Custom job and System.Security.SecurityException: Access Denied

Question

I have a custom job that I'm executing from a Web Part.

MySPJobDefinition myJob = new SPJobDefinition(SPContext.Current.Site.WebApplication, myParameters...);

//works
myJob.Execute(Guid.Empty);

//fails - exception below code
myJob.RunNow();

//instead of myJob.RunNow() I've tried to put it in a "bogus" schedule, but that fails as well when myJob.Update() is called
SPOneTimeSchedule spOneTimeSchedule = new SPOneTimeSchedule(DateTime.Now.AddMinutes(1));
myJob.Schedule = spOneTimeSchedule;
myJob.Update();

Exception message:

Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Access Denied.

Both application pool in IIS and OWSTIMER runs under admin account. I have read that thread: Configure SharePoint user for timer job, but no success

What I'm trying to achieve is that my job is time consuming. If i execute it by myJob.Execute(Guid.Empty) after a while I get timeout. I was thinking that put it in a one minute schedule will run that job in background. Or is there another way to run job asynchronously?

Answer 1

There may be a better way of doing this.

Use your Web Part to create an SPWorkItem object. Then change your timer job to be a Work Item Timer job (inherit from SPWorkItemJobDefinition).

Waldek Mastykarz wrote an excellent guide to using it: http://blog.mastykarz.nl/processing-items-work-item-timer-jobs-sharepoint-2010/

This approach has the advantage that the creation of the SPWorkItem (in your worker thread for your user request) is pretty quick, and easy to achieve. The Work Item Timer job will then pick the work item up at a later time, and process the item behind the scenes.

Trying to add a new job and kick it off from a web part is unlikely to work well, and certainly won't work in a least-privileges configured system, where none of the users in the content app pool should be able to access the configuration database for the farm.

Answer 2

Actually setting:

 ContentService.RemoteAdministratorAccessDenied = $false

and restarting the owstimer.exe (SPTimerV4) after deployment from Visual Studio solved the problem. The error disappeared and scheduled job works as expected.