Here's a look at how to run a WMI script one time to make a needed change to every system on your network, along with a discussion on WMI security.
One of the great things you can do with WMI scripting is to create a text file with a list of host names that can serve a single script across several machines. This feature can make WMI a powerful tool in the enterprise. In this article, I'll explore this feature and take a look at WMI security.
In my previous articles on scripting with WMI ("Automate Windows administration with WMI scripting" and "Delve deeper into WMI scripting for Windows administration"), I discussed using WMI scripts on local machines only. As useful as that might be, it's of little value when you need to run the same script against 500 machines in your enterprise. Fortunately, though, there's a way to do that without running the script 500 times and changing the host name each time. I'll show you how.
In the second article of the WMI series, I made a reference to a host name in a WMI script that looked like the one in Listing A.
In this example, Admin412 is the host name and is inserted into the WMI path with the variable strComputer. Obviously, we can't use that same methodology for 500 computers. Instead, we'll take some steps that are fairly straightforward but require some new concepts:
- Create a text file that contains the host names of all computers.
- Read the names in the text file into the VBS Dictionary object.
- Loop through all the names in the Dictionary object to accomplish your goal.
You're probably asking what the Dictionary object is and how you get a script to read a text file. In previous articles, I introduced three VBS objects: FileSystemObject, Shell, and Network. The Dictionary object is a fourth VBS object that acts as an array. It’s true that you could simply create an array and use that, but to do so would require that you predefine the size of the array or constantly modify the size as you go along. The Dictionary object lets you get around that requirement.
As with the other VBS objects, you must create an instance, or instantiate the Dictionary object with the code shown in Listing B, which should look fairly familiar. In order to add anything to the dictionary, you must use the Add method, as you'll see below. When you add an item, every item in the dictionary list will have not only its host name value but also a key, which will be a number from zero on up. So, in adding an item, you must specify both its key and text value.
Opening and reading a text file into the VBS Dictionary object
To open a text file, we must first instantiate our old friend FileSystemObject and then use the OpenTextFile method. When you open a text file in VBS, you must also specify whether you're going to read it or write to it. You can't do both in the same operation. In this example, all you want to do is read the file, so you can use the ForReading parameter.
Let’s say we have a text file named hostnames.txt that contains the host names of all the computers on our network. To open that file for reading, we'd use the two lines of code shown in Listing C.
To read each line in the text file, use the ReadLine method. Now you have all the ingredients for reading a list of host names into a dictionary. You can use that dictionary within a WMI script to elicit information from every computer on the list.
Let's begin to loop through the entire text list of host names, one at a time, and add them to the dictionary. How will you know when you've reached the end of the list? Fortunately, you can use a property called AtEndOfStream for the text file object. You'll also initialize a counter called "i" that will serve as a one-up key for each item read. Listing D shows the complete code.
To the Dictionary object, the first few entries might look something like this:
The keys 0-2, in this case, are not important for our use, nor will we refer to them in our script. It’s just that the Dictionary object requires a key for each entry.
Using dictionary entries in place of parameters
Now that all of the host names are in the Dictionary object, you can use that object in the second half of the script in place of parameters. Let’s say that you want a list of the NICs installed in each computer on the network, and that the host names are now stored in the Dictionary object. Here's what you'll do:
- Use a For Each loop and assign each host name to the strComputer variable one at a time.
- Use the ExecQuery method to retrieve the description of the NIC for that computer.
- Use the Echo method to display the host name and its NIC description.
- Go to the next host name in the Dictionary object.
The code for that might look like the one in Listing E. So this code, together with the code shown above for reading from the text file, will result in a list of all host names and the type of NIC installed in them. And, of course, if you were to redirect this script to a text file, you would have a printable list at your fingertips.
As you can see, WMI can be a powerful tool for the enterprise administrator. But what about WMI scripts that get into the hands of the wrong person? What safeguards are there against a WMI script being used by unauthorized persons?
There are essentially two levels of security inherent in WMI scripts. The first is Namespace security, in which you can control the level of interaction of your network users with any of the WMI namespaces, the same way you can with folders. If you go to the Computer Management MMC, right-click on WMI, and select Properties, you'll see the dialog box shown in Figure A. In the Security tab, you can select a namespace and specify security levels.
The second level of security is the Windows operating system itself. Just because a person launches a WMI script does not necessarily mean that it will run. That person must be an authenticated user and have the permissions necessary. In most cases, this means the person running the script must be at least a local administrator on the computer that the script is running on.
This article, and the two that preceded it, have only introduced the vast capabilities of WMI scripting. As with any other form of scripting, the only way to really learn it is to practice (but not in a production environment). Use the resources available at Microsoft’s Web site, and don’t be afraid to make mistakes when experimenting on a test network. You'll find that the effort is well worth the time once you learn that you can significantly ease your administrative burden with WMI.