Permission Issue in SharePoint Custom Timer Jobs
Written By: Shishir Bhandari -- 9/7/2010 --
(3793) comments --
Categories: Configurations, MOSS 2007, Permission Management, System Administration, WSS3
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:
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?
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
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",
using (SPSite tempSite_B = new SPSite(("http://webapplication_B/sites/sitecollection_B",
//Write your Custom Code here
//<for syncing list_A and list_B>
//<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.
- 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 -
- Other resource -
Use system account - spusertoken.
- Return to
MSSharepointTips to read about other topics and ideas.
- Check out MSSQLTips.com for great
information about Microsoft SQL Server.