"RunWithElevatedPrivileges" in SharePoint Timer Jobs?

Question

Can we use SPSecurity.RunWithElevatedPrivileges in SharePoint timer jobs?

Under whose identity will the timer job run under elevated privilegs?

Any gotcha's and must know facts regarding this will also be appreciated.

Tusker

Answer 1

RunWithElevatedPrivileges only works if the current thread is using impersonation, i.e. IIS. Used in other code (timer jobs, console applications, workflow, etc.) it will have no effect. Colin is correct that by default the timer service runs as the farm service account specified in the COnfiguration Wizard. You can verify this in Windows Services.

Wicket

I can't speak for timer jobs or workflow, or technically console applications either but I'm developing a winforms application - which should have basically the same execution context as a console app (the user that starts the application) - and it can't do certain things without a RunWithElevatedPrivileges delegate, and then of course getting a new SPSite in the new elevated context. Do you have a source that shows how that's not necessary? – Butyrate

To confirm, you're using SharePoint 3.0/2007? Try checking Environment.Username in and out of RWEP to see if there's really a change. (See solutionizing.net/2009/01/06/elegant-spsite-elevation/… and responses for related discussion.) – Wicket

Nope - SharePoint 2013 - has the functionality of RunWithElevatedPrivileges() perhaps changed since? or is it slightly different some other way in more recent versions of SP? – Butyrate

No idea, honestly - I'm several years out of SharePoint dev. I'd pop open ILSpy/dotPeek/equivalent and see what the implementation looks like now. Did you try checking Environment.Username? – Wicket

Answer 2

They run under the account you used when running the SharePoint Products and Technologies Configuration Wizard for the first time to connect to SQl / run the Central Admin app pool under. i.e. the God account in SharePoint.

Rosannarosanne