Leveraging Windows Management Instrumentation in Win2K Pro

WMI gives unprecedented visibility into Win2K Pro data management

Proper instrumentation (i.e., the ability to get feedback about the performance of a computer subsystem) is the key to effective systems management—you can't manage systems that aren't well instrumented. Historically, computing-system components (e.g., routers, servers, workstations, applications) have used different instrumentation models. For example, network devices typically use SNMP, and PCs might use the Desktop Management Interface (DMI) standard or other proprietary management protocols and applications.

Fortunately, the Distributed Management Task Force (DMTF—formerly the Desktop Management Task Force) introduced the Web-Based Enterprise Management (WBEM)/Common Information Model (CIM) standards to create a broad framework for unifying disparate management protocols. (For information about WBEM and its standards, visit the DMTF Web site at http://www.dmtf.org/wbem/index.html, and see "Related Articles in Previous Issues," page 69.) WBEM takes the different instrumentation standards and inputs them into a common object model that WBEM-aware management applications can access. In Windows 2000 (Win2K), Microsoft combined the WBEM standards into a set of services the company calls Windows Management Instrumentation (WMI).

To learn how to leverage WMI in Windows 2000 Professional (Win2K Pro), you need to understand WMI's capabilities. If you've ever wanted a tool that lets you intelligently query and manipulate hardware and software information on your Windows computers across your network, WMI scripting is for you.

The Common Information Model
The CIM is an object-oriented model that describes managed objects (logical and physical) to management applications. As an object-oriented schema, the CIM specification uses a set of classes that can inherit from one another. These classes have properties, methods, and associations. Associations let you relate objects to one another so that you can describe managed systems in several meaningful ways. For example, a Win32 computer system (i.e., a Windows workstation) computer class can have associations to an application class installed on the same computer. These associations let your management application not only collect data on individual system pieces but also view the system's interactions.

WMI uses Managed Object Format (MOF) to describe the CIM schema that defines the base classes and how they relate to one another. When you search your Win2K Pro workstation in the %systemroot%system32wbem folder, you'll find several files with the .mof extension. These text-based files are the actual class definitions for the managed objects that WMI supports. Screen 1 shows part of the ntevt.mof file that describes Win2K event-log classes.

WBEM/CIM is an industry-standard specification that isn't specific to a particular OS or platform. However, the specification does let you use vendor-specific extensions to the schema. Therefore, although core CIM classes are available on any platform, individual vendors can add their own platform-specific classes. Screen 1 shows an example in which Microsoft added classes that are specific to Win2K event logs.

Providers and Consumers
Besides extending the core CIM schema, WBEM/CIM also incorporates providers and consumers. A provider is the code that speaks directly to the managed object and gathers data to return to the management application. A consumer is an application that uses the data that providers collect. For example, Microsoft Systems Management Server (SMS) 2.0 uses WMI as a consumer to feed the SMS hardware and software inventory database. Microsoft provides several out-of-the-box default providers, which Table 1 lists. These providers interact with hardware or software to present management information to your management applications in a way the applications can understand.

Microsoft also provides a WMI software development kit (SDK) that is part of the Windows Platform SDK and that lets you develop your own WMI providers. (For information about the WMI SDK, visit the Microsoft Developer Network—MSDN—Web site at http://msdn.microsoft.com/downloads/ sdks/wmi/default.asp.) For example, when you want to instrument a particular application, you can write a specific provider to extract management data from the application and feed this data to WMI.

Providers can give event-based data or persistent data (e.g., information about the amount of a workstation's RAM or available space on a drive volume) about a managed object. Management applications running on Win2K use the Common Information Model Object Manager (CIMOM) to access data from both information types. The CIMOM provides the necessary interfaces between the management applications and the providers. The CIMOM takes data from disparate providers, such as SNMP and Win32, and uses the WMI API to present the information to management applications.

CIMOM and Event Data
WMI events let you know what is happening on your system in realtime. When a managed object changes, you need to know so that you can potentially automatically act on the change, if necessary. Management applications can register with the CIMOM to receive notification about specific events, and the CIMOM communicates with providers about the registered events. When an event occurs, the associated provider notifies the CIMOM, which in turn notifies the management application that registered to receive the event notification.

Because the CIMOM abstracts management information from several providers, you can correlate events across many system components. For example, you can register with the Performance Monitor provider to receive notification about increasing pagefile sizes, and you can also register with the Win32 provider to receive notification about running applications with a memory working set larger than a specified size. These two events might help you locate and easily identify runaway applications on your system. Your management application might also include a rule, which you can specify through WMI, to shut down that application.

High-Performance Providers
You can find most Win2K Pro providers in the %systemroot%system32wbem folder. Providers are typically DLLs and can be normal or High-Performance (HiPerf) providers. HiPerf providers must be DLLs written to run in the same process (in-process) to either the management application that is calling them or WMI. For example, System Monitor, Win2K's Performance Monitor version, uses the wbemperf.dll HiPerf provider to collect data through WMI.

Because System Monitor collects realtime data, Microsoft needed to write this provider's code as HiPerf. However, not all providers are HiPerf. When you buy a management application that uses WMI or install providers that a third-party independent software vendor (ISV) wrote, you need to know the provider type because a non-HiPerf provider might be too slow for your application.

The WBEM Repository
CIMOM stores persistent data about managed objects in the WBEM repository, which you'll find in the %systemroot%system32wbemrepositorycim.rep file. Providers deliver data to the CIMOM, and Win2K automatically backs up the WBEM repository every 30 minutes to the CIM.rec file.

You can use the Microsoft Management Console (MMC)-based WMI Control snap-in to modify backup behavior, restore data from an earlier backup, and manage WMI and other repository aspects. To open the WMI Control snap-in, right-click the My Computer icon and choose Manage from the pop-up menu, or choose Computer Management from the Administrative Tools folder. Expand the Services and Applications node, right-click WMI Control, and select Properties. Screen 2 shows the Backup/Restore tab, which you use to control WBEM repository backups and restores.

WMI Navigation Tools
To navigate WMI, you need to understand WMI namespace construction. The WMI namespace is analogous to the MIB tree that SNMP uses. The namespace is a directory in which you can find certain classes of objects that the directory classifies by vendor and function. Screen 3 shows WMI's base namespace. The namespace always starts with root, and you find classes that are part of the core WBEM/CIM 2.0 standard in the rootCIMV2 namespace descriptor. Classes that Microsoft provides have a Win32_ or MS designator preface, and you find these classes under each part of the tree.

In your Win2K system's %systemroot%system32wbem folder, you'll see the wbemtest.exe application, which you use to connect to and navigate the WMI namespace. You can select the Connect button in wbemtest.exe to create a connection to a portion of the namespace (e.g., rootCIMV2) on a local or remote computer. After you're connected, you can display all available classes for that namespace portion and the associated methods and properties. You can also see which properties and methods the namespace inherits from parent classes. These inherited properties or methods include an underscore preface (e.g., __SystemClass).

WMI also supports Win2K-style security for accessing the namespace. You can select the Security tab from the WMI Control Properties window to set the security configuration. The example in Screen 4 shows the security dialog for the rootWMI portion of the WMI namespace.

When you install the WMI SDK, you have more tools that you can use to navigate the WMI namespace. The WMI SDK provides the Web browser-based WMI Object Browser, which lets you view objects and their associated methods and properties within the namespace in a nicely formatted, graphical frames-based view. The WMI Object Browser in Screen 5 shows an instance of the Win32_OperatingSystem class, which has the SAUTERNES name property. The window's right-hand pane displays the properties associated with the Win32_OperatingSystem class instance, which is information that is related to my Win2K Pro installation.

The WMI SDK also provides an Event Registration Tool, which you use to manually register a consumer application for particular events, as well as the corresponding WMI Event Viewer that lets you view current event registrations for several consumers. When you register for an event, you create three characteristics for that event registration. First, register the consumer application, which is the application that will receive the event notifications. Next, create a filter that controls what data you want to receive notifications on. For example, you might create a filter to notify you when your processor utilization exceeds 80 percent. Finally, set a timer. Two types of timers exist—absolute and interval. The absolute timer lets you set the date and time for when you want the event collection to begin. The interval timer lets you set how frequently you want to poll a WMI provider for data.

WBEM Query Language
WBEM Query Language is the standard language that you use to perform queries against WMI. For example, to create a filter that tells the CIMOM which events you want to register, you need to submit a query for the events to monitor. That query uses a specialized SQL dialect subset—WBEM Query Language—that is specific to WMI. If you're familiar with SQL, then you'll find using WBEM Query Language easy. However, WBEM Query Language is a read-only query language, so you can use WBEM Query Language to query managed objects, but not to modify them.

WBEM Query Language queries can be data, event, or schema queries. You use data queries to retrieve instances of a specific managed object class and associated properties, and you use event queries to create a filter for a particular event. Schema queries let you extract information (e.g., descriptions of a class and its given methods, properties, and association) about the WBEM schema. The WMI SDK includes more detailed information about the keywords that WBEM Query Language supports. The SDK describes the WMI-specific dialect within WBEM Query Language, but the WMI syntax is similar to SQL.

WMI Scripting
The data types that WMI provides and the ways you can interact with that data are almost limitless. However, I've described consumers of this data as management applications, such as those applications you can get from NetIQ (AppManager) and IBM (Tivoli Enterprise Solutions). For information about AppManager and Tivoli, see "Management Applications."

Microsoft also provides a way for systems administrators to access this data. For example, the WMI Scripting API tool provides COM-based objects, methods, and properties that you can access from Visual Basic (VB), VBScript, JScript, or any other COM-based scripting engine. WMI implements the WMI Scripting API in the CIMOM; when you write a WMI script, you talk to the CIMOM directly, which queries a provider or the repository. You use WMI scripting to register for events, query (through WBEM Query Language) the properties of an object, or change an object's configuration. You can also use WMI scripting to query and manipulate WMI information on remote machines.

The WMI Scripting API tool lets you perform tasks that you wouldn't use a systems management application to perform. For example, in WMI, an instance of the class Win32_Process represents the Win32 processes running on a workstation. You can run the WMI Object Browser from the SDK, connect to the rootCIMV2 namespace, and select the Browse for Instance button. You then select Win32_Process to display a list of all running processes on the system, as Screen 6 shows. In the example in Screen 6, I've browsed to an instance of notepad.exe to display the properties associated with this instance, including memory and pagefile usage, which the window's right-hand pane shows. Each instance of class Win32_Process supports four methods—Create, GetOwner, GetOwnerSid, and Terminate.

The code snippet that Figure 1 shows is an example of how you can search for and shut down an instance of Microsoft Word running on a system. In this code, I use a FOR...EACH loop to enumerate a system's running processes. In Figure 1, the GetObject method opens the WMI namespace, which defaults to rootCIMV2, and sets the impersonation level. WMI uses the currently logged-on user (or another explicitly specified user) to support impersonation to perform a request. When I specify impersonationLevel=impersonate, I'm telling the script to use my existing credentials to connect to the namespace. The next set of commands, ExecQuery("select * from Win32_Process where Name='winword.exe' "), is a WBEM Query Language statement that means to select all instances of the class Win32_process in which the Name property for that instance is equal to winword.exe. After you find the process you're searching for, execute the Terminate method to shut down the process.

Figure 1 shows only a small sample of what you can do with WMI scripting. You can also gather hardware information on local or remote systems, read and change Registry entries, and query the status of an application that includes the Microsoft Installer (MSI—formerly Windows Installer). You can check out sample WMI scripts in the Microsoft Windows 2000 Resource Kit. Several excellent Web sites are also available as resources for Windows Script Host (WSH) and for samples of how you can use WMI, including Gunter Born's Windows Scripting Host Bazaar (http://ourworld.compuserve.com/homepages/ guenter_born/wshbazaar/wshbazaar.htm), Ian Morrish's WSH FAQ (http://wsh.glazier.co.nz), and Clarence Washington Jr.'s Win32 Scripting (http://cwashington.netreach.net/main_site/default.asp).

New Management Visibility with WMI
WMI in Win2K Pro gives you unsurpassed control over your Windows systems and data management. When you leverage WMI and WMI Scripting APIs in your Web pages and scripts, you can create management solutions that take charge of your Win2K infrastructure. I encourage any systems administrator who plans to deploy Win2K to learn about WMI—you'll be glad you did.