I was recently working on a custom windows application whose job was to bulk load content into SharePoint document libraries. I was testing it on the test server and then moved it over to the production server for the client to use. When they logged in with their admin account (account #1) and fired up the app, it wouldn’t do its job. Looking at the log file showed the error:
The web application at [URL] could not be found. Verify that you have typed the url correctly. If the url should be serving existing content, the system administrator may need to add a new request url mapping to the intended application.
This error is basically a really verbose SharePoint “file not found” type of error. It’s saying that it can’t find the URL and suggesting that your SharePoint administrator might need to add an alternate access mapping to your SharePoint web application (extend the web app and add an alternate access mapping). It was occurring when instantiating and SPWeb object.
The funny thing about this error was that, if I logged on as an administrator, it went away and the app worked fine. That immediately suggested to me I had a permissions problem. So I looked all around for where the differences might be. The account was actually in the domain administrators group and had permissions that worked fine in SharePoint. It was a farm administrator and a site collection administrator. There was nothing it couldn’t access…except the SPWeb object.
We had a couple of other accounts that were similarly configured, so I tried one of the other accounts after spending hours “googling” (or was it “bing-ing?) a potential solution. While searching on the web, I found I had plenty of company with others who had similar problems. Many of proposed solutions revolved around swapping out accounts in specific application pools being utilized by SharePoint. However, most of these solutions do not take into account infrastructures that won’t allow these accounts to be changed to local system accounts. Whatever…
Okay, so I tried one of our other similarly configured accounts and found that it worked just fine. “What was the difference”, I pondered? I searched all over and found that account #2 was NOT a site collection administrator. In other words, the account that wasn’t working, account #1, WAS a site collection administrator and the account that WAS working was not. So, I removed it from the site collection administrators.
Guess what? My application suddenly started working when logged on as account #1. So, I put it back in to the site collection administrators group and found that it STILL WORKED! Just taking it out of the site collection administrators did something, somewhere in the vast security netherworld of SharePoint that flipped the appropriate “bit” and fixed whatever the original problem was. Problem solved. Only took eight hours. 😦