Assessing the Crisis
IdentifySQLComputers.vbs, which Listing 1 shows, is largely based on the series of scripts I presented in "Remote Administration with WMI," February 2003, http://www.winnetmag.com, InstantDoc ID 37596. This script's purpose is straightforward. Based on a list of computer names you store in a text-based input file, the script uses Windows Management Instrumentation (WMI) to determine whether the target computers have SQL Server 2000 or MSDE installed. Because IdentifySQLComputers.vbs uses WMI, the target computers must be running WMI for the script to work. In Windows 2000 and later, WMI is a core component in the OS, so WMI is already installed and enabled. However, if you have computers running Windows NT 4.0 or Windows 98, you need to install and configure WMI on those computers to use IdentifySQLComputers.vbs.
The input file, Computers.txt, contains one computer name per line. For each computer in the file, the script displays one of the following three message types:
- GOOD—indicates that neither SQL Server 2000 nor MSDE are installed on the target machine.
- BAD—indicates that SQL Server 2000 or MSDE is installed on the target machine.
- ERROR—indicates that the target computer couldn't be reached. Possible causes include an invalid computer name in the input file, network connectivity problems (e.g., the computer didn't reply to a ping), or the computer isn't WMI-enabled.
Let's look at how IdentifySQLComputers.vbs works. As Listing 1 shows, I begin the script by defining the ForReading constant and initializing two variables: strInputFile and strServiceName. The strInputFile variable's value points to the Computers.txt input file. The strServiceName variable's value is the internal service name (i.e., the name the OS uses internally) of the service for which you're checking. In this case, I want to check the PCs for the SQL Server service because it starts the SQL Server Resolution Service, which is the SQL Slammer worm's target. The internal service name of the SQL Server service is MSSQLSERVER. (You can find a service's internal service name in the Service name field of the service's General Properties page in the Microsoft Management Console—MMC—Services snap-in.)
Next, I use the FileSystemObject's OpenTextFile method to open Computers.txt. OpenTextFile returns a reference to a TextStream object, which I assign to the variable named objTextStream. To retrieve this file's contents, I use the TextStream object's ReadAll method to read the entire input file into memory. I then call the VBScript's Split function and use the file's carriage return/line feed (which vbCrLf represents) as the delimiter. The Split function chops up the in-memory file and returns an array that contains the computer names. I assign the array to the arrComputers array variable, then close the input file.
Next, I set a reference to the WScript object's StdOut stream. This code is optional; I use it only for convenience. By setting a reference in this way, I can use the shorter StdOut.WriteLine notation instead of the more verbose WScript.StdOut.WriteLine notation to send text to the console. If you use the StdOut property, you must run the script with the cscript.exe host. You can't use wscript.exe because it doesn't understand STDIO streams (i.e., STDIN, STDOUT, and STDERR).
After setting the reference to the StdOut variable, I create a WshShell object. Later, I use this object's Exec method to ping each computer before trying to connect to it. The use of the Exec method highlights another script dependency. Microsoft added the Exec method to Windows Script Host (WSH) 5.6. Thus, you need to run the script on a computer that has WSH 5.6 installed. Windows Server 2003 and Windows XP include WSH 5.6 by default. If you're running the script on a Win2K, NT 4.0, or Win98 computer, you need to upgrade to WSH 5.6.
Prev. page
1
[2]
3
4
next page 
