A farm administrator should allow access for a new user to the web, this user has never been added to any sharepoint groups before (He is a new employee, for example). This user should have possibility to create a timer job on web site page.

What steps should I do to configure a new user for timer job?

  • What is the problem that you are trying to solve? In the current and previous thread, your are just talking about the techy thingies, but maybe there is a complete other solution for your problem.
    – Bas Lijten
    Commented Nov 5, 2011 at 8:20
  • I tries to understand how does the user interact with sharepoint timer service? What permissions shoul the user have to work with this service? How to correctly configure system that the user can manage timer jobs from any webs, not only from CA?
    – Alexander
    Commented Nov 5, 2011 at 8:37
  • Would it be possible to re-phrase this question so that it stands on its own? Perhaps you just need to delete the first paragraph. If the question is self-contained there is a better chance of getting answers.
    – SPDoctor
    Commented Nov 5, 2011 at 15:34

3 Answers 3


This article can probably help you, briefly, you will need to set ContentService.RemoteAdministratorAccessDenied setting to false.

PowerShell code (copy-pasted from the article):

$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.RemoteAdministratorAccessDenied = $false

Nevertheless, I reckon, that creation of timer jobs by portal users is not a good idea anyway, despite of it's possible.

I'd recommend you to create one single timer job, which will run every minute (SPMinuteSchedule), and check for a value in web properties. If the expected value found - timerjob will clear this value, and do it's work. This approach is often used when controlling threads execution (known as "signaled threads").

So the point is, that user will not interact with timerjob directly. He will only set a value in web properties.

Also you can use farm properties instead of web properties, or other information storage, because web properties are actually not a very secure place to store data.

  • When a timer job instance is created, it is persisted to the farm configuration database So in this case I should configure an account that has write permissions to this DB. Then I should add this account to my web site. Am I right?
    – Alexander
    Commented Nov 6, 2011 at 11:39
  • Paul said 'Upon detailed investigation of Microsoft.SharePoint.dll I discovered that SharePoint guys added a new security feature to all objects inheriting from SPPersistedObject in the Microsoft.SharePoint.Administration namespace. This feature explicitly disallows modification of the above stated objects from content web applications, which is where our web part is running.'. In this case we cannont use Persisted objects on a web... is it realy ???
    – Alexander
    Commented Nov 6, 2011 at 11:42
  • Your reasoning seems to be logically correct :) But there is additional access restriction here, so in addition you probably will need to set RemoteAdministratorAccessDenied to false. Anyway, I haven't tried this workaround by myself and can't garantee it will work in your situation. I'd prefer the "signaled" approach. Commented Nov 6, 2011 at 11:48

The issue is different, but solution is the same.

My Friend posted a link to the post in my previous question. There are solutions:

The account creating the site collection, via either of these approaches, must have the appropriate rights to update the configuration database. Obviously your users aren't going to have the appropriate rights so you might think you could use SPSecurity.RunWithElevatedPriviliges (RWEP). Unfortunately this won't work either because unless you are running the page via the SharePoint Central Administration site (SCA) then your application pool identity will also not have the appropriate rights (at least it shouldn't if you've configured your environment correctly). Your next thought might be to create a timer job and run the site creation code within that job because you know your timer service account runs as a farm administrator. However, you now face the same issue as your calling account must also have rights to update the configuration database in order to create the timer job.

There's a few different ways around this problem, each with their own pros and cons:

  1. Grant your application pool accounts appropriate rights to the configuration database. This approach is not recommended as you are violating the concept of least privileges and potentially exposing sensitive information and risking corruption if your application pool should become compromised.
  2. Create a custom windows service that runs as the farm account and uses .NET remoting to communicate tasks. If you think you'll have lots of operations requiring privileged access then this is potentially a good way to go, but it introduces are high degree of complexity and requires an installer to be run on every server in the farm. SharePoint uses this approach with its implementation of the "Windows SharePoint Services Administration" service (SPAdmin). The OOTB scsignup.aspx page uses this service to handle the creation of the site collection and thus get around the security restrictions. Unfortunately there's no way for us to leverage this service by having our own code run using it (like we can with custom timer jobs and the SPTimerV3 service).

  3. Create a virtual application under the _layouts folder of each web application and have it run using the SCA application pool. Using this approach you can put the site collection creation application page under the virtual application and thus get the credentials required to edit the configuration database. The problem with this approach is that you once again must touch not only every server but every web application, which defeats the purpose of using WSP packages for solution deployment.

  4. Direct all site collection requests to an application page under the SCA site and pass in target values. This approach gets around a lot of the issues described above (simple to deploy, runs with an account having the appropriate permissions, etc.). The problem is that you must now expose your SCA site to everyone and you must grant the "Browse User Information" right to everyone.

  5. Call a web service running under the SCA's _layouts folder. The nice thing about this approach is that it is simple to deploy (standard WSP deployment from a single server updates all existing servers and any new servers), easy to create and debug, and simple to maintain. The only downside is that it requires that your WFE servers be able to access the SCA web site. The upside is that you don't have to expose this to everyone - just the WFE servers, and you don't need to grant the "Browse User Information" right as your application pool accounts should have the appropriate rights already. You can also get around high availability issues by having the SCA site run on each server (see Spence's article on high availability of SCA: http://www.harbar.net/articles/spca.aspx).

Full post you can read there

  • So ugly in either case, imho.. :( Never understand why you don't like the "signaled" approach. Do you really need to run your timer job immediately? I reckon in most cases less-than-a-minute delay is pretty acceptable... Commented Nov 10, 2011 at 19:36
  • @omlin, you are right. The best solution is to start timer job from feature reseiver of SPFarm or SPWebApplication features or use powershell as you said. The main goal of this question is deep understanding of timer service. I would like to know limitations for user, and how I can trick these limatations. Thanks for your advice.
    – Alexander
    Commented Nov 10, 2011 at 19:52
  • My main point was not about PowerShell... :) It was about using web property and each-minute (SPMinuteSchedule) executing timer job, which checks this property and fires execution only if the property is equal to, say, "fire" (and then reset this property back to "not fire", of course). Web properties could be set without any permission problems. Isn't that a good trick?! :) Still don't see any disadvantages of it. Commented Nov 10, 2011 at 20:51

The user does not interact with the timer service. Timer jobs do not get created on a site's page. The timer service is used by SharePoint and developers/admins to create SharePoint timer jobs that perform administrative level recurring tasks. It is not a user level function. If this user is not an administrator or developer that is going to be writing custom code, then he should really have no need to even know the timer service exists.

  • I understand that this user should be an administrator. How can I configure his rights correctly? what part of system should I configure (DB, web application, farm, serviced, etc.)? Why timer job cannot be created on a site's page? As I understand the timer job can be created on web scoped feature activation (there are a lot of examples in the internet), I don't think that it is a big difference between feature receivers and page background in this case.
    – Alexander
    Commented Nov 6, 2011 at 6:40
  • @Alexander timer jobs cannot be created from feature receivers either, unless they're executed from stsadm or powershell. If timer job creation feature is activated from GUI, it will fail with exception. That's why such features are often marked as hidden. Commented Nov 6, 2011 at 10:58
  • @omlin - I think that depends on the scope of the feature too. Web Application Scoped features - which have to be activated in Central Admin - can create timer jobs just fine. But you're right that it might fail if activated from SPSite or SPWeb level (depending upon the user's access, so it's a bad idea to even try).
    – Andy Burns
    Commented Nov 8, 2011 at 8:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.