When intResult contains a value of 0, the script interacts directly with the tape device and ejects the backup tape. To accomplish this interaction, I use a little-known command-line utility called the Removable Storage Manager (RSM) utility (rsm.exe). Designed for use with tape autoloaders, this utility tracks tape usage, ensuring that the autoloader inserts the correct tape into the streamer before a scheduled backup commences. (For more information about rsm.exe, search on rsm in XP's Help file.) The strRSMCmd variable stores the call to rsm.exe. The call requests an eject of the medium, specifies a physical filename (the /pf parameter) that matches the strWeekday variable, and specifies that the tape eject should start immediately (the /astart parameter).
You'll need to customize BackXP.vbs for your own use. First, you must change the strParam1 through strParam5 lines to match your own backup requirements. You can obtain the complete list of NTBackup parameters by clicking Start, Help and Support and searching for NTBackup. You must also modify the BACKUP_FILE_PATH constant so that it contains the path to your .bks file; this path must have the at (@) symbol as the first character.
Restoring Dfs Roots Through a Script
Dfs, which came of age with Win2K, is a strategic storage management solution that gives administrators a more flexible way to centrally manage their distributed resources. With Dfs, administrators can create simplified views of folders and files--that is, a virtual organization called a namespace--regardless of where those files physically reside in a network. Administrators can use Dfs to automatically replicate entire namespaces across multiple physical locations, thereby letting users access the resources on a network closest to them and providing fault tolerance should a node become unavailable. (For more information about Dfs, see http://www.microsoft.com/windowsserver2003/techinfo/overview/dfs.mspx.)
Windows Server 2003, XP, and Win2K Server include Dfscmd, a root-management tool that lets you manage Dfs from the command line. If Dfscmd isn't installed by default, you can either install it from the Support Tools folder or download it from the Microsoft site. (The Win2K download site is http://www.microsoft.com/windows2000/downloads/servicepacks/SP4/supporttools.asp.) For more information about dfscmd.exe, see http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=/windowsxp/home/using/productdoc/en/dfscmd.asp.
The DFSRootBackup.vbs script, which Listing 2 shows, iterates through a series of four servers (Alpha, Beta, Charlie, and Delta) and executes Dfscmd to create a batch script that you can use to restore each server's Dfs root folder. You place the batch script on a separate server; the batch script logs its results in that server's Application event log at key points.
Let's look at DFSRootBackup.vbs in more detail. The first constant I declare--DFS_DEST_PATH--should be customized for your own environment. DFS_DEST_PATH is a Universal Naming Convention (UNC) path to a share that I created on a fifth server called Echo. Alpha, Beta, Charlie, and Delta are the servers that host Dfs root folders. Echo will contain the backups of these folders.
The second and third constants contribute to a command that the script will create, which will look something like this:
dfscmd.exe /view \ Alpha\DFSRoot /batch >>
"\\Echo\DFSBackup Alpha DFS Batch Script.txt"
(The command wraps to several lines here because of space constraints.) This command uses the /view parameter to retrieve details for the specified Dfs root folder (on server Alpha, in this case) and the /batch parameter to then return a batch script that you can use to restore the root folder. The command places the batch script on server Echo in the designated file. The CMD_PART1, CMD_PART2, and LOGFILE constants represent parts of the dfscmd.exe command that don't contain the specific server name (e.g., Alpha). You can change the name of the DFSRoot folder in CMD_PART2 and the text in LOGFILE to suit your needs. After declaring some familiar constants and variables, I declare the server array. Scripting provides many ways to store (or even dynamically generate) a list of servers. I decided to use VBScript's Array function because it's an easy way to generate an array of server names representing those servers that have a Dfs root.
After the declarations, the script writes an entry in the Application event log on the client running the script, telling the log either that the script has started successfully or had errors. The For...Next statement iterates through the recently created server array. The same actions happen within each iteration. First, the FileSystemObject object's FileExists method checks whether the new log file--which represents the batch script--exists. When the file exists, the FileSystemObject object's DeleteFile method deletes it. Next, the strDFSCmd variable holds the dfscmd.exe command, which is immediately passed to the WshShell object's Run method. Script execution pauses until the command completes. Depending on the value that dfscmd.exe returns (0 means success; 1 means failure), the script writes a success or failure message to the Application event log.
To be absolutely sure that the resulting batch script contains no errors, the code needs to scan the event-log file for the word error. One way to accomplish this would be to use the FileSystemObject object's ReadAll method to read the entire file. However, this method wastes memory resources for large files. Instead, I use a simple line-reading loop, which adds each line in the log file to a long text string. Next, the InStr function determines whether the word error is contained in the file, then writes to the event log a failure or success message, depending on whether the line-reading loop found an error. Then, the next iteration of the loop starts to read the next line of the file and check for the word error. After the last line of the file is read and checked for the word error, the LogEvent method logs a success event in the Application event log to indicate that the script has finished.
Enhanced Flexibility
BackXP.vbs and DFSRootBackup.vbs demonstrate some simple methods you can use to add flexibility to built-in Windows utilities, and you can easily customize these scripts to fit your backup environment. (For an enhanced version of BackXP.vbs, see the Web-exclusive sidebar "Enhancing BackXP.vbs".) In addition, you can apply these techniques to other Windows utilities. For example, you can apply these techniques to update values in Active Directory (AD), DNS, or other system configuration settings.