Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Can somehow explain me what are of the benefits of using SharePoint Timer jobs over Windows Task Scheduler?

share|improve this question
add comment

5 Answers 5

Here are few more differences between Timer Job and Windows Task schedulers:

Timer Jobs

  1. Timer jobs require downtime to deploy.
  2. Control via Central Admin.
  3. Schedule of Timer Job will be backed up and restore in your normal process of SharePoint backup and restore.
  4. Can be deployed using standard WSP solution.
  5. Custom Timer Jobs provides the power to specify Job LockTypes (i.e. SPJobLockTypes) which guarantees that multiple instances of same job will never execute at the same point in time.

Windows Task Scheduler

  1. Windows Scheduled task doesn't require downtime to install/update.

  2. The task will only run on the server that you've installed it on.

  3. Administrator needs to manually manage backup and restore of Schedule Tasks

  4. No standard built in deployment method

  5. No multiple instance guarantee. Administrator needs to make sure that no two instances are running at the same time.

share|improve this answer
add comment

Our operations team says when you have a task that is really related to SharePoint, maybe list items iteration, logging etc etc. you should use Timer Job..

But if you have tasks not related to SharePoint at all or directly.. Than use Task Scheduler..

Example, we had an External Content Type made from SQL Server Database and the user wanted to iterate through the SharePoint Lists and put some values in SQL Database.. The operations team denied using Timer Job in this case.. Said the affected part is on SQL Database and its not directly related to SharePoint.. We had to make a Task Scheduler in this case..

However once we had to Iterate through one of the Lists and send emails to people on the basis of expiry or so.. In this case Operations had no issue on creating Timer Job :)

share|improve this answer
1  
+1 for the explanation. Two things I would add. First, a TimerJob is going to execute in the context of the account the the SP Timer Service is running as. A Scheduled Task can be configured. Second, A TimerJob can be run by SharePoint admins via the Central Admin web page. This might be an important convenience for choosing a TimerJob over a scheduled task. –  Robert Kaucher Apr 11 at 19:24
add comment

I like Arsalan's answer, however MS is pushing people to avoid server side development, which includes Timer Jobs. As timer jobs run on the SharePoint server, a poorly written timer job can have a negative impact on the farm. Also, if a customer ever moves to Office 365, any custom timer jobs will have to be re-written.

An app run by the windows task scheduler that connects to SharePoint via REST or the CSOM seems like it is more in line with current guidance. The scheduled task can be run from any server, not just the SharePoint box, and it can be re-pointed to Office 365 with almost no effort,

share|improve this answer
add comment

Benefits of Sharepoint Timer jobs over Windows Task Scheduler are :

Single point of failure : Windows Task Scheduler need to be configured on all the web servers. If you configure to run the job on 1 server only, and this server crashes, job will not work at all.

Status Reporting : Windows Task Scheduler doesn't have any reporting on when was the last time job got executed and what was the status. Only option is logging. Whereas SharePoint have a UI to show status of all the jobs and their status.

Security : In case of Windows Task Scheduler, you will need go to IT Admins and request for a special username/password to run such jobs where as SharePoint Timer Jobs automatically run under SharePoint Timer Job account.

Deployment : There is no easy way to deploy Windows Task Scheduler tasks and application which need to executed in a FARM environment. This will require lot of manual steps by IT Admin. SharePoint jobs can be deployed using WSP's.

share|improve this answer
    
I disagree to Status Reporting and Deployment part.. You can easily write your own text file based logs.. And deployment isn't too hard or aren't too many steps for Task Scheduler.. –  Arsalan Adam Khatri Apr 12 at 14:49
add comment

In addition to the above, timer jobs are much easier to test, as you can just run them in visual studio. Another advantage is that if the timerjob has any configuration data it can be installed in a simple app,config

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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