The Scriptomatic Tool

Write WMI Scripts Like the Pros!

By The Scripting Guys

If you're like most of us, you've spent many sad hours staring out the window, watching your fellow system administrators drive by in their Jaguars and Porsches, preparing to flit off to Monte Carlo or some other exotic locale. And no doubt you've said to yourself, "Man, I know just as much about system administration as those guys do. Why do they get the fancy cars and the yachts and the Rolex watches?"

Well, we're here to let you in on a little secret. Why do some system administrators get fancy cars, yachts, and Rolex watches? It's because they know how to write WMI scripts, and you don't!

Well, actually, that's a lie. If you know any system administrators who are driving fancy cars, it's more likely that they're embezzling company funds than spending their time writing WMI scripts (WMI, of course, stands for Windows Management Instrumentation). The truth is, learning how to write WMI scripts is not going to make you rich and famous (we just wish someone had told us that before we took this job). On the other hand, WMI scripts can make your system administration life much easier; scripts can carry out many of those tedious and repetitive chores that seem to fill your day, and thus free up plenty of time for you to do other things.

Um, sure, like embezzling company funds, I guess. But you didn't hear that from us.

Of course, you're probably thinking, "But why should I waste my time writing WMI scripts? After all, haven't those Scripting Guys already written every possible WMI script, and posted it to the TechNet Script Center?"

Sorry to disappoint you, but, no, we haven't. In fact, if you've ever browsed through the Script Center, you've likely had two reactions. At first you say, "Wow, look at all these scripts!" But then, after catching your breath, you probably add "Wait a second. Where are the WMI scripts that return information about video cards? Where are the WMI scripts that return information about network adapters? Where are the WMI scripts that return information about [choose any and all that apply: processors, motherboards, batteries, USB hubs, IDE controllers, keyboards, monitors, sound cards, etc. etc. etc.]"

Hey, we'll admit it: the truth is, we're too lazy to write all those scripts ourselves (besides, there's just too darn many of them). But we have done the next best thing: we've developed the non-patented Scriptomatic, the magical new device that lets you write WMI scripts even if you don't know the first thing about WMI!

Disclaimer Does this mean we recommend that you not learn WMI? Needless to say, the answer is no; after all, we are writing a book designed to teach you WMI scripting. In fact, for those of you interested in learning WMI from the ground up, we have an online tutorial series.

On the other hand, we recognize that you are busy, and that the reason you visit a Web site like the Script Center is because you don't really have the time to learn WMI, let alone sit down and write a WMI script. And that's why we created the Scriptomatic. As long as you can accept a few limitations, the Scriptomatic will write your WMI scripts for you. It will even wash your car, wax your floors, and slice and dice vegetables!

Well, OK. But it will write your WMI scripts for you.

The Scriptomatic is not supported under any Microsoft standard support program or service. The Scriptomatic is provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the Scriptomatic and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the Scriptomatic or sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Before we do anything else, let's explain the Scriptomatic and what it does. The Scriptomatic is an example of a Hypertext Application, essentially a Web page that uses a .HTA file extension. When you fire up the Scriptomatic, it automatically loads the names of a selected set of WMI classes (for example, Win32_SoundDevice and Win32_NetworkAdapter) into a dropdown list box. After the Scriptomatic finishes loading, you simply select the desired class and, voila! You have a script that returns information from, say, Win32_SoundDevice or Win32_NetworkAdapter.

Brief aside Why is the Scriptomatic a Hypertext Application? Two reasons. First, we wanted to write the Scriptomatic using scripting code, and using nothing more powerful than Notepad. This was not only a fast and easy way to build the Scriptomatic, but also demonstrated that we practice what we preach: we really do use scripting to accomplish useful tasks. (Although the Embezzlomatic remains a distant dream.)

Brief aside No. 2 Don't worry; HTAs might allow you to bypass the "not safe for scripting" warnings, but they don't bypass other kinds of security, like NTFS permissions. And if you are retrieving information from a remote computer, you still have to be an administrator on that remote machine. An HTA doesn't let you bypass those restrictions either.

The Scriptomatic relies on two important principles, beginning with the fact that you can use WMI to return complete information about WMI. That might not seem to make a lot of sense, so let's put it this way: you can write a simple WMI script that tells you what WMI classes are available on a computer, and also tells you what properties and methods are available within each class. This is the whole idea behind the Scriptomatic: the Scriptomatic uses WMI to determine what WMI classes are available, uses WMI to deduce the properties for a specified class, and then automatically constructs a script that can be used to return values for these properties.

The second guiding principle behind the Scriptomatic is the fact that most WMI scripts follow the same pattern (see our tutorial for an explanation of this pattern). Typically, WMI scripts are designed to return information about something, be it a monitor, an uninterruptible power supply, or a hard disk. And most of these scripts follow the same pattern: you connect to a computer, you connect to the desired class, you echo the values of each property within that class. By following this same pattern, we were able to create a generic script template that can return information for most of the "interesting" WMI classes on a computer (we'll explain what we mean by "interesting" in a minute).

But you don't really care about that, do you? You just want to see the Scriptomatic in action, don't you? Hey, no problem; download the file, and start it up. When you do, you'll see something similar to this:

Pretty exciting, huh? But just sit tight; after a minute or two, the most interesting and useful WMI classes will pop up in the Scriptomatic. Your Scriptomatic will then look like this:

If your browser does not support inline frames, click here to view on a separate page.

So now how do you write a script using the Scriptomatic? Believe it or not, this requires just two steps: 1) Click the dropdown list box containing all the available class names, and, 2) Select the desired class. Instantly, a new script will appear in the Scriptomatic, just like this:

