The Task Scheduler service allows you to perform automated tasks on a chosen computer. With this service you can schedule any batch file, program, or document to run at a time that is convenient for you or when a specific event occurs. Task Scheduler monitors the time or event criteria you choose and then executes the task when those criteria are met.

 

Task Scheduler is automatically installed with the Microsoft® Windows® Server 2003 family, Windows XP, and Windows 2000 operating systems and is started each time the operating system is started. It can be run through the Task Scheduler graphical user interface or through the Task Scheduler API.

 

With the Task Scheduler API you can:

 

• Create work items (currently the only work items available are tasks).

• Schedule a task to run at a specific time or when a specific event occurs.

• Change the schedule for a task.

• Customize how tasks run.

• Stop a scheduled task.

 

The Task Scheduler API consists of several COM objects and their associated interfaces. The illustration in this topic shows a task scheduler object that represents the Task Scheduler service; an enumeration object and task object that are created by ITaskScheduler method calls; and a task trigger object that is created by IScheduledWorkItem method calls.

 

Note The IScheduledWorkItem methods are inherited by the ITask interface.

 

Task Scheduler uses two standard COM interfaces: IUnknown and IPersistFile.

 

• The IUnknown interface is supported by all Task Scheduler objects, and all Task Scheduler interfaces inherit its methods. It is used to retrieve pointers to other interfaces on a given object. These pointers are retrieved through calls to IUnknown.QueryInterface.

 

• The IPersistFile interface (supported by the task object) is used to save a task to disk. Whenever you create a new task object or modify an existing task object, you must call IPersistFile.Save to store the task to disk.

 

When developing applications that use the Task Scheduler API, keep the following programming issues in mind.

 

• Your application must make sure the Task Scheduler service is running before attempting to make any calls using the Task Schedular API.

 

• When retrieving strings, make sure you call CoTaskMemFree to release each string after it is no longer needed. When retrieving arrays of strings, make sure you first release each string in the array and then release the array iteself.

 

• When creating or modifying a work item, including triggers associated with a work item, make sure you call IPersistFile.Save to save the work item to disk.

 

• After using any of the interfaces provided by the Task Scheduler API, make sure you call set the object variable to NOTHING to release the interface.

 

Task Scheduler uses two terms to describe what it can schedule: work items and tasks. Of these, work item is a more general term that describes any type of item that can be scheduled. It can be any item that the Task Scheduler service runs at a time specified by the item's trigger(s).

 

In contrast, a task is a specific type of work item. Currently, the only type of scheduled work item that is supported is a task.

 

The IScheduledWorkItem interface contains methods that are supported by all types of scheduled work items. For example, account information, run times, and application-defined comments are properties that may apply to all types of work items. These properties can be set and retrieved through the IScheduledWorkItem interface.

 

The ITask interface contains methods that are supported by only tasks.

 

The methods of the IScheduledWorkItem interface are currently inherited by the ITask interface and in the future will be inherited by other work item interfaces.

 

A task is any application or file type that the Task Scheduler can execute. These may include any of the following (as supported by the operating system on which the task will execute): Win32® applications, Win16 applications, OS/2 applications, MS-DOS® applications, batch files (*.bat), command files (*.cmd), or any properly registered file type.

 

The information that describes a task is kept in a task file that is stored in the Scheduled Tasks folder. The name of these task files include the name of the task, followed by a .job file extension.

 

A trigger is a set of criteria that, when met, will cause a task to be executed. Task Scheduler provides time-based and event-based triggers that can specify task start times, repetition criteria, and other parameters.

 

Time-based triggers are fired at a specified time. Not only can you set the time of day that they fire, you can also set how often they fire: once, daily, weekly, monthly, on a specified day of the month (for example, the third day of the month), or on a specified day of the week of a month (for example, the second Tuesday of the month).

 

Event-based triggers are fired in response to certain system events. Event-based triggers can be set to fire when the system starts up, when a user logs on to the local computer, or when the system becomes idle. The last of these is known as an idle trigger.

 

Each task can have a single trigger associated with it or multiple triggers. Multiple triggers can be thought of as a schedule, a set of times at which something happens. In this case, the schedule is the set of times (specified by the union of all the triggers associated with the work item) at which a work item will execute.