Timer Job: Stsadm properties (Windows SharePoint Services)

Applies To: Windows SharePoint Services 3.0

Topic Last Modified: 2009-04-23

A timer job is defined as service that stores information about logical units of work on a server, and queries it for execution at pre-defined intervals (that is, a time schedule). The phrase time schedule applies to all Web sites on a particular Web application. The scope determines how the job is run. If a job is scoped to the Web server level, it is run for each Web server computer, independently of any other Web servers that might be hosting the same content. If an operation is scoped to the content database level, it is run once for the content database, which means once for the each content database in the entire server or server farm.

When you schedule a timed job, you schedule the beginning time for the job. For example, you can schedule a job to be run daily, beginning between 1:00 A.M. and 2:00 A.M. You always schedule jobs to begin within a time range, rather than at a specific time. This allows the Windows SharePoint Services Timer service (SPTimer), which is described in following paragraphs, to be run at a random time in that range, so that not every server in a server farm is running the scheduled job at the same time. For example, if you set job-change-log-expiration processing to be done during the range 1:00 A.M. to 2:00 A.M., each front-end Web server starts processing the change log sometime between 1:00 and 2:00 A.M.

The Windows SharePoint Services Timer service (SPTimer), a background utility, handles scheduled jobs in Windows SharePoint Services. This utility is installed to your Web server when you set up 1st_WSS_3. The SharePoint Timer service relies on the Gregorian calendar for scheduling. For every job you schedule, you must specify a beginning time for that job based on a 24-hour clock. You specify the time in local time versus an offset from Universal Coordinated Time (UCT), and the time is stored in that format as well.

The dates used by the SharePoint Timer service are not stored in context. This means that you cannot schedule jobs to run every X days/weeks/months/years, where X is greater than 1. So, while you can schedule jobs to run every day, every week, or every month, you cannot schedule a process for every two days, and so on. Neither can you schedule jobs for relative days in a month, such as the third Monday of every month.

The timer job properties are part of the setproperty and getproperty operations. The syntax for the setproperty operation is:

stsadm -o setproperty

-propertyname <property name>

-propertyvalue <property value>

**\[-url\] \<**https://server\_name**\>**

The syntax for the getproperty operation is:

stsadm -o getproperty

-propertyname <property name>

**\[-url\]** \<https://server\_name\>

The following table describes the timerjob properties.