When invoking SharePoint jobs (either standalone or timer jobs), I occassionally run into a 403: Forbidden error. This is one of the more difficult to diagnose errors I’ve faced.
I ran into it again today, in this case during a feature receiver’s Feature Activated event. I searched for clues in the usual places: I checked the Windows event logs, checked the ULS logs, checked app pool read permissions for the IIS and 12 hive folders, checked my CAS policy, etc. I attached my debugger and traced through, but everything looked normal.
After a short while, I found the unlikely culprit: The WSS_WPG account didn’t have permission to schedule Windows tasks. Yes, even one-time jobs use Windows tasks, so the worker process needs to be able to schedule them.
This happens to be the same underlying error which prevents search crawls from being configured. My colleague Tony documented a fix, which also happens to remedy custom SPJobDefinition 403 problems:
“This issue occurs due to security privileges that revolve around the tasks folder on the index server. To fix this issue the follow steps need to be completed:
- Check to see if you can view the security tab from the Tasks folder in the Windows directory, usually C:Window. If you can see Sharing and Security skip step 2.
- To view the attributes of a folder open a command prompt and typeattrib –s %windir% tasks. If Windows Explorer is already open, close it and reopen once this command has been executed. Now browse to %windir%tasks, right click and select propertied. Click on the security tab.
- From the security tab click add, change theFrom this location:from the domain to the local server.
- In theEnter the object names to select (examples):typeWSS_WPG. Click check name and once it resolves select ok.
- Now grantWSS_WPGpermission toRead, andWrite. Click Ok and close the window.
- Close Windows Explorer and open a command prompt and this time typeattrib +s %windir% tasks. This will reset theTasksfolder to its default view.”