If your browser does not support inline frames, click here to view on a separate page.

It's like a dream come true, isn't it? (You guys really need to find better things to dream about.)

In and of itself, that's reasonably cool. But the Scriptomatic can do far more than merely write a script for you. For example, the Scriptomatic automatically returns values for every single property. But what if you don't want the values for every property, what if you want to return the values for only a few selected properties? No problem; the script generated by the Scriptomatic is fully-editable. Just delete the lines of code that you don't want.

Tip of the day The Scriptomatic is designed to return information about the local computer. But what if you want to return information about a remote computer? Piece of cake. You might notice that the second line in every Scriptomatic script is this:

strComputer = "."

To run a script against a remote computer, just change "." to the name of the remote computer. For example, to return information from a computer named MyWebServer, change the second line of the script to this:

strComputer = "MyWebServer"

And what if the script happens to be a keeper, something you'd like to hang on to so you can use it over and over again (or that you can return to and modify later)? Hey, just click the Save button, and give the script a name (make sure you use a .vbs file extension). The Scriptomatic will then save whatever happens to be in the edit box at the time.

And what if you don't trust us, what if you don't believe these are real, live, ready-to-use scripts, what if you're thinking, "Sure, I'll go through all the trouble to save this script, and then I'll have to find it and run it, and when I do, nothing will happen." Well, if you want to run the script, just click the Run button. A command window will open up, and the script will run.

Disclaimer It's perfectly safe to run any of the Scriptomatic scripts, because all they do is return information; none of the Scriptomatic scripts configure anything on your computer. Cross our heart, here's the worst case scenario: you create a script to return information about the tape drives on a computer. You run that script, only it turns out that computer doesn't have any tape drives! Omigosh, what happens then ?!? Well, the script goes ahead and runs, it just doesn't return any information. That's it, that's the worst thing that can happen.

Honest.

Tip of the day No. 2 We originally designed the Scriptomatic as a quick and easy way to write scripts. After we finished it, however, we realized that we had -- accidentally -- created a handy little admin portal. Want to know what services are installed in a computer? Start the Scriptomatic, select the Win32_Service class, and then click Run. Want to know more about the shared folders on the computer? Select Win32_Share and click Run. Dying to know about the installed hard disks? Select Win32_DiskDrive and -- you got it. Using this one tool (as opposed to, say, a collection of MMC snap-ins), you can ferret out all sorts of interesting information about a computer. And if you'd like to ferret out information about a remote computer, well, just change the computer name, and have at it.

As we implied above, these are real, live, ready-to-use scripts. For example, here's the actual script that will be generated when you choose Win32_Registry as the class (assuming that you are running on Windows XP; if you are running on a different version of Windows, the properties of Win32_Registry might differ slightly):

On Error Resume Next
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Registry,,48")
For Each objItem in colItems
     Wscript.Echo "Caption: " & objItem.Caption
     Wscript.Echo "CurrentSize: " & objItem.CurrentSize
     Wscript.Echo "Description: " & objItem.Description
     Wscript.Echo "InstallDate: " & objItem.InstallDate
     Wscript.Echo "MaximumSize: " & objItem.MaximumSize
     Wscript.Echo "Name: " & objItem.Name
     Wscript.Echo "ProposedSize: " & objItem.ProposedSize
     Wscript.Echo "Status: " & objItem.Status
Next 

And here's the actual output generated by that script:

Caption: Registry

CurrentSize: 3
Description: Registry
InstallDate: 20011029113047.000000-480
MaximumSize: 41
Name: Microsoft Windows XP Professional|C:\WINNT|\Device\Harddisk0\Partition1
ProposedSize: 41
Status: OK

Is that sweet or what?

So is the Scriptomatic the answer to all your scripting needs? Well, not quite. For all its many virtues, the Scriptomatic does have a few limitations:

