Windows Management Instrumentation (WMI)

WMI is quite an old technology that I think a lot of people have heard about but few people have actually tried. Even fewer people can use it and about a handful of people are masters of it. I have recently tried out this technology and thus I am definitely not the latter.

WMI 101 (short version):

WMI is the de-facto standard to access management information in an enterprise environment. The standard is used to address the ability to access, configure, manage and monitor system resources. WMI is commonly used by Administrators to monitor both local and remote machines using scripts. You need to know about WMI if you want your applications to be monitored in production by third party applications or Administrators and their scripts.

WMI concepts:

• Providers - Acts as an intermediary between WMI and a managed resource, such as an Event Log. Providers request information from, and send instructions to the WMI managed resource on behalf of consumer applications and scripts.
• Consumer - A script, enterprise management application or any other application that makes use of WMI resources.
• CIM - Common Information Model is a schema (object repository or class store) that models the managed environment and defines every piece of data exposed by WMI.
• CIMOM - CIM Object Manager handles the interaction between consumers and providers.
  
• Events - WMI allows you to register for events which will notify you when any WMI object is created, deleted or modified.

So why would you want to use WMI?

WMI can be used to build tools that organize and manage system information so that administrators or system managers can monitor system activities more closely. WMI allows you to access an enormous amount of information about both local and remote machines.

Lets take a moment to think about the possibilities.

• You can development an application using WMI that pages an administrator when a Web server crashes,
  
• Have a badly behaving process terminated if it exceeds more than certain about of CPU usage.
• You can also detect and discover management information such as what operating system (including service pack) is installed on a server.
• You can determine how many processors the computer system has
• Determine which services are running in a process
• Etc

All these examples are built-in WMI classes and events you can use. In addition, you can also define custom classes and events for your enterprise applications. The benefit is that all applications using the WMI infrastructure will pick up yours automatically.

Let's use another example. Let's say you have a couple of processes that are processing data on your servers. You would like these components to publish stats regarding their throughput, performance, internal queue sizes, CPU usage, etc. You would also like to restart these processes on an ad hoc or scheduled interval without stopping the whole interweaving process. You would like to be notified when certain business rules are violated or exceptions occur via different types of channels (SMS or Email).

Normally to do all this type of functionality you write custom code. This is typical System Monitoring and Control Bus implementations. Instead of writing a lot of custom code, you can rather use WMI to raise events when certain conditions occur OR publish information to performance counters and custom classes OR send WMI command to your process which will act accordingly.

The possibilities are endless. But why aren't a lot more people use it? The same reason for most things. It is difficult to use and limited documentation on it.

I still think it is worth investigating though.