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 root\cimv2 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 "\root\cimv2" 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.