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 ...
Here are few more differences between Timer Job and Windows Task schedulers:
Timer jobs require downtime to deploy.
Control via Central Admin.
Schedule of Timer Job will be backed up and restore in your normal process of SharePoint backup and restore.
Can be deployed using standard WSP solution.
Custom Timer Jobs provides the power to specify ...
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 ...
An event receiver runs in the same process as the code that triggered it. This can be anything running SharePoint code:
If the action (adding an item, updating an item...) is performed by an end-user, from the browser UI, the code that actually performs the operation runs under W3WP (the IIS application pool process, i.e. the one that runs the Web ...
SharePoint 2010 RTM'd in April 2010. That article is from December 2009, when it was in beta. We're now into SP1, so it wouldn't surprise me if they changed the dispatcher to use w3wp.exe instead of owstimer.exe.
Personally, if you know that it runs under either of the two, debug either until you hit breakpoints. I don't reckon it's that much of a deal.
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..
we had an External Content Type made from SQL Server Database and the
user wanted to iterate ...
You could try stroring the site url in timerjob properties collection and retrieve it in the Execute method of timerjob
In the feature activated event store the siteUrl
string key = "mySiteUrl";
string value = web.Url;
TimerJob tmrJob = new TimerJob(webApp);
//remove the key if already exists
bool isKeyExists = tmrJob.Properties.ContainsKey(key);
This isn't my forte but I ran across the note below on this MSDN posting; perhaps that will help.
If you wanted a job to run on all servers, including application
servers, your class should derive from SPServiceJobDefinition. Pass
the timer service (SPFarm.Local.TimerService) as the SPService
parameter of the SPServiceJobDefinition(String, SPService)...
The SharePoint System Account is the farm account. A quick way to identify this is in Central Admin. Goto Security > Configure Service Accounts. Select Farm Account. It will display which account is being used. Ensure that account has the appropriate permissions to the secure store entry.
I finally figured out what was wrong. It was our old web application, maybe it somehow got damaged during the server crash. So I created a new web application and tested the timer there. It worked fine. Hope this can help somebody out there.
Recycling the timer service is not a big issue as it will cause the minor outage for a couple of seconds, During the Restart process, all the running jobs will go into paused state and jobs which are scheduled during that time frame will not run But will catch on next schedule once the Timer Service is back.
Another thing, there is Scheduled timer job in ...
This is a very silly alternative but it has worked for me many times when I have faced a similar situation. Create a new timer job with a new name copying all the logic from this timer job and deploy it. Most probably it will work.
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
Disclaimer: While this won't bypass the need to provide a set of user credential, at least will somehow avoid to store them as clear text.
The general idea is to use the Secure Store Service to store a set of credential that will be used in the request. You need to define an "app" and then access that application via codebehind from the timer job instance.
Here is how you get SPServiceContext:
public void UserProfileSample()
//get current service context
string websiteUrl = "http://SampleName";
SPSite site = new SPSite(strUrl);
SPServiceContext serviceContext = SPServiceContext.GetContext(site);
//initialize user profile config manager object
UserProfileManager upm = new ...
Based on my experiments in the case of an OWSTimer process you should access your external data using the BCS API instead of running a CAML query against the external list. See details here: http://pholpar.wordpress.com/2012/02/14/accessing-external-data-from-sharepoint-timer-jobs-or-from-event-receivers-triggered-by-incoming-mail/