| Downloads |
|---|
| 24945.zip |
The Task Scheduler that's part of Windows 2000 and Microsoft Internet Explorer (IE) 4.x and later is a powerful tool for scheduling scripts. However, Task Scheduler is also the source of many questions. Here are the answers to some of the questions that I've received about Task Scheduler and some tips you can use to debug task-scheduling problems.
I have a script that runs fine when I run it interactively but fails when I run it as a scheduled task. How can I debug this problem?
This question is probably the most commonly asked about scheduling tasks. Taking the following steps can help you troubleshoot the problem:
- Comment out the @Echo Off command at the start of your script (if applicable). Run the script interactively on the machine on which you've tried to schedule it, and note any failures.
- Make sure that the account under which you're running the script in Task Scheduler has sufficient permissions to accomplish the tasks inside the script. You can use various types of accounts with Task Scheduler, including Administrator accounts, user accounts, and service accounts that you've created specifically to run scripts. (Such service accounts should have enough permissions to run scripts but little more.) Try using a different account to schedule the task. For example, a service account might have insufficient permissions to complete the scheduled tasks, whereas your user or Administrator account has sufficient permissions. If you're using a service account that you've created, make sure that the account domain name and password you're using are correct and that the account isn't locked out.
- Search the script for Pause, Waitfor, Sleep, and Timeout commands. The Pause command displays the message Press any key to continue and stops the script's execution until someone presses a key. When you use Task Scheduler, typically no one is present to press a key, so the script never resumes its execution. Similarly, you can't use the Waitfor command in a script that you run with Task Scheduler. A component of the Microsoft Windows 2000 Server Resource Kit and the Microsoft Windows NT Server 4.0 Resource Kit, the Waitfor utility pauses a script and waits for a specified signal from another machine. The utility resumes the script's execution only when it receives that signal, which never comes when you use Task Scheduler. The Sleep and Timeout commands pause a script for a specified number of seconds. These commands can be a valuable tool, but if you specify a long sleep interval, the script might appear to have failed when it's simply waiting to begin running again.
- Check the script for user environment variables (e.g., %TEMP%) in the script. In Task Scheduler, these variables aren't available to the script.
- Make sure the paths to input files, output files, and utilities in the script are accurate. Specify all paths, unless you can use system environment variable to point to the file or utility. You can use a simple If Exist statement to test for the existence of files that you need and warn you if any are missing.
How can I change a user account or use multiple user accounts in a script?
A big improvement of Task Scheduler over the At or WinAt scheduler is that you can run different scripts under different accounts. In addition, you can switch from one user account to another account as the script runs, or you can have the script run under two user accounts simultaneously. Here's how you can accomplish these feats.
Changing user accounts midstream. Suppose that a script must run two Dir commands on different servers that have a shared directory: \\Server1\Share1 and \\Server2\Share1. To run the Dir command on \\Server1, the script needs to run under User1's account. However, User1 doesn't have necessary permissions to run the second Dir command on \\Server2, so the script must run the second Dir command under User2's account. To switch to a different user account, you need to make another IPC$ connection, as Listing 1 shows. The Net Use command at callout A in Listing 1 makes the second connection.
In some cases, you might want to break the connection with the first server before connecting to the second one. Severing unnecessary connections is a good cleanup practice if you have a script that uses different accounts to connect to different machines (which should be a rare situation). In such cases, you can use the Net Use command with the /delete (or /d) switch in code such as
Net Use \\server1\ipc$ /d
Note the first Net Use command at the beginning of Listing 1. You don't need to include this command if that's the account with which you've scheduled the task. (Including it doesn't hurt, though.)
Running multiple user accounts simultaneously. Suppose that you want to use two user accounts to simultaneously connect to two different shares on the same server. If you would have tried this action in the past, you would have received the error message The credentials supplied conflict with an existing set of credentials. In Task Scheduler, you can work around this problem by using the server's IP address or Fully Qualified Domain Name (FQDN) for the second connection. For example, look at the code that Listing 2 shows. The code makes the first connection the typical way by using Server1's name. The code then uses Server2's IP address to make the second connection.
To sever these connections, you can use the code
Net Use \\server1\ipc$ /d
for the first server and
Net Use \\10.0.0.1\ipc$ /d
for the second server.
I use Task Scheduler to run a script that maps drives. However, sometimes these mapped drives don't disconnect properly. How can I disconnect these "ghost" drives?
I've observed this phenomenon on a few occasions. You can't disconnect the drives the usual way—only a system reboot makes them disappear. Instead of mapping drives, I recommend that you use Universal Naming Convention (UNC) paths to make your connections. You will avoid not only ghost drives but also possible conflicts in scripts. If someone has added a drive to a server and you unknowingly use the same drive letter when you map a drive in a script, conflicts occur.
I have a complex script that takes a while to run and never seems to fully finish. What can cause this problem?
By default, Task Scheduler automatically ends tasks at 72 hours. If you have an extremely long task, you need to adjust this setting. Double-click the task (or right-click it and select Properties), and select the Settings tab. In the Stop this task if it runs for option, set an appropriate length of time. Another possibility is to rewrite the script in Perl. Because Perl executes faster, you can significantly reduce the script's long execution time.
I want to migrate my scripts from a Windows NT 4.0 server to a Win2K server and run them with Task Scheduler. Do you know of any pitfalls to avoid?
When migrating scripts, the main problems you'll encounter deal with the differences between the Microsoft Windows 2000 Server Resource Kit and the Microsoft Windows NT Server 4.0 Resource Kit. Most important, some of the utilities in the NT 4.0 resource kit (e.g., rmtshare.exe) no longer exist in Win2K. In addition, Microsoft moved some of the NT 4.0 resource kit utilities to Win2K Support Tools rather than the Win2K resource kit. Microsoft also slightly changed the syntax of certain tools in the Win2K versions. For example, in the Reg utility's Run command, the place in which you specify the remote server's name has changed.
Another problem might be the spaces in the paths to the Win2K utilities. By default, the Win2K resource kit and Win2K Support Tools install to folders whose paths contain spaces. Under certain conditions, the For command can fail if an embedded utility path contains a space. Installing the Win2K resource kit and Win2K Support Tools to a path that has no spaces will prevent problems later on.
I need to repeat a command every 10 minutes throughout the day. How can I schedule this task?
You could create a task that uses a loop to rerun the same command every 10 minutes and schedule that task to run just once a day. Or you could create a task that runs the command once and use the Task Scheduler's Advanced Scheduled Options to schedule the task to repeat every 10 minutes. I recommend that you repeat the task with Advanced Scheduled Options. That way, you can see whether the script ran successfully on the last run and when that run occurred. In addition, Task Scheduler gives you better control over starting and stopping the task.
The Add Scheduled Task Wizard takes too long to add scheduled tasks. Do you know of a quicker way to add tasks?
You can quickly add tasks several ways. You can drag tasks from one computer to another. (See the online Help inside the Task Scheduler topic JOB files, accessing scheduled tasks remotely.) You can also drag a script directly on to the Scheduled Tasks window, then assign a scheduled time and make other changes to the settings. When you use either technique, be sure to set the user account and password after you drag and drop the task or script.
What are the security implications when you use Task Scheduler?
Task Scheduler is as secure as the folder in which your scripts reside. If that folder's permissions are set improperly, you're exposing your network to serious security risks. You can imagine the damage a modified or renamed script might inflict if an unauthorized user had a destructive agenda. Make sure that the access to the scripts folder is limited to administrators only.
What are some best practices for using Task Scheduler?
After using the Task Scheduler over the past few years, I've found that these practices work well:
- Write your scripts so that they aren't server specific. That way, you can run a script on different servers without having to modify it.
- Test, test, and retest a script before you use Task Scheduler to run that script in a production environment.
- Store all your scheduled scripts in one folder. Use the Robocopy utility from the Win2K or NT 4.0 resource kit to copy all your scripts to a folder on a secondary server. That way, you can still run the scripts even if the primary server is disabled. Make sure the folders on both the primary and secondary servers have the necessary permissions to keep out unauthorized users.
- If you plan to use scheduled tasks to run several scripts on several servers, be sure that you keep records that detail each script's purpose, intended targets (i.e., which servers), and execution frequency. Store this information in a spreadsheet and review the spreadsheet periodically to see whether the scripts' existence, targets, and frequency still make sense in light of any changes in your environment. In the event of a total server loss, these records can become crucial to reestablishing your scheduled tasks quickly. Periodically back up your scripts to tape or CD-ROM and add the backup to your secured offsite storage facility.
- Launch tasks during off-hours, if possible.
- Monitor servers on which scheduled tasks are running to be sure they have the CPU and other system resources necessary to handle the tasks.
- Regularly check the Task Scheduler log (i.e., winnt\schedlog.txt) to make sure that the tasks have an exit code of 0, which indicates success.
OOPS
In the May 2002 issue of Windows Scripting Solutions, Figure 2 in "The Code Behind the Printer Mapping Utility" doesn't display the error messages that the figure was intended to illustrate. To view Figure 2 with the error messages displayed, go to the newsletter's home page (http://www.winscriptingsolutions.com) and enter 24598 in the InstantDoc ID box. Then, click the link for Figure 2 in the online article. We apologize for any inconvenience this error might have caused.