• The Scriptomatic is designed to work with only a subset of classes, the Win32 classes that return property values. There are hundreds of WMI classes, but many of these are of little use to script writers, primarily because they don't return data (this is true for many of the CIM classes, like CIM_Service, which does not return data about the services installed on a computer). Rather than display all the classes and let you try to figure out which ones are useful and which ones aren't, we made an executive decision to limit the displayed classes to those that: 1) return data; 2) are found in the root\cimV2 namespace; and, 3) have names starting with Win32_. This makes the Scriptomatic much easier to work with, and probably covers 98% of the more useful and interesting WMI classes. Of course, that also means that 2% of the more useful and interesting classes are left out (this value is higher on Windows .NET Server, which puts a great many interesting and useful classes in namespace other than root\cimv2).

  For beginning scriptwriters working on, say, Windows 2000, we don't believe this will be much of a problem. In future versions of the Scriptomatic, we'll see if we can come up with a way to provide more complete coverage. And what if you're an advanced scriptwriter, and already working on .NET Server? Well, remember, the Scriptomatic is just an HTA; that means you could open it up in Notepad and modify the code for loading in classes. If you're an experienced WMI scripter, this should be trivial.

  If you're not an experienced WMI scripter, be forewarned that opening the Scriptomatic in Notepad immediately invalidates your warranty.

  Or at least it would if we actually offered a warranty.

• The Scriptomatic won't return values for all properties. We confess: we cheated a little when we did the Scriptomatic. Some WMI properties come back in the form of arrays (for example, the Win32_Printer class has a Capabilities property that returns an array of printer capabilities). Iterating through an array requires additional code; we'd have to check to see if each and every property is an array and, if so, we'd have to add in special code to iterate through it. That's not an impossible task by any means, but we just didn't have time to do it. As a result, you won't get back any values for a property like Win32_Printer Capabilities.

  Fine, we'll add that in for version 2. Sheesh.

• The Scriptomatic won't interpret returned values for you. When you ask WMI for the status of all the services installed on a computer, you'll get back information like this: Service A -- Running; Service B -- Stopped; Service C -- Running. Pretty self-explanatory, right? However, when you ask WMI for the status of all the printers managed by a print server, you get back information like this: Printer A -- 4; Printer B -- 4; Printer C -- 7. In other words, you get back an integer value, and it's up to you to include code that translates the value 4 into Printing and the value 7 into Offline.

  The Scriptomatic can't do this translation for you; in addition, the Scriptomatic doesn't provide a way to look up the meaning of these return values. For now, you'll have to rely on the WMI SDK. In the future -- well, let's just say that we're looking into different ways of integrating this information into the Scriptomatic.

• The Scriptomatic can only return property values; it can't be used to run methods. If you want detailed information about all the services installed on a computer, then the Scriptomatic is the perfect tool for you; it's a veritable information-retrieval machine. But what if you want to stop a service, or start a service, activities that can also be carried out using WMI? Well, sorry; in its current incarnation, the Scriptomatic can't do anything like this. But if there's enough interest, we'll explore the possibility of adding that capability in the future.
• The Scriptomatic works only with WMI. That might not seem like a limitation; after all, WMI is the way to get at information about a computer, the software running on that computer, the peripherals connected to a computer, etc. What WMI doesn't do (or doesn't do very well, anyway) is get at information stored in Active Directory; this means you can't use the Scriptomatic to write scripts that return information about user accounts or organizational units or security groups. But stay tuned; when Son of Scriptomatic makes its debut in the not-too-distant future, we hope to add in the ability to write ADSI scripts as well as WMI scripts.

To be honest, we listed all those limitations simply to prevent anyone from saying, "Hey, you never told us that the Scriptomatic couldn't …." But don't let these limitations deter you. Is the Scriptomatic perfect? Yes, it is. Oh, wait: No, it's not. But it is pretty darn cool, and it's a fun, easy, and -- dare we say it? -- educational way to get started writing WMI scripts. And it's free! What more could you ask?

Um, that was supposed to be a rhetorical question. Just download the Scriptomatic and see if it doesn't make your life better. And make plans to stop by the Jaguar dealer on the way home.

Product support note What kind of product support do we offer for the Scriptomatic? Absolutely none; you're on your own. However, we would definitely be interested in hearing what you like (and don't like) about the Scriptomatic, as well as suggestions you have for future versions. Just drop us a line at scripter@microsoft.com.

System requirements note Admittedly, we haven't exactly run the Scriptomatic through years of rigorous testing. However, the testing that we have done indicates that it should work without any trouble on Windows XP, Windows 2000, and Windows .NET Server computers. It will also work on Windows NT 4.0 computers, provided that you have installed Service Pack 6.0, Internet Explorer 5.0, WMI, and WSH 5.6 (whew!). It also seems to work just fine on Windows 98 computers that are running Internet Explorer 5.0, WMI, and WSH 5.6.

Who Are The Scripting Guys?

The Scripting Guys are Bob Wells, Dean Tsaltas, Ethan Wilansky, and Greg Stemp.