Scrutinizing Scriptomatic

In my various Scripting Solutions articles, I walked you through the process of creating scripts as my grandfather would have: I made you walk uphill both ways in the snow while wearing shorts. (Perhaps it wasn't quite like that, but you get the idea.) As you've seen, this approach works well. However, once you start exploring the Windows Management Instrumentation (WMI) interface, you need a different approach. Before you write any code, you need to browse through the WMI software development kit (SDK) to find the objects you're looking for, then decipher which properties contain the information you need. Finding the correct class objects and properties can take a bit of practice and a lot of squinting at the screen. Fortunately, here's a tool on the Microsoft Web site that can help you with this drudgery: Scriptomatic.

In the documentation, Scriptomatic is billed as a utility that writes scripts for you. Well, it does and it doesn't. Scriptomatic does write working scripts—in fact, it's the basis for some of the scripts in the Microsoft TechNet Script Center. However, a novice scripter can't use Scriptomatic to create the types of scripts I've written for previous Scripting Solutions articles. (For links to those articles, go to http://www.windowsitpro.com/departments/departmentid/8/8.html.) Scriptomatic's basic function is to spit out property values for certain WMI classes on the local computer. To run the script on additional computers, pick up information from other sources, or evaluate or modify the data in any way, you need to edit the script manually. For this reason, I see Scriptomatic less of an automated scripting tool and more of a learning tool that lets you find the WMI classes and properties you need. After you have that information, it's a lot easier to open Notepad and create a more robust script that has some flexibility built into it. Using Scriptomatic takes away some of the donkey work of finding WMI classes and properties.

Scriptomatic is most useful when you have a little background in WMI. If you don't have that background, check out the Learning Path box. If you're familiar with WMI, read on and learn how to obtain and use Scriptomatic and how to edit its scripts.

Getting Started with Scriptomatic
The first step is to download the self-extracting file from the Microsoft Download Center. Go to http://www.microsoft.com/downloads, search for scriptomatic, then click the Writing WMI Scripts Using the Scriptomatic Utility link. Download scriptomatic.exe. When you run scriptomatic.exe, the WinZip Self-Extractor decompress two files—scriptomatic.hta and a documentation file—in the C:WindowsScriptsScriptomatic directory.

By default, Scriptomatic doesn't include any mechanism for connecting to remote computers, so you'll need to develop your scripts from a computer that will have all the WMI classes you need. This limitation won't necessarily hurt you—just make sure that you run Scriptomatic on a computer that has the same OS and WMI version as the computer on which you plan to run your WMI script.

If you must run Scriptomatic on a remote computer, here's a workaround you can use: Open scriptomatic.hta in Notepad. In the code, find the two instances of strComputer = ".". In each instance, replace the period (.) with the name of the target remote computer (e.g., strComputer = "atl-ws-01"). Save the file and, voila, you can retrieve WMI classes from that remote computer. Alternatively, the WMI CIM Studio in the WMI SDK lets you connect to any computer on your network that's running the WMI service.

Using Scriptomatic is straightforward. When you launch the tool, it automatically inventories the WMI classes available on the local computer, then displays the dialog box that Figure 1 shows. When you click the drop-down list in Figure 1, you get a list of Win32 classes available on that computer. (Only classes found in the rootcimv2 namespace are included because those classes are the most relevant for Windows scripting.) When you select a class, Scriptomatic automatically creates a script that, when run, displays all the class's properties on screen. For example, if you select the Win32_OperatingSystem class, you'll get a script similar to the one that Figure 2 shows. From this script, you can learn the proper names and format of the class's properties.

All the scripts created by Scriptomatic use basic VBScript statements and the Windows Script Host's (WSH's) Echo method to send, or echo, output to the screen. You can run a script from Scriptomatic or as a standalone .vbs file. To run a script from Scriptomatic, you simply click the Run button. If you plan to run the script as standalone file, you need to save it as a .vbs file. Before you run the script, I strongly recommend that you open a command-shell window and run the command

wscript //h:cscript //s

to make the command line (i.e., cscript.exe) rather than Windows (i.e., wscript.exe) the default script host. Otherwise, each echoed line of output requires you to click OK to progress to the next line. If you use Scriptomatic on a class such as Win32_NetworkAdapter, your hand will be immobilized with repetitive motion syndrome in no time flat. (If you use the Run button to launch a script, Scriptomatic automatically runs it under cscript.exe.)

Figure 3 shows part of the output from running the Win32_OperatingSystem class script in Figure 2. As you can see, the script retrieves and displays the values of the class's properties. However, the output might not include all the properties. The output doesn't include properties whose values aren't set. And if you're using the initial release of Scriptomatic, the output won't include properties whose values are stored as arrays. The first release of scriptomatic.hta (which has a date stamp of August 9, 2002) doesn't support properties of type Array. If the Scriptomatic script encounters an array, it tries to echo the value of that array and fails. However, because all Scriptomatic scripts start off with VBScript's On Error Resume Next statement, this error isn't fatal. Instead, the script simply moves on to the next line. Thus, although Scriptomatic exposes properties that return arrays, the script doesn't return any array values. Microsoft addressed the array limitation in the second release of scriptomatic.hta (which has a date stamp of November 6, 2002). However, this release is available only on the CD-ROM that accompanies the Microsoft Windows 2000 Scripting Guide. Scriptomatic 2.0 (which is actually the third release) will also support arrays.

Scriptomatic 2.0, which is scheduled for release later this year, offers other improvements as well. For example, this new version will let you choose which computers to run the tool on, let you select the language you'd like to use (Perl and JScript will be options in addition to VBScript), and let you select the output format. Scriptomatic 2.0 will also show you all classes in all namespaces.

Collecting Property Information
How can you use the information you gather with Scriptomatic? For starters, you can use it to track down the properties and their values. For example, Windows Server 2003 has a number of WMI providers not found in previous versions of Windows. One of them is the Terminal Services WMI provider, which lets you access Windows 2003 Terminal Services settings. Suppose you want to create a script that changes the default location of each remote computer's home directory. The Terminal Services WMI provider includes 18 classes of objects related to Terminal Services, including

Which class contains the setting you want? To find out, you could open all 18 classes in WMI CIM Studio and read through each class's property values. However, it's much easier and more reliable to use Scriptomatic. For each class, you simply generate and run a script, then scan the displayed property information. A quick perusal of the Win32_TerminalServiceSetting class script's output reveals that this class has a property called HomeDirectory, which specifies a computer's home directory.

The next step is to find out what the values for that property mean. Some property values are easy to figure out. For example, for the Win32_TerminalServiceSetting class's ActiveDesktop property, it makes sense that a value of 1 enables Active Desktop and a value of 0 disables it. (It's a good idea, however, to double-check that property values mean what you think they do.) But some values are less intuitive—what does a value of 0 mean for the class's UserPermission property? To decipher such values, you can poke around GUI-based tools and mentally map GUI settings to class properties. In this case, a quick look at the Terminal Services Configuration tool reveals a User Permission setting, which has two possible values: a value of 0, which enables Full Security, and a value of 1, which enables Relaxed Security. Other resources that can help you track down the meaning of property values include the Microsoft Developer Network (MSDN) WMI Reference (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/wmi_reference.asp) and Google (http://www.google.com).

