WMI Classes in Action

The last time around, we looked at various Windows architectural features such as metadata, intra-OS communications and how WMI is involved in managing them. We shall continue our exploration this time, and find out how WMI uses CIM (Common Information Model) schema for storing and managing system data. Finally, we'll give you an overview of how to actually use WMI in code, with a rather simple example.

How WMI uses CIM



The CIM is object-oriented, system-independent and application-independent. It provides a hierarchical schema, through classes, that defines objects in a already managed environment. These classes include methods to describe the behavior and properties, of the data stored in the CIM. Applications, networks, printers and drivers are the types of objects that are represented in a CIM schema.

However, a CIM is just a repository. In order to transact operations between this information and the application requiring it, we need a provider. This is very similar to the mechanism we use in our database applications to talk to our database and its objects. Several common CIM types have providers written by the OS vendor. If an application vendor provides a new CIM type, then they would also render a provider for it. Most providers work through COM/DCOM interfaces. These can provide and fetch data to/from WMI, handle requests for system management as well as generate events and notifications. Thus, these providers are largely responsible for abstracting the systemic information into the object-oriented structure exposed to our applications.

Its Object Manager called CIMOM manages the information in a CIM. This is responsible for tracking information and it intelligently determines the right provider to satisfy a request. In a Windows environment, all this is abstracted through the Windows Instrumentation Management (WinMgmt) service. The figure shows how this is hierarchically represented.

WMI classes



Just like the classes we are used to in C++, VB, Java and other programming environments, WMI classes provide an object-oriented approach to programming the CIM. At the oot level of the hierarchy, several namespaces are declared. A namespace is a set of classes and interfaces. By default, all classes belong to the

'Root' namespace.

WMI framework contains quite a few class sets-Win32 classes (in the CIMv2 namespace), registry classes, network classes, system classes, remote policy management classes and CIM base classes. Other than this, Microsoft has also implemented a variety of other classes (such as MSMCA, MSFT, and classes for the .NET framework). You can use the class' name to identify its root class. For example, the 'Win32' identifier in 'Win32_Directory' means that the class' name is 'Directory' and it belongs to the Win32 root class.

Let us now take one of the several classes in WMI and see how to use it.

Walkthrough: Windows System Activation



Yes, we are taking the WMI class that deals with the famous activation process. The class we require is called 'WindowsProductActivation' and it resides in the Win32 class-set. So, its name is 'Win32_WindowsProductActivation'. This class has nine properties-ActivationRequired, Caption, Description, IsNotification On, ProductID, RemainingEvaluationPeriod, RemainingGracePeriod, ServerName and SettingID. It defines five methods-ActivateOffline, ActivateOnline, GetInstallationID, SetNotification and

SetProductKey.

CIMOM performs the request response translation between CIM and the application, effectively hiding the real details and source from the app

Let us assume for the sake of this example, that you have installed a legal copy of Windows and now because of a change in your licensing, you want to change the associated product key. In order to run this code, you will need a WMI capable Windows installation (Win 98/NT/XP/2000/2003) and a new Windows product key. Our code is in Visual Basic. The code is courtesy:

http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/wpadepl.mspx

In the shown code snippet, we are connecting to the Win32_WindowsProductActivation class using the GetObject method. The 'impersonationLevel' property will

allow the code to impersonate the currently logged on user. For this purpose, you need to be logged in as a member of the Administrators group. Then, we enumerate through the returned instances and set the product key to the new volume license key (myNewVolumeLicenceKey). When the product key changes, Windows needs to be re-activated. So, we call ActivateOnline to activate it. The If statement merely checks to see if the current ProductID matches the sequence (stored in seqNumber) we want to change. If it needs to be modified, we do it. This prevents changes to systems that already have an activated valid key in the deployment.

You can very well put this code in a home-grown Web-based management system and execute the script to a remote workstation using client-side scripting.

Sujay V. Sarma