Gallery

Managing with WMI

Posted on 12 Jul 2007 at 17:52

Thomas Lee rounds off the basics of .NET by examining how Windows Management Instrumentation can be used in effective systems management.

The WMI infrastructure has two main components: the WMI service and the WMI repository. The WMI service, Winmgmt, provides a standardised interface between WMI providers and WMI management applications (including WMI scripts). This is a typical Microsoft approach to integrating components - WMI providers and WMI management apps share a common calling convention to enable WMI applications to access the provider objects in a consistent manner, simplifying things no end.

The WMI repository, also known as the Common Information Model, or CIM, is a hierarchical data store organised by WMI namespaces. At system startup, the WMI service creates a number of namespaces such as root\default, root\cimv2, and root\subscription. The service also creates a default set of class definitions, including the Win32 and WMI system classes. Each namespace contains multiple WMI objects, and additional WMI namespaces may be created by additional WMI providers.

WMI consumers

WMI consumers are, in effect, any code that uses the WMI infrastructure to access and manipulate information via a WMI provider. This includes scripting languages like VBScript and PowerShell.

The CIM is a data model that contains information about components of the computer systems within your organisation. The CIM is a language-independent programming model that you can use to access WMI information, and is designed to present a consistent view of logical and physical objects in a management environment. Like a C++, COM or .NET class, a CIM class can include properties to describe the data, methods and behaviours of the object being modelled.

In principle, the CIM is platform independent. Within Windows, Microsoft has provided extensions to the CIM to describe the OS components, so some of the Win32 classes, for example, are similar to standard CIM classes, while others are extensions or new CIM classes. In general, Windows admins will most likely use the more Windows-focused Win32-based classes rather than the platform-independent CIM classes, although there's nothing to stop you using either or both.

There are three levels of classes within the CIM:

Core classes represent managed objects that apply to all areas of management. They provide a basic set of features to help you to analyse, describe and manage a computer.

Common classes are extensions of the core classes and represent managed objects that apply to specific management areas. In general, common classes are independent from a particular implementation or technology and apply to all computer systems.

Extended classes represent managed objects that are technology- or vendor-specific additions to the common classes. An extended class typically applies to a specific platform such as Unix or the Microsoft Win32 environment.

Managed Object Format

WMI uses Managed Object Format to describe the classes within the CIM. Developers use MOF to create extended classes and add them to the WMI Repository or CIM. You compile MOF files and add their details to the CIM by using the compiler mofcomp.exe. In most cases, a WMI provider will come with a MOF file that defines the data and event classes it implements.

On a Windows system, you can find the key MOF files in the %systemroot%\system32\wbem folder: on my XP SP2 system, there are 43 MOF files in this folder. Add-on components also provide MOF files, so, for example, when you load the .NET Framework you add a MOF file for ASP.NET called aspnet.mof, which can be found in the folder %systemroot%\Microsoft.NET\Framework\v1.1.4322 for .NET version 1.1 or %systemroot %\Microsoft.NET\Framework\v2.0.50727 for .NET version 2.