Scripting with WMI

Administrators have several choices when selecting tools that collect desktop inventory information for systems migration, auditing, or other purposes. In addition to Microsoft Systems Management Server (SMS), which is the company's tool for hardware and software inventory, several third-party tools are available that bolster SMS's inventory capabilities or operate on their own. In some organizations, however, the cost and complexity of deploying an inventory solution that's part of a larger management platform can present insurmountable hurdles to understaffed IT departments. In some cases, using scripts to cull system data directly from Windows Management Instrumentation (WMI) makes the most sense. For example, you can use a WMI-enabled script to return information about a system component that your existing inventory solution doesn't cover, or you can use WMI to gather information that you need for a rollout analysis without relying on a third-party inventory product.

Before we dig in to a WMI-based inventory solution, let's define WMI, where it came from, and what it can do. WMI is Microsoft's implementation of a scalable management standard that's built into Windows XP, Windows 2000, and Windows Me (WMI is also available as an add-on to Windows NT and Windows 9x). WMI is based on the Distributed Management Task Force (DMTF) initiatives, Web-Based Enterprise Management (WBEM), and the Common Information Model (CIM). As a result of being based on these standards, WMI provides a consistent, extensible management hook into the Microsoft OSs.

WMI Infrastructure
The WMI infrastructure consists of four components: WMI providers, the Common Information Model Object Manager (CIMOM), the CIM repository, and the WMI scripting library. WMI providers, many of which are built into the Windows OS and called standard providers, ensure that managed resources are available and addressed appropriately in WMI. CIMOM acts as a traffic director that handles interactions between WMI providers and consumers. The CIM repository is a schema that models and manages every piece of data available through WMI. The data is categorized into classes, and the classes are logically grouped into namespaces. Most computer- and OS-related information resides in the rootcimv2 namespace. The WMI scripting library is the interface through which scripting tools such as JScript, VBScript, and other languages (e.g., Perl) that support Microsoft ActiveScripting technology easily consume WMI data.

For the purposes of this article, you need to understand only that the sample scripts I describe are WMI consumers that use the WMI infrastructure to get information about, and sometimes control, managed resources. Retrieving data from WMI is just a small example of what you can do with WMI, but it's a good introduction to the potential of WMI scripting.

Rudimentary WMI Script Construction
Before you take the sample scripts from this article and manipulate them to get the information you're after, you'll want to review the basic constructs of WMI scripting. The first script, which Listing 1 shows, returns system processor information by performing the three basic functions common to WMI scripts: It connects to the WMI Service, retrieves information about a specific object, and outputs the gathered information. The first two lines connect to the WMI Service through the WMI Scripting Library "winmgmts:" on the local system "." and open the "rootcimv2" namespace. The next line of the script returns instances of the specified WMI-managed resource, Win32_Processor, in the form of a collection. The last three lines of the script enumerate the contents of the collection in a For loop. If you create a text format file containing the contents of Listing 1 and save the file with a .vbs file extension, you can use Windows Script Host (WSH) to process the file. When you do so, a pop-up dialog box will display the information that the script enumerates.

More Powerful Scripts
What if you want to do more than just return the type of processor in your computer? You can accomplish more powerful results by expanding on WMI's basic functions. The second script, which Listing 2, page 78, shows, provides information about key system components to consider when you upgrade to XP. For example, if you're strapped for resources, you can use a variation of this script as a logon script to gather information you need to plan upgrades and system replacements necessary before you deploy XP. You can compare the results, which the script displays on your computer screen, to Microsoft's recommended processor, memory, disk space, video card, keyboard, mouse, CD-ROM drive, and network adapter requirements for XP.

The third script, which Web Listing 1 (http://www.winnetmag.com, InstantDoc ID 38498) shows, returns the same information as the second script, but instead of returning data to the screen, the third script writes data to a file. In this instance, the script appends data to a file on a network share that the script references through a Universal Naming Convention (UNC) path. The script prepares the data in a comma-separated value (CSV) format that you can import into a spreadsheet or database application. Notice in Web Listing 1 that the script replaces the Wscript.Echo commands with objTextFile.Write, removes the informational descriptions in quotes, and appends a comma to each piece of data to be written to the file. Additionally, the script executes a carriage return and line feed before closing the file.

Resources for Scripting with WMI
Although a .csv file probably won't satisfy all your requirements for inventorying desktop systems, you can employ additional scripting methods to output the information you've gathered to other formats, including XML. Likewise, you can use ActiveX Data Objects (ADO) to update a Microsoft SQL Server database.

The Microsoft TechNet Script Center (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/scriptcenter/default.asp) is an excellent resource for finding sample scripts, including many that use WMI. In addition to providing general information about scripting, the TechNet Scripting FAQ (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/scriptcenter/scrptfaq.asp) provides a sample script that reports versions of key scripting components on your system along with links to download updates to these components. If you're unsure whether you have WSH or WMI, start here to avoid unnecessary frustration. And, of course, you can look through back issues of Windows & .NET Magazine (http://www.winnetmag.com) to find many great articles about using WMI scripting for administrative tasks.

Mining WMI
If you want to start from the ground up, you might consider some tools that will help you mine WMI. One such set of tools, Microsoft's WMI Administrative Tools, consists of WMI Event Viewer, WMI Event Registration Tool, WMI CIM Studio, and WMI Object Browser. The WMI Administrative Tools are available at http://www.microsoft.com/downloads/release.asp?releaseid=40804. WMI Object Browser is the most useful tool because it lets you drill down through the schema to view objects in the CIM repository. But the coolest tool for WMI scripting beginners is the recently released Scriptomatic tool, which is available at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/scriptcenter/wmimatic.asp. Scriptomatic lets you quickly generate WMI scripts with a few mouse clicks. Scriptomatic uses WMI to return a list of available classes into a dropdown list. When you select one of the returned classes, Scriptomatic generates a script that enumerates the values of the properties within that class. You can then run the Scriptomatic-generated script or save it for modification.

Starting Small
After you begin to realize the power of WMI, you can investigate other uses for administrative tasks you'd like to automate or perform remotely. Even if you don't see a use for WMI and scripting right now, keep it in mind as an alternative for those troublesome management tasks for which a tool doesn't exist.