In-depth Look at WMI and Instrumentation: Part I

You can perform WQL queries against the WMI store. WQL is built on top of the SQL language with some variations, the main difference being that you can only query for data and not perform updates or deletes. A separate section of this article is dedicated to WQL. To subscribe to WMI events you use the WqlEventQuery type which creates the appropriate WQL query for you. When you create an instance of WqlEventQuery you pass along the event class name to query for and an optional condition, like any SQL WHERE condition. The condition allows you to query for only specific events, for example all EventDetails events where the Type property is set to one-"Type = 1". You also need a ManagementScope class to specify in which namespace you want to perform this search. When creating an instance of the ManagementScope class, pass along the namespace you want to search in including the machine name, for example "\\.\root\enterpriseminds". Finally, create an instance of the ManagementEventWatcher class and pass along the WqlEventQuery and ManagementScope objects you created before. The ManagementEventWatcher object then notifies you synchronously or asynchronously when an event is available. Here is a code snippet:

ManagementEventWatcher EventWatcher = null;
InstrumentationConsumer Consumer = null;
WqlEventQuery EventQuery = null;
ManagementScope Scope = null;
try
{
// create a event query object
EventQuery = new WqlEventQuery("EventDetails");
// define the search scope - which machine and namespace
Scope = new ManagementScope(@\\.\root\enterpriseminds\EventDetails);
// create a watcher object we use to get async notifications
EventWatcher = new ManagementEventWatcher(Scope, EventQuery);
// register the delegate to call when an event arrived
EventWatcher.EventArrived += new EventArrivedEventHandler(
Delegate_EventArrived);
// start listening for events
EventWatcher.Start();
}
// show any exception happening
catch (Exception e)
{
MessageBox.Show(e.Message);
}

This code snippet subscribes to EventDetails events in the "\\.root\enterpriseminds" namespace. To synchronously wait for the next WMI event call WaitForNextEvent() on the ManagementEventWatcher object. This call waits till the next instance of that event is available and then returns. The code snippet above performs an asynchronous read by setting the event handler to be called when an event arrives and then calling Start() on the ManagementEventWatcher object. This allows your application to get notified about WMI events while performing other tasks. The next code snippet shows an example of the EventArrived event handler (of the type EventArrivedEventHandler):

public void Delegate_EventArrived(object sender, EventArrivedEventArgs e)
{
// create a new event info
EventDetails Details = new EventDetails();
// get the event details
Details.Message = Convert.ToString(e.NewEvent.Properties["Message"].Value);
Details.Type = Convert.ToInt16(e.NewEvent.Properties["Type"].Value);
Details.Guid = Convert.ToString(e.NewEvent.Properties["Guid"].Value);
// now add the event to the list view
EventCollection.Add(new ListViewItem(new string[] { Details.Message,
Details.Type.ToString(), Details.Guid }));
}

The EventArrivedEventArgs.NewEvent contains a reference to the received WMI event and is of the type ManagementBaseObject. It provides access to the property collection of the WMI event which we use to read the event details and then we add the event to a list view. Finally if you do not want to receive any further events you call Stop() on the ManagementEventWatcher object and then Dispose() to free the underlying COM object. Here is a code snippet:

It is also very simple to subscribe and asynchronously receive WMI events. It is also very powerful to perform that against any machine on your network which has the WMI infrastructure installed, which all new Windows releases do. A good example would be a server application which you deploy onto multiple servers. How do you monitor it and make sure you get notified as soon as a critical error happens? With WMI you can achieve that fairly easily. When a critical error happens, you raise a WMI event. You then write a small application which subscribes to this WMI event on all the machines this server application is running on. And as soon as one raises an event, you can display it on a central console. This simple management tool could be very powerful and helpful for monitoring your server application. Microsoft provides such a management tool, just much more sophisticated-Microsoft Operations Manager 2005.

The attached sample application

The attached Windows form sample application provides an instrumentation provider as well as an instrumentation consumer. The provider application demonstrates how to create and publish class instances, how to revoke published class instances and how to raise WMI events. The consumer application demonstrates how to subscribe and asynchronously receive WMI events and how to query for instances of a WMI class. The provider application raises a WMI event when started as well as when closed. For more details see the included readme.htm file. Please note that Windows 2000 SP4, Windows XP SP2 or Windows 2003 SP1 (or KB836802 for Windows 2003) are required for subscribing to WMI events. This is due to a known bug in the WMI API.

