I have often talked about the divide between developers and administrators. (There are many such divides: The divide between developers and end users, for example! But that is not the topic of discussion right now.) Windows Management Instrumentation (WMI) is a great example of how object oriented design and reuse of the object model can be used effectively to architect solutions which consist of diverse, seemingly heterogeneous entities. It’s also a tool whereby the developer community can add lot of value to administrators. What’s more, administrators, with little programming effort, can actually simplify and automate their work.

WMI has been around in Window NT 4, Windows 2000, Windows 95/98/xp for quite some time. Unfortunately, not many people know about it, leave alone using it!

As usual, in TechForum, I bring you another great technology which is often ignored but is extremely useful.

Code first
Enough of theory! Let us see a real life example first. This is the WMI ‘hello world’ application, if you want to call it that.

Sub wmidemo1()
Dim s As Object
Set s = GetObject _
(“winmgmts:{impersonationLevel=impersonate}”). _ InstancesOf(“Win32_Service“)
For Each Service In s
Debug.Print Service.Description
Next
End Sub

This is a very simple code routine that lists all the services on the Windows 2000 server. Here is another piece of code that enlists Full Name of all users in the domain (using Active directory) and the SID associated with it.

Sub wmidemo2()
Dim s As Object
Set s = GetObject _
(“winmgmts:{impersonationLevel=impersonate}”). _ InstancesOf(“Win32_useraccount”)
For Each Service In s
Debug.Print Service.fullname, service.sid
Next
End Sub

The only difference in the code is the reference to the class win32_useraccount and the properties fullname and SID.

Here is some more active code. This code kills all instances of a given executable running on the machine.

