Windows Management Instrumentation: The Systems Administrator’s Apprentice

During the past year, I examined several Windows Management Instrumentation (WMI)-based scripts that provide a glimpse into the powerful WMI scripting library. In "Systems Management Panacea," April 1999, I introduced you to wbem.vbs, which uses WMI Query Language to retrieve class instances. In "Windows Script Files in Action," June 2000, I presented the event-log parser (i.e., eventlog.wsf and library.vbs). Eventlog.wsf demonstrates one of the WMI Event Log provider's many event-log management capabilities.

To learn more about WMI scripting capabilities, see the Microsoft Windows 2000 Professional Resource Kit or Microsoft Windows 2000 Server Resource Kit. You'll find more than 50 WMI-based scripts to manage and report on everything from a target computer's boot configuration to user accounts. Although you can examine the VBScript (.vbs) files in your resource kit installation directory, you need to understand WMI scripting to understand the script's inner workings.

WMI Scripting 101
WMI scripting is a library of automation interfaces that sit on top of the Common Information Model Object Manager (CIMOM). COM-compliant scripting languages (e.g., Windows Script—WS, ActivePerl) use these automation interfaces to access WMI's infrastructure. Wbemdisp.dll is the DLL that implements the WMI automation objects, methods, and properties.

To access WMI through the WMI scripting library, you need to perform three steps that are common to most WMI scripts. First, connect to the Windows Management service, and second, retrieve instances of WMI managed objects. Third, call a method or access a managed object's property. After you understand the interfaces that you use to perform these steps, you'll be well on your way to becoming a WMI scripting guru.

Let's examine a WMI script that demonstrates these three steps in action. Winmgmts.vbs in Listing 1, page 164, is a basic WMI script. You can download the complete listings from Windows 2000 Magazine's Web site at http://www.win2000mag.com/. (Enter 9033 in the InstantDoc text box, go to the Article Info box, and click the 9033.zip file.) The script is powerful and demonstrates most of what you need to know to leverage WMI scripting.

The script initializes two string variables—strComputer and strProcsToKill. The target computer's name is StrComputer; strProcsToKill is a process name that the script uses to identify and kill all running processes with the same name. Notepad.exe is the running process in this case.

The code at callout A in Listing 1 uses WMI's moniker winmgmts to connect to WMI on the target computer and retrieve all Win32_Process class instances. (A moniker is a standard COM mechanism for binding to a COM object.) You can include optional security settings and additional object path components as part of the WMI moniker syntax. (For detailed information about WMI moniker syntax, see http://msdn.microsoft.com/library/psdk/wmisdk/scintro_6tpv.htm.)

The script returns each Win32_Process instance as an SWbemObject in an SWbemObjectSet collection. SWbemObjectSet and SWbemObject are two of several interfaces that the WMI scripting library provides. You can use VBScript's For...Each construct at callout B in Listing 1, page 164, to enumerate SWbemObjectSet because it's a collection.

At callout B, the script performs the last step for accessing WMI. Inside the For...Each loop, the script accesses two properties and one method that the Win32_Process class defines. First, the script echoes the ProcessID and Name properties of each Win32_Process instance. Next, the script compares the current Win32_ProcessName property with the strProcsToKill variable. If the two match, the script calls the Terminate method that the Win32_Process class provides to kill the current instance.