A look at Microsoft Operations Manager 2005

There are a number of enterprise monitoring solutions on the market, one of them being Microsoft Operations Manager 2005. Microsoft IT uses MOM 2005 to manage its 6,000 or more servers in over 200 countries. This article will briefly explain how MOM 2005 works and how you can configure it to receive WMI events and raise alerts to IT operators. This is a very powerful way you can alert IT operators about critical errors happening in your application.

To install MOM 2005 launch setup and first perform the option "check prerequisite". Select all the items under "Microsoft Operations Manager 2005 components" and click Check. This will check that all the pre-requisites like Windows 2000 SP4 or Windows 2003, MDAC 2.8, SQL Server 2003 SP3a and the .NET framework 1.1 are installed on the machine. After all the pre-requisites are installed, go back to the main setup screen and select the option "Install Microsoft Operations Manager 2005". Select the typical installation which will again perform a pre-requisite check. The check will pass as we already made sure that all pre-requisites are installed. Next select the database server to use followed by the database size which needs to be at a minimum 300 MB. If you have multiple management servers running, then you can group them in one or multiple groups. The group name cannot be changed after the installation. Next you enter the group name to use, for example "Development". Next you enter the Windows account to be used by any action performed by this management server, for example to gather information from providers, install and uninstall agents, etc. Next you enter the Windows account to be used to access the MOM database server. Finally it asks whether to enable error reporting and whether to send them automatically to Microsoft - always a good idea. When the install is completed you find a new start menu item under "Programs | Microsoft Operations Manager 2005".

MOM 2005 consists of an "Administrator Console" and an "Operator Console". This separates very well the administrative tasks from the operational tasks. Administrative tasks are installing agents at new servers to monitor, setting up new event providers like a WMI event, setting up alert rules like "email or page an operator", etc. Operative tasks are looking at the health of monitored servers, reacting to alerts, analyzing event and alert information, etc. So Operators are the IT professionals who use MOM 2005 as a tool to look after the server and IT infrastructure they are responsible for. First launch the "Administrator Console" to set up MOM to receive the WMI events we are raising in our application. This shows the console tree on the left side and the "Information Center" on the right side. The information center gives you access to documentation, MOM downloads, the MOM home page, etc.

MOM utilizes so called Management Packs, which are a set of rules, providers, scripts, tasks, etc. A Management Pack encapsulates all the management aspects to monitor an application or infrastructure component. You can say it encapsulates all the knowledge to manage that application or component. The ISV of that application or component should provide the Management Pack, as the creators also know best how to monitor it and keep it running reliably. Microsoft internally mandates that all future server products/releases shipped need to provide a Management Pack. MOM installs out of the box with the "Microsoft Operations Manager 2005" Management Pack but ships with a number of other Management Packs which you can import, for example for SQL Server, Active Directory, Systems Management Server, IIS, DNS, etc. To import a Management Pack, click on the item "Management Pack" in the console tree and select "Import/Export Management Pack" from the popup menu. Next select that you want to import a Management Pack followed by the folder where the Management Pack is located. Your MOM 2005 CD has a folder called "ManagementPacks". Browse to it and on the next screen you find all the Management Packs available in that location. Select one or more Management Packs to import, for example "Microsoft SQL Server 2000" and "Microsoft Windows IIS". During the import it shows you a detailed progress screen. When done you will see new items appearing under the "Management Packs" item in the console tree. For example under "Rule and Groups" you see "Microsoft Windows Internet Information Services" and "Microsoft SQL Server". Underneath you find detailed event and alert rules which are recommended by those Microsoft product groups.

Creating your own Management Pack

