In the first part of this two-parter, I outlined a problem facing developers when they try to connect to SharePoint sites outside of the context of SharePoint service accounts or administrator accounts.
The problem comes up when you do a basic connection using new SPSite(“http://someurl”); The error message is the FileNotFoundException as described in the title of this post. So, how do we debug the problem?
Spoiler alert: It’s a permissions issue. Your site is there but the account you use to run your application doesn’t have access to connect to the site using the object model.
First, we need an app. A simple console application is likely your best shot, so create one of those, doing nothing but the simplest of tasks inside your main method:
static void Main(string args)
SPSite site = new SPSite("http://localhost/");
If you want some improved output, you may venture into some advanced error handling like:
SPSite site = new SPSite("http://localhost/");
catch (Exception ex)
Running that code as an administrator will yield success because, well, we’re developers, to be addressed as ‘Oh great and glorious’, preferably accompanied by some select music by George Friedrich Händel.
Try logging in as someone without your divine touch and ‘poof’ goes your code and attempt to connect.
Leave it to normals to ruin a perfectly good ego trip.
However, because our powers are nothing short of infinite (we have methods called ‘CreateUser’ for crying out loud), we can remedy those problems and grant the minions the permissions they require.
There are two types of permissions we need to fix. One is access to the registry and file system and another is access to SQL server, or rather permissions to run certain queries.
What, we need to give users access to the registry to run applications?
Yes, you do. In fact, this is very well documented in the TechNet article Account permissions and security settings (SharePoint Server 2010). In other words, your simplest way of granting users the necessary registry and file system permissions is to make them members of WSS_WPG. That may be too wide for you, so here’s a suggestion to how you can configure your minimum permissions yourself.
Create a new AD group (or Windows group if you’re not using a domain) that you name something easy to remember like ‘Minions’.
For each of those permissions in the above mentioned TechNet article, grant one permission at a time and try running your application. Depending on what tasks you want to do inside your application, chances are you’ll get away with less than the full range of permissions. However, you may still not be able to get rid of that FileNotFoundException problem, though, because there is one more part to our puzzle.
Second are the SQL server permissions. Again, there is an easy to use role to which we can add users who need to run applications. That role is in the SharePoint Config database and is called WSS_Content_Application_Pools. Chuck your minions into that group as shown in the figure below and you’re good to go.
Again, this may be a bit broad for you, so you may want to just set exactly the permissions required. To do so, you can use the SQL Profiler to see what fails and then grant your minions permissions to do those actions.
Be aware that this is a tedious task at best, but it does afford you incredible control over which permissions you grant.
First, if you added your minion to the WSS_Content_Application_Pools role, remove them, and watch as their self-esteem falls apart when they try running your connection application.
Next, open the SQL Server Profiler and create a new trace. Set the filters to show only events where your minion is involved. In my case, this would look something like the figure below.
Once you run your application now, you’ll see a single query in the trace window followed by the usual error message in the console application. In my case, the query in the trace is:
exec dbo.proc_getObjectsByClass @ClassId=’674DA553-EA77-44A3-B9F8-3F70D786DE6A’,@ParentId=NULL,@Name=NULL
This means that we need to grant our minion the rights to execute this query, or specifically, the stored procedure called proc_getObjectsByClass.
You can do this individually for each securable object (stored procedures is a securable object) by opening the user in the database and selecting the Securables tab. Click Add and select the ‘Specific objects…’ option. In the Select Objects dialog that pops up afterwards, select the Stored procedures object type and then in the object names, enter [dbo].[proc_getObjectsByClass] before clicking OK, as shown below.
The stored procedure should now appear in the Securables section and you should see the grantable permissions blow.
Select Grant on the Execute row and hit OK, as shown below.
OK, one permission down, but still many to go.
If you try running your console application again now and watch the SQL Server Profiler trace, you’ll get much further, but you still get the same exception as before. This time, the last query that fails, at least in my case, is
exec dbo.proc_getObjectsByBaseClass @BaseClassId=’9920F486-2FF4-4D10-9532-E01979826585′,@ParentId=’14B655C4-FC63-454C-AE61-B18B96CFF10C’
Repeat the above steps to grant the minions permissions to execute this stored procedure as well. Re-run the console application after doing so, and you’ll get even further. Grant the permissions needed to execute the last (and failing) query in the trace until your console application succeeds.
Congratulations! You’ve just granted your minions exactly the permissions they need to execute a console application and connect to your SharePoint site.
By the way, you’d still need to grant your minions access to the sites where they will perform work. That, as they said in Tajikistan, is another show.
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!