Editing the Scriptomatic Script
After you run the Scriptomatic script to find the property information you need, you can save the script for editing. To do so, click the Save button to open a dialog box like the one that Figure 4 shows. Be sure to save the script as a .vbs file.

You can use Notepad or another text editor to edit the .vbs file. GetTSStatus.vbs, which Listing 1 shows, is an example of what the finished script might look like. This script retrieves and displays the Terminal Services settings for the local terminal server or for each specified terminal server. (The terminal servers must be running the WMI service.) To create GetTSStatus.vbs, I made two major modifications to the Scriptomatic script for the Win32_TerminalServiceSetting class:

Modification 1. I wanted to run my script on several servers, so I modified the Scriptomatic script so that it would run not only on the local terminal server but also on any specified remote terminal servers. I accomplished this capability with command-line arguments, an If...Then...Else statement, and a Select Case statement. I initially devised this system for a script that I discussed in "Check Service Status on Local or Remote Servers," March 2004, InstantDoc ID 41670.

To begin, I decided to use the following command to launch the script:

GetTSStatus.vbs [argument]

where argument can be one of the following:

No argument is needed to run the script on the local terminal server.

When no command-line argument is present, the If...Then...Else statement that callout A shows tells the script to connect to the local terminal server. When an argument is present, the Select Case statement that callout B shows evaluates the argument to determine on which terminal servers the script should run.

If you plan to adapt GetTSStatus.vbs for use in your environment, you'll need to adapt the Select Case statement in two places. In the Case "file" code, you need to customize the INPUT_FILE_NAME constant. Replace C:ScriptsServers.txt with your input file's pathname. (In the input file, put each terminal server's name on a separate line.) In the Case "all" code, you need to customize the Set colComputers line. Replace LDAP://CN=Computers, DC=labyrinth, DC=com with the path to the servers on which you want to run the script.

Modification 2. Because I knew that I wanted to run GetTSStatus.vbs on more than one terminal server, I adapted the Scriptomatic script so that it includes the name of the server when it displays the server's Terminal Services settings. As callout C in Listing 1 shows, I accomplished this by adding the sComputerName variable (which contains the terminal server's name) to each Echo statement in the TSServStat subroutine.

What Scriptomatic Does Well
It's overstating the case to say that Scriptomatic will write your scripts for you while you work on your golf game or Space Invaders scores. The tool has a number of limitations, with the biggest limitation being that it creates scripts that do one thing and one thing only: spit out a class's property values. However, what Scriptomatic does do (and does well) is help you obtain WMI class and property information. After you have that information, you can create robust scripts that perform a variety of tasks.