As an ISV, it is very simple and also recommended to create your own Management Pack and ship that with your product. That makes it much simpler for IT groups to monitor and maintain your application. First create your own "Rule Group" where you define all the event and alert rules around your product. Under the item "Management Packs" you find the item "Rules and Groups". Right click on it, select "Create Rule Group" from the popup menu and enter the name and description describing your product (for example "Enterprise-Minds Instrumentation Sample"). On the following screen you enter the "Company Knowledge Base", which is really a description of the Management Pack and the product it monitors. Click on the "Edit" button to enter the text. When you are finished it asks whether to deploy the new "Rule Group" to a group of computers. Through this option you select the group of computers the rules in this "Rule Group" will apply to. Select "yes" and click the "Add" button to add a computer group. It shows you the list of defined computer groups. Double click on one if you want to see details about the computer group. The "Formula" tab shows the formula used to determine which computers belong to the group. If you run the sample application on the machine you installed MOM 2005 on, select the computer group "Microsoft Operations Manager 2005 Servers". After you selected one or more computer groups, click Ok to save the new "Rule Group".

Expand the newly created "Rule Group" with the plus sign in front of it. Next create a new event rule (events meaning MOM events collected). Right click on the item "Event Rule", select "Create Event Rule" from the popup menu and from the list select "Alert on or Respond to Event (Event)". First you select an existing event provider or create a new one. Create a new event provider by clicking on the button "New". The provider type we use is WMI, so select "WMI Events" from the list. Next enter the name of the new provider, for example "Enterprise-Minds WMI Event". Then you enter the namespace the WMI class is residing in which is, in our case, "root\enterpriseminds". Next you enter the WQL query this provider executes against WMI, which in this case is "SELECT * FROM EventDetails". To query only for certain properties, list the properties instead of the star, for example "SELECT Message, Type FROM EventDetails". This query returns any WMI event raised by the sample application. Another way to only return certain properties is to list the properties in the "Property list" field, for example "Message, Type". Click "finish" to create this new provider, which brings you back to the "Event Rule" creation process and selects the new provider in the drop down list.

On the next screen you could apply a filter if you don't want to receive all events, for example only receive events where the Type property has a value of one. Later in the article it is explained how to filter events based on the WMI event values. Next you could define that this rule only runs on certain days and times, the default being "process at any time". Next you can generate an alert by selecting the "Generate Alert" checkbox. Select a severity of the alert which is by default "Critical Error". Later in the article it is explained how you can generate different alerts based on the values provided by the WMI event. Next you select if you want to suppress duplicate alerts, which is the default selection, and which criteria are used to determine whether it is a duplicate alert. The default criterion used is if the alert comes from the same computer and domain. This reduces the amount of alerts an Operator has to deal with, as it is very likely that the same alert will be raised many times till the issue is resolved. It is enough that the Operator sees one alert which keeps the noise level down. Next you define response actions which should be executed when the event happens, for example execute this script which may restart an application. This allows automating some of the actions to be taken when this event happens. Next you enter a knowledgebase which allows you to describe the issue in detail and standard troubleshooting steps to be taken. This helps Operators to understand how to resolve an issue. Finally you give the event rule a name, for example "Instrumentation Sample Rule".

This is all you need to do to capture WMI events and raise alerts to Operators. In order for all the changes to take effect you need to right click on the item "Management Packs" and select "Commit Configuration Change" from the popup menu. By default, changes are only committed and take effect after five minutes. With this you can commit the changes right away. To change this default setting, select the item "Administrator | Global Settings". Then, in the list on the right side, select "Management Servers", double click the item you want to change and, on the "Rule Change Polling" tab of the dialog that comes up, change the time till changes are committed.

The IT Operator view in MOM 2005

IT Operators do not administrate MOM but rather have an operative view over all the servers and components they are responsible for. The "Operator Console" can be launched through the start menu "Programs | Microsoft Operations Manager 2005". The navigation pane on the left (same look as in Outlook 2003) lets you navigate to different views, the most important being the event, alert, state and performance views. The "event" view shows you all the events available. The "alert" view shows all the alerts which have been raised to the Operator. The "state" view provides a very quick and good overview of the health state of each computer. It shows all the main components monitored and the state of each. For example it can show that the overall health of the machine is "critical error". But the IIS and MOM Agent are healthy and the SQL component is the one which raised the "critical error". This helps a lot to understand very quickly which components on which servers need attention. Double clicking on a server in the state view shows all the alerts for this server. Events can then be used to get a much better understanding of what happened before, during, and after the time of error. The performance view shows performance for all the performance rules set up.

