How do you instruct a SharePoint Farm to run a Tim

2019-04-28 06:20发布

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.

5条回答
一夜七次
2楼-- · 2019-04-28 06:45

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

查看更多
女痞
3楼-- · 2019-04-28 06:48

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.

查看更多
Lonely孤独者°
4楼-- · 2019-04-28 06:59

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.

查看更多
太酷不给撩
5楼-- · 2019-04-28 07:01

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!

查看更多
Bombasti
6楼-- · 2019-04-28 07:06

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.

查看更多
登录 后发表回答