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.