Discovering the SPTimerService and PreferredTimerServiceInstance in SharePoint with Powershell

By | 2017-03-27

Recently we had installed a new SharePoint 2013 On Premise farm. Everything worked great with custom features and permissions and so on, however suddenly a Health Monitoring Rule came knocking about some missing dependencies. I fixed this specifically a few weeks ago, but now it reappeared without us changing anything that could trigger this. When I reran the Health Analyzer Rule, it was OK again.

Upon investigation, it seemed the corresponding SPTimerjob was run on a back-end server the time it got the error messages. When it turned OK it was running on a Front-End server. The message itself was not unfamiliar, it can also be triggered by the Powershell command “Test-SPContentdatabase”.

When I ran this Powershell command on a Front-End server, it reported no problems, but when I ran it on a back-end server, it reported the same Missing Dependencies warnings (Missing Templates, Missing Features, Missing Webparts, etc).

This Health rule “Missing server side dependencies” is run once a week, the scope of this rule can be set to “Any server” or “All servers”. This doesn’t help us in our case.

Scope options for Health Analyzer Rules

Scope options for Health Analyzer Rules

The cause is that our back-end servers do not have the ServiceInstance “Microsoft SharePoint Foundation Web Application” running. Also the custom solutions are not installed on our back-end server (related to the webapplication scope of some of them). Testing to load our custom DLL proved to produce errors on our back-end SharePoint servers:



So I searched for a way to have this Health Analyzer Rule run only on the Front-End servers, and of course I want to do it with Powershell.

I have found two ways of doing this:

  1. Setting the SPContentDatabase property “PreferredTimerServiceInstance” to a specific TimerService that lives on a specific Front-End. Read more on it at
  2. Changing the SPTimerServiceInstance property “AllowContentDatabaseJobs” to False on the servers on which I don’t want this rule. Read more on it at

Reading the remarks on the AllowContentDatabaseJobs property at the second MSDN page definitely demonstrates my finding:

Note that if a server is set as the “preferred” server for content database timer jobs, then setting this property to false will cause an exception.


To get some more background info on the PreferredTimerServiceInstance, read the answer from Roger Cormier at this MSDN forum post.



So how do we set these properties?

First off, we need to look at the SPTimerServiceInstances in our Farm. We can get these with either one of the following commands:


To get the specific TimerService Instance on the current server we can use the following where clause:


The property on the ContentDatabases is easily accessible, just get an SPContentDatabase object with the appropriate Powershell command “Get-SPContentDatabase”. The property “PreferredTimerServiceInstance” can be read and set normally.


So, to set the property on all contentdatabases to the TimerService instance on the current server, we can use the following loop.



Now to get or set the AllowContentDatabaseJobs property requires some more advanced Powershell and reflection again (read this article for my explanation on the GetMember/Invoke construction). Notice I use the Farm TimerService Instances to iterate through and invoke the get method on each one.


Finally I set the value to false on the TimerService instances on all servers except the current server:


Keep in mind that it is better to have more than 1 server as possible TimerService Instance, because when the preferred instance fails, we don’t want more trouble.


Don’t forget we need to Update and Restart the timerservices as per MSDN remark on the AllowContentDatabaseJobs property:

Leave a Reply

Your email address will not be published. Required fields are marked *