1

I've worked with several examples of both SharePoint Timer Jobs and PowerShell scripts, some of them doing the same things as the other. In my experience, PowerShell scripts are far more flexible, easy to test, and easy to deploy than SharePont Timer Jobs. The only advantage I can really think of to Timer Jobs is that they are written in C#.

What are the advantages/disadvantages of each? When is it better to use one or the other?

All comments that apply to 2010 and/or 2013 are weclome

answers i will not accept:

  • you can schedule Timer jobs to run regularly - you can schedule powershell scripts as well, using the Task Scheduler
  • Timer Jobs are all located centrally - you can simply agree to store all powershell scripts in a single folder
|improve this question
2

One of the things I like about Timer Jobs is the property bag that comes with them - you can deploy an admin page to Central Admin to manage said properties and configure your job on the fly, without resorting to config XML. You can also package all of this into a single WSP for deployment.

I suppose PowerShell is better if you're doing non-SharePoint things, like working with local files, but if I'm just within the SP ecosystem, I generally prefer to limit the additional technologies I work with =)

|improve this answer
  • I hadn't thought about that you could add a page to Central Admin to manage it... that is a very valid point, though I think personally I would never go to the effort. I don't think PowerShell and Task Scheduler count as "additional technologies" – Nacht Nov 13 '12 at 23:58
2

from architecture point of view it is better to use TimerJobs. Advantage is that it executes code under Sharepoint account, it also has build in scheduling functionality. If you'll backup your SP data, this schedule will be saved. If you need create custom functionality, which automatically will be deploying without really notifying users and will handle it's tasks. So it is better also for custom solutions.

If you need fast adaption, fast integration and reconfiguration. PowerShell is better. If you know, that you will not distribute your solutions, you create functionality for your personal case, there is nothing wrong in using scheduled PowerShell scripts.

|improve this answer
  • you can run powershell scripts using the sharepoint account as well, with Task Scheduler. I'm not sure what you mean about backing up the schedule – Nacht Nov 13 '12 at 23:43
  • of course you can run it under SharePoint account, but you need to manually specify it, also you need manually specify schedule, also target customer (if you work with customer) will have possibility to change your code, so, they can crash something. That it isn't the best way to provide ready to use functionality which I believe should be installed as easy as you can and have to be protected from modifications. If you work on your farm, all have direct access to client farm and you need to do fast modifications, you needn't things I described below, you can just use PowerShell script. – Anton Khritonenkov Nov 14 '12 at 5:30
  • And you are right, backuping SharePoint databases to store the schedule is not real advantage, here I'm wrong. – Anton Khritonenkov Nov 14 '12 at 5:34
  • you always have to configure the schedule, and it's not like it's difficult to configure which account runs it. If the customer messes with the code itself, then that's their own damn fault, but I suppose that is a definite difference between the two. – Nacht Nov 14 '12 at 5:36
  • I think this is not the best way to think about client like this, but this is topic for different converstaion, I think we should stop at this point. – Anton Khritonenkov Nov 14 '12 at 8:19
0

The advantage with Timer Jobs is that they can be scheduled to run at different time intervals easily whereas with Powershell scripts you need to do that manually or do some extra things to automatically run them at specified intervals.

|improve this answer
  • you can schedule powershell scripts with Task Scheduler, with more options than Timer Jobs allows – Nacht Nov 13 '12 at 5:25
  • I was referring to the same, when I was saying "you need to do extra things..." and by the way if you use Task scheduler, then you can also simply write C# code as well. – Nadeem Yousuf Nov 13 '12 at 7:13
  • yeah that's a good point, which i hadn't realised i could do - simply write sharepoint console applications – Nacht Nov 14 '12 at 5:33
0

In a multi-server farm - a timer job could run on any available server. For heavy/long jobs this can be very useful.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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