for each Process in GetObject _
(“winmgmts:{impersonationLevel=impersonate}!//rogue”). _
ExecQuery _
(“select * from Win32_Process where Name=’notepad.exe’”)
Process.Shutdown (0)
Next

Note here that there is an SQL Statement to enlist running processes! Isn’t that great? This I would say is the right use of the right technology at the right place. The base WMI infrastructure needed to be object oriented. But for enumeration, filtering and similar tasks, we would have had to create another ADO recordset-like functionality. Instead a subset of the SQL language syntax was adapted for this purpose. Nowhere else have I seen a great combination of object orientation and usual SQL syntax. This is real practical architecture.
Can you think of a simpler method of achieving these tasks? This is just for starters. More code later.

Origin of WMI
WMI is actually an implementation of open standards called Web-Based Enterprise Management (WBEM) and Common Information Model. The CIM is a language-independent programming model that uses object-oriented techniques to describe an enterprise. It is available as a COM component, as an API and as a .NET managed class (system.management.instrumentation).

The purpose of WMI is to provide a standardised means for monitoring and managing computer systems across the enterprise. Baseline tasks include collecting data about the state of a managed object on the computer system and altering the state of the managed object by changing the data stored about the object. A managed object can be a hardware entity, such as a memory array, port, or disk drive. It can also be a software entity, such as a service, user account, page file or an application written by you.

Features of WMI

WMI Architecture
Consider that we want to provide information about a hard disk using WMI. The hard disk is managed by the operating system using some device driver. Beyond the device driver, we need to know about relevant hard disk related parameters at runtime. How could we make this happen?

What you need is a middleman between the device (hard disk, in this case) and your monitoring application. This middleman should ideally behave in a pre-defined manner for not just the hard disk but also for the processor, display, network and even the operating system functionality like eventlog, services and so on.

This is achieved using a device level provider. This provider understands the CIM(WMI) model on one hand and also understands device-specific functionality. Therefore, the WMI provider is really an adapter between the device and the rest of the world.

Refer to the following diagram to get a clear picture of how WMI works.

The CIM Object Manager and WMI Repository are known as the WMI infrastructure. Using WMI, the application developer only needs to know how to call a WMI object. Once an object is identified, the available instances, properties, methods and associated classes can be enumerated and acted upon. The consumer of WMI (developer) does not need to understand the exact method of information being provided by WMI.

For example, to know remaining disk space, the developer would query the relevant WMI class. WMI will check how this class is registered, which provider needs to be talked to and then deliver the information to your application.

Thus the creators of devices and other WMI compliant entities can write a provider, and developers only need to talk to WMI infrastructure. The device intricacies are never exposed to the developers nor does the provider need to know who is using the info and how. This is real encapsulation based simplification of tasks.

Before WMI was introduced, you would have had to look at the specific architecture and API of each entity separately. For example, the method of checking event log entries is bound to be different than finding out free disk space. Using WMI, developers can access all compliant entities using a uniform method of managing computer systems and devices.

In addition, the coding can be done in any language that supports COM, which includes the humble .VBS batch file to sophisticated Web services. Before a script can access WMI object instances and their properties and methods, the appropriate namespace needs to be specified. Namespaces contain various objects related to a single logical type of information. For example, there is a namespace for Exchange 2000 related information. There is another namespace for the Win32 operating system and so on. The baseline namespace is ROOT.

WMI providers
Windows 2000 has many built-in providers that make a huge amount of information available to developers. Some of the providers include:

• Active directory provider
• Event log provider
• Performance counter provider
• Security provider
• WDM provider for hardware device drivers

WMI Classes
For various types of entities and information there are literally hundreds of pre-defined WMI Classes. You can also develop custom WMI classes to make your applications WMI Compliant. All serious packaged products that are developed using WMI compliant platforms should ideally include a WMI provider and relevant classes. The class we used above was the from the Win 32 class. The following classes are available under the Win 32 category:

• Hardware
• Operating system
• Installed applications
• WMI service
• Performance counters

WMI tools
Many tools are available to simplify the usage of WMI features. From a developer perspective, there are many components registered that can be used to access the WMI infrastructure. Moreover, the following utilities are also provided.

For developers who want to create a WMI compliant application, there is a full-featured Software Development Kit for WMI. This toolkit also contains additional utilities like the WMI object browser and WMI administrator. We will see these utilities later. Right now let us concentrate on understanding the base functionality of WMI.

Learning WMI using WBEMTEST.EXE
From the point of view of learning and utilising WMI, wbemtest.exe is the most important. This EXE is situated in the %systemroot%\system32\wbem\ directory. Just start it like any other EXE file. The following application is displayed. When you start this utility, only the Exit and Connect buttons are enabled. You need to provide the path of the machine and the namespace to connect to in order to enumerate and view the WMI classes and instances.

The user interface of this utility is a bit erratic so be careful while handling it. It provides a lot of information starting with the superclass and going downwards to individual instances properties and methods. It is easily possible to get lost and confused while using this utility. So go step by step, understand what is happening and then proceed further.

Given below are the steps to arrive at the listing of processes on a machine (which we have seen earlier in the VB code) using the utility.

• Click on the Connect button
• Type the path as root\cimv2 and close the dialog. Now all buttons will be enabled.
• Click on the Enum Classes button, choose the Recursive option and choose ok.
• Now the utility will list all the classes from the root downwards. Classes within classes are also enlisted because we have chosen the recursive option.
• There will be hundreds of classes. The exact number will depend upon the machine you are using. On my machine WMI enumerated 672 classes!
• Now scroll down in the list till you reach Win32_process class.
• Now double click on the Win32_process item in the list. Another complicated dialog opens (not shown here). In this dialog, first select the check box called “Hide system properties.” That will reduce the clutter. This dialog is the object editor. It shows properties, methods, instances and so on. In short, it tells you how the Windows 32 service object is designed in the WMI repository. This information would be useful to you while writing applications that work with services.
• We want to see the actual services running on the machine, not the object model. So click on the Instances button. This will open another list! This list will finally show the names of all the services running on your machine.
• This list is what was exactly available to us programmatically in VB using the Getobject method.
• Now you can double-click on one of the services to view details of all the property values. Within this dialog we can also see the associated object instances, class definition and MOF (Management Object Format) definition.

As you can see, WBEMTEST.EXE very easily provides a wealth of information about the entire WMI infrastructure. I will continue this topic for next week. I am sure you will find this topic very useful and effective in day-to-day life, whether you are a developer, architect or administrator.

Feedback
Your feedback, suggestions, requests for covering specific topics or issues are welcome. Please send feedback to techforum@mediline.co.in

About the Author Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in