Managing with WMI

Windows Management Instrumentation (WMI) is a great Microsoft technology that can help you to manage your systems better: it’s equally useful for developers, enabling them to expose the management aspects of their applications. In this column, I’ll examine what WMI is, its architecture and how you use it. And, as in most of my recent columns, I’ll present PowerShell examples to illustrate. Strictly speaking, WMI isn’t part of the .NET Framework, but accessing WMI objects is so like accessing other .NET objects that it’s easy to use alongside other .NET components.

Before delving into the details, a tip of the hat to Austin Osuide, who gave an excellent talk on WMI at the May UK PowerShell user group. His enthusiasm for WMI (and, of course, for PowerShell) convinced me this was a good topic for this column, and I have his slides should any reader want them.

What is WMI?

WMI is Microsoft’s implementation of the DTMF’s (Desktop Management Task Force) Web Based Enterprise Management and CIM (Common Information Model), and as such it provides non-proprietary and environment-independent mechanisms for manipulating information on all components of a computer system. WMI allows you to monitor and control just about all the computing resources throughout your corporate network, including hardware like batteries, BIOS, disk drives and network cards. You can use WMI to manage processes, services, shares, Registry settings, event logs, users, groups and more. WMI can also detect events as they occur (say, when a service has stopped) and notify a WMI Event consumer.

WMI is built into all versions of Windows 2000 and above, and can be installed on any other 32-bit Windows client. Prior to WMI, if you wanted access to the information and functions it delivers, you’d have had to write Win32 API calls using C++, as these calls typically weren’t available to scripting languages.

WMI architecture

The WMI architecture has three main components:

WMI providers (and managed objects) – COM objects that give access to managed objects. A managed object is a computer component such as a process, a hard drive and so on.

WMI infrastructure – core OS components that provide consistent access to WMI-managed objects.

WMI consumers – management applications or scripts that interact with the infrastructure to make use of the provider objects.

Several providers are implemented by default in the OS (see www.pcpro.co.uk/links/155dotnet1 for more information on the WMI providers implemented in Windows). For example, in Windows XP, the Win32 provider is installed by default, while you can optionally install the SNMP provider via Control Panel’s Add/Remove programs applet. Other applications, such as Office Communications Server 2007, supply additional WMI classes and make use of WMI to access this information. Increasingly, Microsoft applications are WMI enabled, both supplying WMI classes and making use of them.

WMI classes are similar to any of the other .NET classes I’ve illustrated in past columns, and like these they offer methods you can call and properties you can retrieve and set. The only significant difference is the method of instantiating individual classes. There are 954 classes on my Windows XP SP2 laptop, while on one of my Windows Server 2003 systems there are 882, and on my Longhorn Beta 3 virtual machine there are 1,003: some of these are WMI system classes (53 of them on my XP system). A WMI provider consists of a DLL file containing its code and a Managed Object Format (MOF) file that defines the classes for which this provider returns data and performs operations. System classes have class names that start with two underscore characters, for example __Event, and tend not to be of use to IT administrators. On the other hand, the Win32 provider supports 564 classes that are of interest to IT pros.