The script accepts input that you supply when you run the script, indexes the content, and stores it in the Arguments collection, as the code snippet in Listing 2 shows. This code sets sComputerName equal to each argument's value in turn and prints the name of the computer so that you can identify which output goes with which machine. The final script will output the computer's service information below the computer's name.
What if a supplied server name isn't valid—for example, if you misspell the name or if the server is offline? This question is a good one because you can't get service information for a computer that doesn't exist. For now, we'll simply use the On Error Resume Next statement to tell VBScript to ignore anything that goes wrong and continue running the script.
Alternative Input as Arguments
Server names aren't the only arguments you might want to supply. To tell the script where you want it to get its input, you can specify that you want the script to read its input from a text file in which you've stored a list of server names or that you want it to check all servers in the domain. Alternatively, you can tell the script that you need help. If you don't provide any arguments, the script can assume that supplied arguments are the names of the computers on which the script should run. Let's look at how to test for all these possibilities. (For now, we're simply organizing the script so that it can work differently according to the input it gets. Later, we'll make the script do something with this information.)
If the person running the script doesn't supply any arguments, the script should run on the local computer. To check services on the local computer without hard-coding or supplying the local server's name, you can use WMI syntax. You can specify the current computer by providing its name, but you can also use a period (.) to tell WMI to run this script on the local computer. To make the script run locally by default, have it check the value of Wscript.Arguments(0), which is the first item in the Arguments collection. If the item is empty, the script will set the value of sComputerName to a period.
Another option is to make the script get the list of server names from a file. The text file's location shouldn't change, so you can hard-code it into the script. However, you must specify that you want the script to read a file. To do so, you can test to determine whether the value of Wscript.Arguments(0) is file.
You can configure the script to run against all computers in AD or some subset of computers that you code into the script. For the sake of simplicity, let's run it against everybody. If a user wants to check service status on all computers running WMI, the user would type all for the argument. (Similarly, you could let users supply the name of an organizational unit—OU—as an argument, test the input to determine whether it's an OU, then check only those computers in the specified OU.)
Because this script can accept a variety of input types, it requires some instructions. In my previous columns about scripts that take arguments, the notion of taking no arguments whatsoever wasn't an option. If the person running the script didn't provide the necessary arguments, the script informed that person that it required input and stopped running. That approach won't work with this script because not providing arguments is now a valid option—the script will simply run locally. Therefore, let's give the person running the script the ability to use the familiar /? command to obtain help with the script. If the script sees this character combination in Wscript.Arguments(0), it will print out instructions for using the script.
I've used the Select Case statements in many previous columns, so you won't be surprised that I use it in this script to check the value of inputs. Listing 3 shows an abstract of the portion of the script that decides how to attack input. The code converts the input to lowercase (to avoid case discrepancies; ALL, All, and all aren't identical string values), then tests to determine the value of Wscript.Arguments(0) and executes some code according to this value. Obviously, the final script will do more than merely report the way the script will run, but Listing 3 shows the general structure. You now have the mechanism for providing input other than server names.
Reading from a Text File
If you have more than a few server names to check, or if you want to always check the same servers, storing the names in a file is easier and more accurate than typing them in each time you run the script. If you'll always run the script from the same computer, you can store the server names in a file called servers.txt (one server name to each line), then call that file from the script. To read the file, you use a VBScript COM object called a File System Object (FSO)—VBScript doesn't know how to interact with files, but it knows how to interact with COM objects. FSOs can represent files or folders; in this case, you would use the FSO to point to and read from the text file in which you've stored your server names. Because the name of the file won't change, you can store it in the script as a constant instead of a variable, as Listing 4 shows.
If you want to create a script that can read files from different sources without requiring you to edit the script, you can make the filename the first argument and the path to the file in question the second argument. Simply set the value of INPUT_FILE_NAME equal to Wscript.Arguments(1) because that argument will contain the path.
)
Andrew Whitton May 14, 2004