Next launch the "InstrumentationProviderForm" sample application attached to this article. Launching it will raise an EventDetails WMI event which MOM 2005 is now listening for. In the same application you can enter the event text, select the event type and then click the "Fire event" button to raise additional WMI events. Go back to the "Operator Console" and to the alerts view. You will see now an alert generated because of the WMI event fired by the sample application. Click on the alert and you will see its details in the lower "Alert Details" pane. In the alert details you see all the WMI event properties MOM received. You see first the system properties like __PATH (the WMI event path), __SUPERCLASS (the class this WMI event inherited from), etc. You then see also all the WMI event properties itself. Please take special note of the order they appear in. Later in the article when we set event filters and alert severity, you can select the properties by number. For example, the __PATH property is the fifth one so you can chose it by the name Parameter 5, the Message property is Parameter 10 and the Type property is Parameter 11. Also take special note of the value of the Type property. The property is of type integer in the .NET code but it is shown here as "0 (0x0)", "1 (0x1)", etc. So MOM reads the numeric value and converts it to a string which has in parenthesis the hexadecimal string representation of the value.

If you select the Event tab in the "Alert Details" pane then you see all the events which raised this alert. In the alert details there is a wealth of information available, such as when the alert was first and last raised. When the issue has been resolved, the Operator right clicks on the alert, selects "Set Alert Resolution State | Resolved" and then enters a description how it was resolved for future reference. Through that menu Operators can also set other alert statuses, such as that it has been assigned to a vendor or subject matter expert, or it might require a scheduled maintenance. When all alerts have been resolved then the health state is set back to "Success".

Filtering MOM events and setting alert severity levels

Let's go back into the Administrator Console and filter the MOM events, meaning we want to see only MOM events when the WMI event type is set to "Application Start" (value 0) or "Application Stop" (value 1). Open up the properties of the "Instrumentation Sample Rule" rule, go to the tab "Criteria" and select the "Advanced" button. Remember that the Type property is the Parameter 11. At the bottom select Parameter 11, select the Condition "equal", and enter as value "0 (0x0)" (remember it is converted to a string including the hexadecimal string representation in parenthesis). This criterion would return only events of the type "Application Start". Because we want to have all WMI events except the "User Initiated", we select the Condition "not equals" and the Value "2 (0x2)". Click on the button "Add To List" to add it to the criteria list. You can add multiple criteria, but each field can only be used for one criterion. If you want to edit a criterion then select it in the list on top and click the button Remove. This removes the criterion but shows it in the Field/Condition/Value controls at the bottom so you can change it and then add it again.

Save the event rule and don't forget to commit the configuration changes (right click on Management Packs and select "Commit Configuration Change" from the popup menu). Go back to the sample application and manually raise three events, setting the Type for each to "Application Start", "Application Stop" and "User Initiated". Go back to the Operator console and refresh the Events view (key F5) and you see only two events. Select each and check the value of the Type property and you will see that the one with the value "2 (0x2)" (which is "User Initiated") is not present, because it has been filtered. Switch to the alert view and you will see only one alert, because we suppress duplicates. Select the alert and select the Events tab in the "Alert Details" pane and you see the two events which raised the alert. Set the state of the alert to resolved so we have no alerts for our next scenario.

