Scripting Solutions with WSH and COM: Scheduling Automated Tasks

In "Scripting Solutions with WSH and COM: Give Your PCs a Wake-Up Call," February 2002, InstantDoc ID 23602, I demonstrated how to use Wake on LAN (WOL) technology to wake up your PCs. Unless you plan to stay awake with your computers all night so that you can wake them up and run the scripts manually, you need a way to schedule tasks automatically. I introduce you to the power of automatically scheduling your scripts on Windows XP systems and provide a few simple scripts that show you how automated tasks work.

The Good Old Cron Days
Since the early days of PC systems management, I've used a dedicated PC in the data center rather than a server to run scheduled tasks automatically across the network. When I began searching for software that I could use to schedule tasks, I wanted something that worked similarly to the UNIX cron daemon. This daemon schedules automated tasks according to entries in stored configuration files called crontabs, then outputs the results to log files called cronlogs. I discovered a PC version of this UNIX utility that runs permanently in DOS, scheduling tasks that I add to the crontab file. To this day, my dedicated scheduling PC is known as "the cron machine," even though I've upgraded it to XP so that it can run all automated tasks across the network.

Before Microsoft developed the Task Scheduler service, you had to use the At command from the command line and the Schedule service to schedule tasks in Windows NT. In fact, many users referred to the service as AT because it ran tasks at a time and date. AT had many useful commands, such as Net Stop Spooler. The sample command that Listing 1 shows tells the Schedule service to run the Net Stop Spooler command next Thursday at 2:15 a.m., give the task job ID 1, and let it interact with that server's desktop. You can schedule scripts with familiar extensions, such as .cmd, .bat, and .vbs, to run. You can also use the At command to list all the jobs scheduled, then use the Delete command to delete a job. The code that Listing 2 shows deletes job 1.

Unfortunately, AT's UI was clunky, so Microsoft developed the WinAT scheduler, which shipped with the Microsoft Windows NT Server 4.0 Resource Kit. WinAT had a Windows-type GUI for managing the scheduling service. Despite the improved GUI, WinAT was still clunky and not very usable. But everything changed when Microsoft released Windows 2000. The new OS brought with it a scripter's delight in the form of the brand-new Task Scheduler service. I quickly upgraded my cron machine, and I've never looked back. Since then, I've upgraded the machine again to XP. Let's take a look at the XP Task Scheduler service's administrative software.

Scheduling Tasks in Task Scheduler
Although I'm using XP for my examples, you can just as easily apply what I'm describing here to the Win2K Task Scheduler. (Note that AT still exists in XP and Win2K if you want to use it; the OS adds AT tasks to the Scheduled Tasks folder.)

Task Scheduler is a service, and you can view it in the Microsoft Management Console (MMC) Services snap-in. (Note that Services is a standalone snap-in that you must add.) If you stop the Task Scheduler service, tasks won't run at their scheduled times. (By default, the Task Scheduler service is running.) You access the Task Scheduler service's GUI for scheduling tasks—i.e., the Scheduled Tasks GUI—through the Scheduled Tasks system folder. To open the Scheduled Tasks folder (by default, C:windowstasks) in XP, choose Start, All Programs, Accessories, System Tools, Scheduled Tasks. Doing so opens the Scheduled Tasks GUI, which Figure 1 shows. If you haven't scheduled tasks, only the Add Scheduled Task icon is visible. However, in Figure 1, you can see the AT task (i.e., At1) that the System account created earlier and two other tasks: Create User Accounts and SendMagicPacket. In the Scheduled Tasks folder, these two tasks appear as files with a .job extension.

From the Scheduled Tasks GUI, you can schedule any script, program, or even document to run at a time that's most convenient for you. For example, you can schedule a task to run daily, weekly, monthly, or at certain times (e.g., at system startup); change the schedule for a task; stop a scheduled task; or customize how a task will run at a scheduled time.

Adding a Task
To add a task, you double-click the Add Scheduled Task icon in the Scheduled Tasks GUI to start the Scheduled Task Wizard. I want to schedule a slightly modified form of SendMagicPacket.vbs from last month's article to wake up a set of PCs by setting the objWOL properties for each machine, then sending the magic packet to each machine in turn. Listing 3 shows the modified code for SendMagicPacket.vbs.

