Real-World Scripting: Create a High-Availability Environment for Your Scripts

Centralize the storage and execution of your scripts on your primary server, and put the scripts in a common directory. Centralizing your scripts in a common directory speeds deployment to the secondary server because you don't have to search and replace the server's path in the scripts. However, you can centralize only those scripts that you can run over the network. You can't centrally store scripts that require local execution.

Adapt your scripts so that they're server independent. Use environment variables such as ComputerName, SystemRoot, and Temp instead of hard-coding the server name. That way, you don't have to alter the scripts before you run them on the secondary server.

Set up the second server that you'll use to run your scripts if your primary server fails. You can use the Robocopy utility from the Microsoft Windows NT Server 4.0 Resource Kit to duplicate the primary server's script directory on the secondary server. Schedule a .bat file that triggers Robocopy periodically to refresh the secondary server's script directory so that the directory stays up-to-date. If you use Microsoft Visual SourceSafe (VSS) to manage your scripts, have VSS deploy them to both the primary and secondary server. Install all the files and extensions you need to run the scripts (e.g., Windows resource kit utilities, ActivePerl and related extensions, Windows Script Host—WSH) on the secondary server, and verify that they all run correctly. If you use the Task Scheduler to run your scripts, set up the scheduled jobs with permissions and the scheduled runtimes on the secondary server. Clear the Enabled check box on the Task properties dialog box so that you can switch to the secondary server with only a few clicks. To clear this check box in NT, double-click My Computer, open Scheduled Tasks, right-click the scheduled job, and select Properties from the drop-down menu. In Windows 2000, open Control Panel, open Scheduled Tasks, right-click the scheduled job, and select Properties from the drop-down menu.

Create a script configuration and deployment document for each script. This document needs to include all the details necessary to understand a script's operation, placement, and dependencies. Figure 1, page 7, shows an example of this document. You can use this example document as a starting point, modifying it to fit your environment and corporate policies. If you ever accidentally delete a crucial task or lose a server on which you're running scripts, this document can be a big help in getting scripts back online and back on schedule.

Use the script configuration and deployment document to create a master monthly calendar of your scripts and their execution schedule. You might also want to include the backup schedule and other scheduled events, such as maintenance outages, and high load times, such as end-of-month reports.