Now this time we want to get all events but for different values in the Type property we want to raise alerts with different severity. Bring up again the properties of the "Instrumentation Sample Rule" rule. First go to the Criteria tab and remove the filter (click on the Advanced button, select the criterion in the list and click the Remove button). Next go to the Alert tab and select the check box "Enable state alert properties". This allows us to create a complex rule which defines the severity on property values. Click on the Edit button beside the "Alert severity". Click Edit to edit the default condition added by MOM. The new dialog allows you to create a complex condition, and the severity level if that condition is met. Select Parameter 11 through the Parameter button on the left side. You see that it adds "AttributeValue(Parameter 11)" to the condition text box. Edit it so it says "AttributeValue(Parameter 11) = "0 (0x0)"" and set the alert severity to "Information" through the drop down list at the bottom. This condition says if the event Type property is set to "Application Start" then raise an information alert. Go back to the condition dialog and click on the Add button to add another condition. Select again Parameter 11, set the condition to "AttributeValue(Parameter 11) = "1 (0x1)"" and set the severity level to "Critical Error". This condition says when the event Type property is "Application Stop" then raise a "critical error" alert. Repeat the same steps to add a condition "AttributeValue(Parameter 11) = "2 (0x2)"" where the severity is set to warning. This condition says when the event Type property is "User Initiated" then raise a warning alert. Close the condition dialog, which brings you back to the alert tab on the event rule. We are raising now three different alerts, which means you also need to change the criteria used by MOM to suppress duplicate alerts. Set the "Server role" to "MOM Agent", the "Component" to "WMI" and for the Instance you select (through the arrow on the right) "Source Computer" and then "Parameter 11". This sets the Instance value to "$Source Computer$$Parameter 11$". So only duplicate alerts coming from the same machine with the same Parameter 11 value (which is the event Type property) are suppressed.

Commit the configuration changes and go back to the sample application. Manually raise three events again, setting the Type for each to "Application Start", "Application Stop" and "User Initiated". Go back to the Operator Console and you will see again three events, but you also see three different alerts. One with the severity "information", one with the severity "warning" and one with the severity "critical error". If you raise multiple events through the sample application you will also see that only one alert per severity is raised.

Creating your Management Pack

Now that we have created our provider, rule, and alerts, we want to package that up into a distributable Management Pack. This allows you to distribute this Management Pack to your customers. Right click on the item "Management Packs" and choose "Import/Export Management Pack" from the popup menu. Next select the option "Export Management Packs" which brings up the list of existing Rule Groups. Select the Rule Group "Instrumentation Sample Rule", meaning we want to export all event rules, alert rules and performance rules of this Rule Group. Next it allows you to select Views and Tasks to export. We have not created any views or tasks so we do not select any. Finally it asks for the name and location of the Management Pack to create, for example "c:\Enterprise-Minds Management Pack". The exported file ends with the extension "akm" and can be imported like any other Management Pack (see earlier in the article). The sample application attached includes the sample Management Pack we created in this article.

Note that you can also delete Rule Groups but only if there are no alerts present for the rules defined in that rule group. If there are alerts present it will show a message stating you can't delete the rule group because alerts are associated with it. Unfortunately there is no simple way to resolve this. MOM 2005 stores all information in the SQL Server database called OnePoint. Delete all the alerts from the following tables - AlertHistory, AlertEvent, AlertEventSuppression and Alert. This is very useful when you want to remove all rules, providers and alerts created and then test if the Management Pack you created includes all information and functions properly. This approach is only recommended for development environments. For production environments refer to the section "database grooming" in the MOM 2005 documentation.

Summary

WMI and Microsoft Operations Manager 2005 provide a compelling and simple way to make available sophisticated management instrumentation for your enterprise applications. The .NET framework makes it easy to create your own WMI classes and events, and registers them for you in the WMI store. Exposing WMI class instances and raising WMI events is very easy. The declarative style using attributes makes it especially intuitive. Also, querying the WMI store for class instances and subscribing to receive WMI events asynchronously is fairly simple. This allows you to create your own simple management tools. MOM 2005 is a very compelling management tool for your IT infrastructure and applications. It provides sophisticated information gathering and analyzing capabilities which gather a wealth of information but only alert operators to relevant information. MOM 2005 excels with its new Operator Console specifically targeted at the IT operator, and its new "health state" view which provides a very good overview of machine and component health statuses. MOM provides many more features which are beyond the scope of this article.

The second part of this article will dive deeper into the WMI store, classes and class instances. WMI can provide a wealth of information about a machine. The sample application for the second article will provide a "WMI System Browser" which enables you to find Windows and hardware serial numbers, a list of installed OS hotfixes, a list of processors with clock speed and current processor status information, and much more. The article will cover how to programmatically create and edit class and class instance information. If you have comments to this article, please contact me @ [email protected] . I want to hear if you learned something new. Contact me if you have questions about this topic or article.