Permission Issue in SharePoint Custom Timer Jobs

By: Shishir Bhandari | Comments | Related: > SharePoint

Problem

It's easy to find blogs and msdn documentation on creating Custom Timer jobs, but still developers face issues while deploying and running them on SharePoint farms due to lack of development guidelines for timers. In this blog, I will discuss one issue which is related to permission levels for a custom timer job. Let's say we have the following scenario:

List	list_A	list_B
SiteCollection	SiteCollection: sitecollection_A	sitecollection_B
WebApplication	webapplication_A	webapplication_B

Based on changes made to this list_A, list_B has to be updated which is in sitecollection_B in WebApplication webapplication_B. Out of the box webparts or configurations cannot achieve this. I thought about writing event handlers, but the success rate with event handlers working on two webapplications is quite low, especially in a farm environment. Also I wanted to do a sync only at non-peak usage hours like every night at 11pm, but this cannot be achieved with event handlers.

So how do we sync two lists in different web applications or based on updates to one list, make appropriate changes in another webapplication?

Solution

The solution is to write a Custom Timer job!

Since two different web applications are involved, they can be in two different "Application Pools" i.e. their System Account user can be different. So we need to elevate privileges to their respective System Accounts in order to run our code. But how do we do that? SPSecurity.RunwithElevatedPrivileges doesn't work for Timer Jobs, so how can we elevate Privileges in a Timer job? The solution is to use USER TOKENS of System Account for elevating privileges instead of using SPSecurity.RunwithElevatedPrivileges.

The below example shows how to use a User Token to instantiate the site collection.

SPUserToken myUserToken_A = null;
SPUserToken myUserToken_B = null;

using (SPSite mySiteCollection_A = new SPSite("http://webapplication_A/sites/sitecollection_A"))
{
    myUserToken_A = mySiteCollection_A.SystemAccount.UserToken;
}

using (SPSite mySiteCollection_B = new SPSite("http://webapplication_B/sites/sitecollection_B"))
{
    myUserToken_B = mySiteCollection_B.SystemAccount.UserToken;
}

using (SPSite tempSite_A = new SPSite("http://webapplication_A/sites/sitecollection_A",
myUserToken_A))
{
	using (SPSite tempSite_B = new SPSite(("http://webapplication_B/sites/sitecollection_B",
myUserToken_B))
	{

		//Write your Custom Code here

		//Example:

		//<for syncing list_A and list_B>

		//or

		//<doing appropriate updates to list_B based on the updates made to list_A>

	}
}

How does this work?

"mySiteCollection_A.SystemAccount.UserToken" in the above example uses the user token of the site collection's System Account (SharePoint\System). Using this User Token, we open the site collection with elevated privileges. Now using this site collection's instance, we can do our custom coding.

Next Steps

Remember: Timer Jobs run on OWSTimer service instead of w3wp.exe. So you need to Restart OwsTimer.exe (Windows SharePoint Services Timer) after deploying your WSP.
Review the MSDN method article here - SpUserToken.
Other resource - Use system account - spusertoken.