How do you instruct a SharePoint Farm to run a Timer Job on a specific server?

Question

We have an SP timer job that was running fine for quite a while. Recently the admins enlisted another server into the farm, and consequently SharePoint decided to start running this timer job on this other server. The problem is the server does not have all the dependencies installed (i.e., Oracle) on it and so the job is failing. I'm just looking for the path of least resistance here. My question is there a way to force a timer job to run on the server you want it to?

[Edit] If I can do it through code that works for me. I just need to know what the API is to do this if one does exist.

Ahmedahmedabad

Answer 1

I apologize if I'm pushing for the obvious; I just haven't seen anyone drill down on it yet.

Constraining a custom timer job (that is, your own timer job class that derives from SPJobDefinition) is done by controlling constructor parameters.

Timer jobs typically run on the server where they are submitted (as indicated by vinny) assuming no target server is specified during the creation of the timer job. The two overloaded constructors for the SPJobDefinition type, though, accept an SPServer and an SPJobLockType as the third and fourth parameters, respectively. Using these two parameters properly will allow you to dictate where your job runs.

By specifying your target server as the SPServer and an SPJobLockType of "Job," you can constrain the timer job instance you create to run on the server of your choice.

For documentation on what I've described, see MSDN: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spjobdefinition.spjobdefinition.aspx.

I don't know anything about the code you're running, but custom timer jobs are commonly setup during Feature activation. I got the sense that your codebase might not be your own (?); if so, you might want to look for the one or more types/classes that derive from SPFeatureReceiver. In the FeatureActivated method of such classes is where you might find the code that actually carries out the timer job instantiation.

Of course, you'll also want to look at the custom timer job class (or classes) themselves to see how they're being instantiated. Sometimes developers will build the instantiation of the class into the class itself (via Factory Method pattern, for example). Between the timer job class and SPFeatureReceiver implementations, though, you should be on the way towards finding what needs to change.

I hope that helps!

Mohn

Answer 2

Servers in a farm need to be identical. If you happen to use VMs for your web front ends, you can snap a server and provision copies so that you know they are all identical.

Rocha

+1 I agree with that, but the client's network admins don't see it that way. I'm just looking for a less confrontational option here. – Ahmedahmedabad

Here at Raytheon, Microsoft has asked us to make our servers duplicates because windows workflow just won't work, and we have various other unpredictable flakiness. I upvoted Dave's answer. – Hereabouts

Answer 3

Timer jobs per definition run on all web front ends.

If you need scheduled logic to run on a specific server, you either need to specifically code this in the timer job, or to use a "standard" NT Service instead.

Ardyce

Coding it in, is an option. Is there an API where I can instruct SharePoint that I want it run on a specific server? – Ahmedahmedabad

Answer 4

I think a side effect of setting SPJobLockType to 'Job' is that it'll execute on the server where the job is submitted.

Laskowski

Answer 5

You could implement a Web Service with the business logig and deploy that Web Service to one machine. Then your Timer Job could trigger your web service periodically.

The it sould be not that important wher your timer job is running. SharePoint decides itself where to run the timer job.

Infrequency