On the first page of the wizard, I browse to SendMagicPacket.vbs and select it as the application (or, in this case, script) that I want to run. Next, I schedule the script to run daily, as Figure 2 shows. On the next page, I specify the date on which the task should begin running (i.e., March 1, 2002) and the time at which it should regularly run (i.e., 2:00 a.m.). Now, I add the username and password under which the task will run. Finally, a summary of the task details appears. Figure 1 shows the finished task in the Task Scheduler GUI.

Customizing an Existing Task
After you've created a task, you can access that task's properties by right-clicking it in the Task Scheduler GUI, then selecting Properties. The properties dialog box has three tabs—Task, Schedule, and Settings. The Task tab, which Figure 3 shows, provides summary information for the task in question. On the Schedule tab, which Figure 4, page 14, shows, notice the Show multiple schedules check box. Selecting this check box lets you set values for different schedules. For example, you could run the same task at 2:00 a.m., 4:30 a.m., and 10:30 p.m. every weekday, then at 9:30 a.m. on Saturdays and Sundays. The Settings tab, which Figure 5, page 14, shows, has the bulk of useful task settings, such as whether to run the task while something else is running (i.e., the machine isn't idle), whether to run the task on a laptop that's running on battery power, how long to let the task run before forcibly terminating it, and whether to delete the task after it has run.

Note that customizing an AT task upgrades it to a normally scheduled task, thereby removing the task from AT's management. In such a case, you need to explicitly enter a user account and password for the task.

Task Administration
Deleting and renaming tasks is as simple as right-clicking the task in the GUI and selecting the appropriate option. You can also run a task at any time or end a running task in this way.

A few other control functions are available from the Advanced menu in the GUI. For example, you can stop and start the Task Scheduler service, pause Task Scheduler while you do something else, request to be notified of failed tasks (if you're an administrator), and look at the task log (by default, C:windowsschedlgu.txt).

One other administrative option relates to AT and bears a bit of explaining. You've seen that each task that you create through the wizard can run under a different account. However, all tasks that you create with the At command must run in the same user account, which in turn has to be the same account that the Schedule service in earlier Windows versions ran in. The default account was the Local System account, but you can use any user account. In XP, the Task Scheduler service has to run under the Local System account. However, you can designate an account other than Local System for tasks that you create with the At command to run in. To do so, click the Advanced menu in the Scheduled Tasks GUI, then select AT Service Account.

Using Tasks in Your Systems Administration
Rather than schedule all the tasks yourself, you can send tasks to users for them to schedule. To move tasks from your PC to the users' PCs, you simply drag the tasks from the Scheduled Tasks GUI into your C:windowstasks folder, then email the tasks to the users and instruct them to drag the tasks into this folder. However, two more common ways exist for moving tasks between machines. First, you can share the Tasks folder on each PC. Second, and the choice I opt for, you can set up a central server share structure (e.g., using XP's or Win2K's Dfs so that it's fault tolerant) that holds all your tasks, then you can have a task on each PC that updates its set of tasks from that share.

Let's look at the latter option. Let's assume that you have four departments (Finance, HR, Development, and Sales), each of which has a PC and a separate set of scripts. To share the Tasks folder on each department's PC, create a folder on SERVER1 (server1.mycorp.com) called Tasks. Beneath Tasks, create four folders corresponding to the four departments. Then, share the Tasks root folder and everything below it under the name Tasks. Use the code that Listing 4 shows—FinanceCopyTasks.cmd—as the scheduled task on all Finance machines. For the other departments, use the same script with the word Finance in the line

\server1.mycorp.comtasksfinance

replaced with the appropriate department name. The /v, /y, and /z switches correspond to requests to verify copied files, overwrite as needed without prompting, and restart across the network if the connection is lost, respectively.

Next Time
Next time, I'll show you how to use Active Directory Service Interfaces (ADSI) to make FinanceCopyTasks.cmd much better. For now, try experimenting with Scheduled Tasks to automate other systems administration tasks, such as automated user-creation. (For a particularly useful demonstration of task-scheduling functionality, see Tim Huckaby's Windows Web Solutions article "Sending Email from IIS," March 2002, InstantDoc ID 23811.)