Windows Management Instrumentation: The Journey Begins

Exploring WMI with Wbemtest.exe
You might wonder how all this information relates to scripting. Consider the following three high-level steps: connect to the Windows Management service, execute a WMI query or request class instance data, and enumerate the query results. These three steps represent common actions that you find in many WMI-based scripts. The first step implies that you must identify the namespace that contains the target classes, so you need to understand WMI namespaces and what they contain. The second step includes identifying the target class and methods or properties the class provides. You therefore need to know how to obtain the class definition. The last step involves enumerating the returned data, so you need to know that WMI returns collections that contain the class instance data. You must use enumeration to gain access to the instance data.

Let's put this information to work in an exercise that highlights the three high-level scripting steps. The tool I use in the example is wbemtest.exe, and you can find it in the \%systemroot%\system32\wbem directory on every WMI-enabled machine. The following steps show you how to use wbemtest.exe to determine WMI namespaces on a target computer.

1. For best results, ensure that you log on with administrator-equivalent privileges before you use wbemtest.exe. Open a command prompt, type

   C:\>wbemtest.exe

   and press Enter to open the Windows Management Instrumentation Tester window. The buttons are disabled on the window, which means that you haven't connected to WMI at this stage of the process.

2. To connect to the Windows Management service on a local or remote computer, click Connect. The Connect dialog box shows a text entry field for Server\Namespace: that has root\default as its default value. Change the Server\Namespace: value to root. Click Login to return to the Windows Management Instrumentation Tester dialog box.

3. The Namespace: identifier in the dialog box's upper left-hand corner is root. All the dialog box's options are enabled, which indicates that you connected to WMI on the local host under the context of your current credentials. Click Enum Classes to open the Superclass Info dialog box.
4. Leave the Enter superclass name field blank, select Recursive, and click OK to open the Query Result dialog box. This dialog box lists all classes defined in the root namespace. The root namespace consists solely of system classes that support several WMI activities (e.g., provider registration, security, event notification). System classes are predefined CIM classes that every namespace in the WMI core includes. You can identify system classes by the two underscores that preface the class name.
5. Scroll down the Query Result dialog box list until you reach the __NAME SPACE class, and double-click the class name to open the Object editor for __NAMESPACE dialog box.
6. The Object editor dialog box contains the selected class' implementation details. The Object editor's Properties list contains system properties; two underscores preface property names. Select the Hide System Properties check box to hide the system properties. Only the Name property will remain in the list.
7. Click Instances to open a new Query Result dialog box that lists all instances of the __NAMESPACE class directly beneath the root namespace. Compare the instances of __NAME SPACE in the Query Result dialog box to the namespaces that Figure 2 shows. The two instances' collections should be similar.

You've now completed the first part of the exercise to determine the WMI namespaces beneath the root namespace. Additional subnamespaces exist beneath these namespaces, as Figure 2 implies. Let's continue the exercise and retrieve some class instance data that a class in one of the newly discovered namespaces, root\cimv2, defines. Close the two Query Result dialog boxes and the Object editor dialog box to return to the Windows Management Instrumentation Tester dialog box, and complete the following steps.

1. Repeat steps 2 through 4 from the first part of the exercise to connect to the root\cimv2 namespace on the local host and recursively enumerate the classes defined in the CIMv2 namespace. After you complete these steps, you see a new Query Result dialog box that lists more than 600 classes.
2. Scroll down the Query Result dialog box list until you locate the Win32_NTLogEvent class. If this is the first time you've examined the root\cimv2 namespace, you might want to become familiar with the comprehensive set of classes that the CIMv2 namespace defines, especially the classes that have a Win32_ prefix. These classes represent the data that the Win32 provider exposes. Double-click the Win32_NTLogEvent class name to open the Object editor for Win32_NTLogEvent dialog box.
3. The Object editor dialog box contains the selected class' implementation details. Select the Hide System Properties check box to hide the system properties. The remaining properties resemble the fields that make up a Win2K and Windows NT event-log record.
4. Click Instances to open a new Query Result dialog box that lists all instances of the Win32_NTLogEvent class. When I completed this step, I received 5674 instances that represent the same number of events residing in my six Win2K event logs. If you want to examine the details of one instance, double-click the target instance to open Object editor for Win32_NTLogEvent.Logfile="Application",RecordNumber=1. The Object editor's Properties list contains property names and CIM data types, as well as the dynamic data the ntevt.dll Event Log provider surfaces.

Related Articles in Previous Issues

You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com/articles. DARREN MAR-ELIA "Leveraging Windows Management Instrumentation in Windows 2000 Professional," Summer 2000, InstantDoc ID 8819 MARK RUSSINOVICH Internals, "Inside Windows Management Interface," February 2000, InstantDoc ID 7937 BOB WELLS Scripting Solutions, "Systems Management Panacea," April 1999, InstantDoc ID 5043

I've merely scratched the surface of the things you can learn and do when you use wbemtest.exe. I encourage you to try some of wbemtest.exe's other options, such as using the wbemtest.exe Query button for WMI Query Language queries. You can also use Windows Script (WS) to perform the previous two exercises. I think you'll find that completing the exercises is easier to script than it was using wbemtest.exe.

Just Manage It
WMI is as important to the Windows platform as AD is. The next time you hear Microsoft discuss lowering total cost of ownership (TCO), you can bet that WMI is the foundation that backs up that claim. To make your systems administrator job easier, wrap your brain around WMI. But if you decide that WMI scripting isn't for you, you still need to ensure that third-party systems management products you evaluate for your Windows infrastructure are WMI-compliant. Next month, I'll cover the WMI Scripting Object Model and WMI Scripting API. Make your travel plans now to continue the WMI journey.