Timer jobs in sharepoint

Manage timer jobs

You can check the status of a timer job and edit the timer job definition.

For the general administration of all jobs, the SharePoint Central Administration Web site has a Timer Job Status page and a Job Definitions page. You can find these pages in Central Administration, on the Monitoring page, in theTimer Jobs section.

From the View menu, you can filter the timer jobs at the following levels:

• All   Displays all timer jobs for the farm.
• Service   Displays all the timer jobs for a particular service. If you select this command, use the Service menu to select the service by which you want to filter the listed jobs.
• Web Application   Displays all the timer jobs for a Web application. If you select this option, use the Web Application menu to select the Web application by which you want to filter the listed jobs.
• Server   Displays all the timer jobs for the specified server. If you select this command, use the Server menu to select the server by which you want to filter the listed jobs.
• Job Definition   Displays all the timer jobs for the specified job definition. On the Timer Job Status page, use the Job Definition menu to select the job definition by which you want to filter the listed jobs.
• Failed Jobs   Displays all the timer jobs on the farm that have failed to finish.

The SharePoint 2010 Timer service (SPTimerv4) is based on the Gregorian calendar for scheduling. For every job that you schedule, you specify when the timer job will run, specified in a 24-hour time format. You must specify the time in local time instead of as an offset from Coordinated Universal Time (UTC). The time is stored in that format. Daily, weekly, and monthly schedules also include a window of execution. The timer service will select a random time within this interval to start executing the job on each applicable server. This feature is appropriate for high-load jobs that run on multiple servers on the farm. Running this kind of job on all the servers at the same time might place an unreasonable load on the farm. Timer job schedules can be specified by using Windows PowerShell. For more information, see Timer jobs cmdlets (SharePoint Server 2010).

Default timer jobs

Creating, Deploying, and Debugging Custom Timer Jobs in Windows SharePoint

Windows SharePoint Services 3.0 lets you create custom jobs that are executed at set intervals. These jobs, known as timer jobs, are similar to those tasks that you can create in any version of Windows by using the Task Scheduler application. This capability is useful for scheduled process jobs because you keep everything in Windows SharePoint Services rather than create a console .exe file that is configured to run at set intervals by using the Windows Task Scheduler. The major benefits to using the Windows SharePoint Services timer service compared to using Windows Task Scheduler is that the timer service knows the topology of the Office SharePoint Server farm, and that you can load balance the jobs across all the servers in the farm or tie them to specific servers that are running particular services. This Microsoft Office Visual How To demonstrates how to create a job that requests the home page of each site collection in a Web application to force just-in-time (JIT) compilation and to speed up the first request.

public SharePointWarmupJob (SPWebApplication webApp)
  : base(JOB_NAME, webApp, null, SPJobLockType.ContentDatabase) {
    this.Title = JOB_NAME;
}
public override void Execute (Guid targetInstanceId) {
  if (this.WebApplication.Sites.Count > 0)
    WarmUpSiteCollection(this.WebApplication.Sites[0]);
}
private void WarmUpSiteCollection (SPSite siteCollecion) {
  WebRequest request = WebRequest.Create(siteCollecion.Url);
  request.Credentials = CredentialCache.DefaultCredentials;
  request.Method = "GET";
  WebResponse response = request.GetResponse();
  response.Close();
}

Creating Custom Timer Jobs in Windows SharePoint

Introduction to Windows SharePoint Services Timer Jobs

Many different types of applications require some variation of a scheduled process to run. These processes are used for complex calculations, notifications, and data validation checks, among many other tasks. Windows SharePoint Services is no exception. To return relevant and timely results to users' search queries, the content within a server farm must be indexed ahead of time. This indexing is performed at scheduled intervals. Search is only one example; another example might be sending nightly or weekly e-mail messages to users who want to be notified when changes occur in a SharePoint list. These scheduled tasks are handled by the SharePoint Timer service, a Windows service that is set up as part of the installation process.

The SharePoint Timer service is similar to tasks that you can create in any version of Windows by using the Task Scheduler application. The major benefits of using the SharePoint Timer service compared with Windows Task Scheduler jobs is that the timer service knows the topology of the server farm, and you can load balance the jobs across all the servers in the farm or tie them to specific servers that run particular services.

Although Windows SharePoint Services has included a timer service for some time, it has not been easy (or possible) for developers to take advantage of this service to create and register their own scheduled processes. Windows SharePoint Services 3.0 changed this and made the scheduled service much easier to use. First, farm administrators can now see all the registered and timer jobs in a server farm in Central Administration. To do this, on the Operations page, under the Global Configuration section, select Timer Jobs Definitions. In addition to the registered jobs, the Timer Job Status page contains a list of all the jobs and the status and outcome of the last execution of each job.

You define timer jobs by using a single class that inherits from the Microsoft.SharePoint.Administration.SPJobDefinition class. You must deploy the assembly that contains this class to the global assembly cache (GAC). Then you must deploy, or install, the timer job into the server farm. This article describes how to create a custom timer job and deploy it into a server farm that is running Windows SharePoint Services 3.0. In addition, just like many other applications, timer jobs may require some external configuration data in order to function correctly. You have several different options for where to store this configuration data.

The example timer job in this article is not very complex. The purpose of the custom timer job is to act as a replacement for the Windows SharePoint Services warmup scripts. Because Windows SharePoint Services is an ASP.NET 2.0 application, pages are compiled from the generic MSIL to native code upon first use. This is known as just-in-time (JIT) compilation. If not performed beforehand, it can cause pages to load slower the first time they are requested. For the Windows SharePoint Services 3.0 beta release, Microsoft provided a script, known as the warmup script, that issues HTTP requests to a list of Windows SharePoint Services URLs to force the JIT compilation. Although it is not widely used in a production environment, the warmup script removes the initial load time of a requested page. This is useful for Windows SharePoint Services demonstrations and development. The timer job that is demonstrated in this article serves to replace the warmup script.