Monitoring Application Health with WMI and .NET

Francis A. Shanahan

The Windows Management Instrumentation framework is one of the least publicized yet most useful tools in the .NET Framework. If your job is to create enterprise class software, you don't need to lie awake at night wondering whether your application is still running. In this article, Francis Shanahan shows you how to build enterprise class peace-of-mind into your .NET software and finally get the sleep you deserve!

I don't know much about cars. Some folks can tell the mileage just by listening to the engine. When I drive down the road, I look at the instruments on the dashboard to understand how the car's running. The oil, the temperature, the gas gauges, and so forth all provide information on how to manage the car. As the administrator of that vehicle, I'm clueless without instrumentation.

The computing industry has recognized this same need for instrumentation in enterprise software. In 1992 the Desktop Management Task Force (DMTF) consortium was formed by BMC, Cisco, Compaq, Intel, Microsoft, and a number of others to solve this need. The DMTF published the Common Information Model (CIM), which provides a standard definition for management information including detailed data around operating systems, processors, disks, networks, and so on.

Most recently the DMTF issued the Web-Based Enterprise Management (WBEM), which is "a set of management and Internet standard technologies developed to unify the management of enterprise computing environments." The WBEM provides information or "management data" in a structured manner that extends the CIM.

Windows Management Instrumentation (WMI) is Microsoft's implementation of WBEM. WMI is currently built into Windows 2000 and XP and will also be supported in the upcoming release of Longhorn. I'll show you how to use WMI to access management data and even enhance the CIM schema to support your own applications.

Integrating WMI support with Visual Studio

Before I dive into the WMI and what it can do, take a second and grab the Management Extensions plug-in for Visual Studio from http://msdn.microsoft.com/library/default.asp?url=/downloads/list/wmi.asp. Installing this plug-in will add two nodes, Management Classes and Management Events, to the Server Explorer in Visual Studio. A version is also available for Studio 2002 if you've yet to upgrade. After you install the Management Extensions, you should add your machine to the Server Explorer (see Figure 1).

Right-click and select "Add Server..." You can navigate to any machine within your network and add it to the Explorer. In some cases you may need to add machines using a username and password different from the user you're logged in as. In Figure 1, BULLDOG is my machine name and the Management Classes node is expanded. You'll notice there's nothing under Management Events yet; more on that later. I'll focus on management classes first.

Using management classes in .NET

The WMI Management Extensions allow you to literally drag and drop managed classes from the Server Explorer onto your forms. You can then use these classes to get information like disk space, available network bandwidth, memory usage, CPU utilization, and more. At this point I recommend you create a simple Web application if you'd like to follow along with the code. I'm using a Web application named "HardcoreWMI" but a Windows Forms application will work equally well.

Once you have your basic application up and running, go ahead and drag a few management classes onto your Web form. When you drop classes onto your form, a wrapper class is generated that encapsulates all of the properties and methods within that management class. You'll need to add the System.Management.dll namespace to your project's references. Table 1 describes the classes I chose for this example.

Table 1. Management classes along with their location and wrapper classes.

Management class	Located under	Resulting wrapper class
ComputerSystem	My Computer	Root.CIMV2.Win32_ComputerSystem.VB
LogicalDisk	Disk Volumes	Root.CIMV2.Win32_LogicalDisk.VB
Processor	Processors	Root.CIMV2.Win32_Processor.VB
Service	Services (I chose the SQL Server process, but you can pick any service you're interested in managing)	Root.CIMV2.Win32_Service.VB

Along with the wrapper classes, an instance of the wrapper is created, so, for example, your form will now have a ComputerSystem1 local variable that's an instance of root.Cimv2.Win32_ComputerSystem. IntelliSense will give you an idea what methods and properties are available (see Listing 1).

The wrapper classes created make it really easy to query the various WMI enabled objects. You'll notice the name of the classes follows a pattern, too. Root/Cimv2/Win32_ComputerSystem is the name of the class in the CIM schema.

Listing 1. Reading the size and available space in GB from the LogicalDisk1 object.

Dim diskSize As Double = _
  Convert.ToInt64(LogicalDisk1.Size) / _
 (1024 * 1024 * 1024)
Dim freeSpace As Double = _
  Convert.ToInt64(LogicalDisk1.FreeSpace) / _
  (1024 * 1024 * 1024)

The schema and WQL

In the case of properties on a management class, the information is fairly standard. What about cases where you want specific information that isn't readily available in the properties? This is a situation for an explicit WBEM Query Language (WQL) statement. WQL works just like SQL but for WBEM data. The syntax is very similar to SQL in that it uses SELECT statements to define the objective of the query and WHERE clauses to limit the query results. WMI provides a built-in utility called WBEMTest.exe, which you can use to try out some WQL for yourself.

Click Start | Run and type WBEMTest to launch the utility. Before you can use WBEMTest, you must connect to a schema. Click Connect, type root/cimv2 in the Namespace dialog, and click Connect. This connects you to the main node for the CIM schema (version 2) on your local machine (see Figure 2). You could also connect to another machine's schema with //<machinename>/root/Cimv2 to access that machine's data remotely.

If you do try this, you'll need to disable any firewalls you have running on source and target, as this tool uses a random port to communicate across the network.

You don't have to connect to the cimv2 node necessarily. As you'll see later on in this article, you can add your own branches to the schema and publish data to those nodes.

You can query just about any element of the schema. So what are those elements? Click Enum Classes and then hit OK to enumerate all classes from /root/cimv2 down. To try out a WQL query, click Query and enter some WQL (see Table 2).

Table 2. Example WQL queries.

WQL statement	Description
SELECT * FROM win32_NTLogEvent WHERE logfile = 'system'	Lists all contents of the System Event log.
SELECT * FROM win32_PerfRawData_PerfProc_Process WHERE name = 'Idle'	Retrieves information on the system idle process.
SELECT freespace, size FROM win32_LogicalDisk WHERE caption='c:'	Gets the total disk space and the amount of free space on the c: volume.
SELECT name, description FROM Win32_Service WHERE state="Stopped"	Lists all services that are currently stopped on the machine.

You'll notice you can use single quotes or double quotes in your WQL statements. A note of caution: Some of these queries can return a lot of data if not restricted by a WHERE clause. Be careful not to send your machine into a death spiral.

Invoking WQL from code

Getting back to the demo application, I want to invoke a WQL statement from within .NET code. To make things interesting, I'll add a textbox to my form to allow the user to enter the WQL statement and a button to execute that statement. When the user clicks the button, I'll use the WMI classes in the System.Management namespace to run the query (see Listing 2).

Listing 2. How to run an arbitrary WQL statement using System.Management classes.

Sub ExecuteWQLQuery(ByVal strWQL As String)
   ' Create a query 
   Dim mySelect As New SelectQuery(strWQL)

   ' Initialize an object searcher w/this query
   Dim myResults As New ManagementObjectSearcher(mySelect)
   Dim myProperty As PropertyData

   ' Iterate through the resulting collection
   For Each wmiObject In myResults.Get()
      ' print out each name/value pair
      For Each myProperty In wmiObject.Properties
          lblInfo.Text &= "<br>" & myProperty.Name _
               & "=" & Convert.ToString(myProperty.Value)
      Next
   Next wmiObject
End Sub

In Listing 2, I've added some code to iterate through the resulting collection and display the results. It's important to note that the WBEM and WMI is an object-oriented approach to management data. APIs return objects, not flat non-hierarchical information. These WMI objects can be used to affect the underlying managed entities as well as monitor them. In this manner you can programmatically control your software and hardware devices. In a real-world situation, you could restart a machine, launch a service, schedule a check-disk, or even remove a machine from a domain.

In Listing 3, I invoke the StartService method. I could have used a generated class similar to the earlier examples, but the purpose of the article is to show you the possibilities!

Listing 3. Invoking a method on a Managed object.

' Create a new path to the windows service 
Dim myPath As ManagementPath = New ManagementPath
myPath.Server = System.Environment.MachineName
myPath.NamespacePath = "root/CIMV2"

' Set the service name from the user's input box
myPath.RelativePath = "Win32_Service.Name='" + _
  txtServiceName.Text + "'"

' Create a new management object
' that represents the service
Dim myService As ManagementObject = _
  New ManagementObject(myPath)

' Invoke the StartService method
Dim returnObject As ManagementBaseObject = _
  myservice.InvokeMethod("StartService", Nothing, _
  Nothing)

You've seen how to examine the schema and also how to remotely execute methods on a managed class using WMI. In the next section, I describe how to add or extend the schema for your own applications and how to publish information to that schema extension.

Instrumenting your application

Earlier you saw that the Management Extensions plug-in adds a Management Events node to the Server Explorer. Right now that node is empty, but I'm going to show you how to create your own custom WMI events and fire them from within your code. This process is known as Instrumenting and is fairly simple regardless of whether your application is ASP.NET-based or Windows Forms-based. An understanding of attributes is useful for this discussion but not essential. Attributes deserve their own article, but if you've never seen an attribute before, you can think of it as a way of decorating your code with additional information that a third party can read at runtime.

In the COM days, it was necessary to create an entire extra class known as a WMI Provider to provide information to WMI. In the .NET world, we can achieve the same effect with much less effort. The first thing to do is tag your assembly with the Instrumented attribute. I typically put this attribute in the AssemblyInfo.vb file, but you can put it anywhere in the assembly's code.

<Assembly: Instrumented("root/HardcoreWMI")> 

This attribute will be read during installation, and the machine's schema will be modified to include the namespace from the instrumented tag–in this case, the root/HardcoreWMI namespace. If your application doesn't already have an installer class, it will be necessary to add one. If you don't want a full-blown customized installation, the following snippet is all that's needed:

<System.ComponentModel.RunInstaller(True)> _
Public Class SimpleInstaller
    Inherits DefaultManagementProjectInstaller
End Class

To fire a custom event, you need a custom event class. All that's required to turn a class into a WMI event class is the InstrumentationType.Event Attribute. This attribute-driven approach makes it extremely simple to instrument your application.

<InstrumentationClass(InstrumentationType.Event)> _
Public Class HardcoreEvent
    Public hardcoreMessage As String
    Public methodName As String
End Class

To fire this event, I use the following:

System.Management.Instrumentation. _
   Instrumentation.Fire(myEvent)

The demo code associated with this article provides a button that fires this event. In production code, you might consider firing the event from within your exception handler. Once the application is built, it's necessary to register that assembly's namespace within the schema. You do this by installing the assembly using the installUtil.exe provided with the .NET Framework. In a command window, navigate to your built assembly's folder and type installUtil <AssemblyName> to register your application with the schema.

Once an event is fired, it's available to any WMI capable application, including Microsoft Operations Manager or the Management Event node of Visual Studio. To capture these events in Studio, right-click on Management Events, click Add Event Query..., and select Custom from the Event Type radio buttons. If you've run the installUtil as described earlier, you should see your application's node in the schema. If you expand the node, you'll see the custom event in the tree (see Figure 3).

Clicking OK will add an Event Query to your Visual Studio Server Explorer. When you run the demo and click Fire Custom Event, the Event Query will be triggered and print the event details to the output window.

The Event model in .NET uses delegates to allow multiple consumers for a single event. Your .NET code can consume these events synchronously by blocking until the event is fired, or asynchronously by using a ManagementEventWatcher (see Listing 4). You'll notice that since this is an asynchronous listener, I need to set up a delegate function to handle the event when it fires. In Listing 4, that function is called HandleEvent. The demo code for this article implements Listing 4 in a Windows Forms application.

Listing 4. Asynchronously listen for custom WMI events.

Dim wmiListener As New ManagementEventWatcher
' myQuery listens for HardcoreEvents to 
' fire every 5 seconds
Dim myQuery As New WqlEventQuery( _
  "HardcoreEvent", New System.TimeSpan(5))
wmiListener.Query = myQuery

' Set up a delegate to fire when the
' event arrives
AddHandler wmiListener.EventArrived, _
  AddressOf HandleEvent
wmiListener.Scope.Path.Server = "BULLDOG"
wmiListener.Scope.Path.NamespacePath = _
  "root/HardcoreWMI"
' Start listening
wmiListener.Start()

The final piece of the puzzle is to publish entire classes to the schema. I've already shown how events can be published through the use of attributes. Entire classes can be published in the same manner.

<InstrumentationClass(InstrumentationType.Instance)> _
Public Class HardcoreBusinessObject
    Private _firstName As String

In this snippet I've tagged my class, HardcoreBusinessObject, with the .Instance attribute. You can now publish this class with:

Instrumentation.Publish(myEntity) 

myEntity is an instance of HardcoreBusinessObject. You can test this mechanism through Visual Studio: Right-click Management Classes and select Add Classes..., and then choose your applications' node and expand it until you come to the instrumented class. Click Add and OK. Now when the class is published to WMI, that instance becomes available to the Server Explorer (see Figure 4).

The sample applications

The provided solution contains two projects, a Web application and a Windows Forms application. In each case you need to update the machine name to the machine you're monitoring. Do a search and replace to replace "BULLDOG" with your own machine name. From the Web application you can do the following:

• Execute a WQL query.
• View statistics on the local machine through a generic dial type user control that indicates min, max, and current values for a particular data point.
• Publish an instance of a dummy business object–in this case, "HardcoreBusinessObject"–and view the published instance in Server Explorer.
• Start a service. The sample defaults to the SQLSERVER service, but you can enter any service name you'd like.
• Fire a custom event. You can verify the event has fired by building an Event Query as described earlier in this article.

The Windows Forms application will listen asynchronously for the custom event to fire. Once it fires, the event data is retrieved from WMI and added to the list box on the form.

What this article hasn't covered

This article has only scratched the surface in terms of what's possible with WMI. Other areas of interest not covered here are:

• Integration with other WMI consumers, such as Microsoft Operations Manager. Using WMI will allow your application to integrate with Microsoft Operations Manager out of the box.
• Security and access to data, all of which is accounted for in the current WMI spec. Windows 2000 and above actually ship with an MMC snap-in to allow management of security privileges, logging, and backup of WMI data.
• Consumption of SNMP traps. SNMP traps can be consumed through the WMI interfaces in a similar manner to the mechanism shown here. See the "References" sidebar for a link that provides more detail about SNMP.
• Exposure of management data through Web Services.

Table 1. Management classes along with their location and wrapper classes.

Management class	Located under	Resulting wrapper class
ComputerSystem	My Computer	Root.CIMV2.Win32_ComputerSystem.VB
LogicalDisk	Disk Volumes	Root.CIMV2.Win32_LogicalDisk.VB
Processor	Processors	Root.CIMV2.Win32_Processor.VB
Service	Services (I chose the SQL Server process, but you can pick any service you're interested in managing)	Root.CIMV2.Win32_Service.VB

Along with the wrapper classes, an instance of the wrapper is created, so, for example, your form will now have a ComputerSystem1 local variable that's an instance of root.Cimv2.Win32_ComputerSystem. IntelliSense will give you an idea what methods and properties are available (see Listing 1).

The wrapper classes created make it really easy to query the various WMI enabled objects. You'll notice the name of the classes follows a pattern, too. Root/Cimv2/Win32_ComputerSystem is the name of the class in the CIM schema.

Listing 1. Reading the size and available space in GB from the LogicalDisk1 object.

Dim diskSize As Double = _
  Convert.ToInt64(LogicalDisk1.Size) / _
 (1024 * 1024 * 1024)
Dim freeSpace As Double = _
  Convert.ToInt64(LogicalDisk1.FreeSpace) / _
  (1024 * 1024 * 1024)

The schema and WQL

In the case of properties on a management class, the information is fairly standard. What about cases where you want specific information that isn't readily available in the properties? This is a situation for an explicit WBEM Query Language (WQL) statement. WQL works just like SQL but for WBEM data. The syntax is very similar to SQL in that it uses SELECT statements to define the objective of the query and WHERE clauses to limit the query results. WMI provides a built-in utility called WBEMTest.exe, which you can use to try out some WQL for yourself.

Click Start | Run and type WBEMTest to launch the utility. Before you can use WBEMTest, you must connect to a schema. Click Connect, type root/cimv2 in the Namespace dialog, and click Connect. This connects you to the main node for the CIM schema (version 2) on your local machine (see Figure 2). You could also connect to another machine's schema with //<machinename>/root/Cimv2 to access that machine's data remotely.

If you do try this, you'll need to disable any firewalls you have running on source and target, as this tool uses a random port to communicate across the network.

You don't have to connect to the cimv2 node necessarily. As you'll see later on in this article, you can add your own branches to the schema and publish data to those nodes.

You can query just about any element of the schema. So what are those elements? Click Enum Classes and then hit OK to enumerate all classes from /root/cimv2 down. To try out a WQL query, click Query and enter some WQL (see Table 2).

Table 2. Example WQL queries.

WQL statement	Description
SELECT * FROM win32_NTLogEvent WHERE logfile = 'system'	Lists all contents of the System Event log.
SELECT * FROM win32_PerfRawData_PerfProc_Process WHERE name = 'Idle'	Retrieves information on the system idle process.
SELECT freespace, size FROM win32_LogicalDisk WHERE caption='c:'	Gets the total disk space and the amount of free space on the c: volume.
SELECT name, description FROM Win32_Service WHERE state="Stopped"	Lists all services that are currently stopped on the machine.

You'll notice you can use single quotes or double quotes in your WQL statements. A note of caution: Some of these queries can return a lot of data if not restricted by a WHERE clause. Be careful not to send your machine into a death spiral.

Invoking WQL from code

Getting back to the demo application, I want to invoke a WQL statement from within .NET code. To make things interesting, I'll add a textbox to my form to allow the user to enter the WQL statement and a button to execute that statement. When the user clicks the button, I'll use the WMI classes in the System.Management namespace to run the query (see Listing 2).

Listing 2. How to run an arbitrary WQL statement using System.Management classes.

Sub ExecuteWQLQuery(ByVal strWQL As String)
   ' Create a query 
   Dim mySelect As New SelectQuery(strWQL)

   ' Initialize an object searcher w/this query
   Dim myResults As New ManagementObjectSearcher(mySelect)
   Dim myProperty As PropertyData

   ' Iterate through the resulting collection
   For Each wmiObject In myResults.Get()
      ' print out each name/value pair
      For Each myProperty In wmiObject.Properties
          lblInfo.Text &= "<br>" & myProperty.Name _
               & "=" & Convert.ToString(myProperty.Value)
      Next
   Next wmiObject
End Sub

In Listing 2, I've added some code to iterate through the resulting collection and display the results. It's important to note that the WBEM and WMI is an object-oriented approach to management data. APIs return objects, not flat non-hierarchical information. These WMI objects can be used to affect the underlying managed entities as well as monitor them. In this manner you can programmatically control your software and hardware devices. In a real-world situation, you could restart a machine, launch a service, schedule a check-disk, or even remove a machine from a domain.

In Listing 3, I invoke the StartService method. I could have used a generated class similar to the earlier examples, but the purpose of the article is to show you the possibilities!

Listing 3. Invoking a method on a Managed object.

' Create a new path to the windows service 
Dim myPath As ManagementPath = New ManagementPath
myPath.Server = System.Environment.MachineName
myPath.NamespacePath = "root/CIMV2"

' Set the service name from the user's input box
myPath.RelativePath = "Win32_Service.Name='" + _
  txtServiceName.Text + "'"

' Create a new management object
' that represents the service
Dim myService As ManagementObject = _
  New ManagementObject(myPath)

' Invoke the StartService method
Dim returnObject As ManagementBaseObject = _
  myservice.InvokeMethod("StartService", Nothing, _
  Nothing)

You've seen how to examine the schema and also how to remotely execute methods on a managed class using WMI. In the next section, I describe how to add or extend the schema for your own applications and how to publish information to that schema extension.

Instrumenting your application

Earlier you saw that the Management Extensions plug-in adds a Management Events node to the Server Explorer. Right now that node is empty, but I'm going to show you how to create your own custom WMI events and fire them from within your code. This process is known as Instrumenting and is fairly simple regardless of whether your application is ASP.NET-based or Windows Forms-based. An understanding of attributes is useful for this discussion but not essential. Attributes deserve their own article, but if you've never seen an attribute before, you can think of it as a way of decorating your code with additional information that a third party can read at runtime.

In the COM days, it was necessary to create an entire extra class known as a WMI Provider to provide information to WMI. In the .NET world, we can achieve the same effect with much less effort. The first thing to do is tag your assembly with the Instrumented attribute. I typically put this attribute in the AssemblyInfo.vb file, but you can put it anywhere in the assembly's code.

<Assembly: Instrumented("root/HardcoreWMI")> 

This attribute will be read during installation, and the machine's schema will be modified to include the namespace from the instrumented tag–in this case, the root/HardcoreWMI namespace. If your application doesn't already have an installer class, it will be necessary to add one. If you don't want a full-blown customized installation, the following snippet is all that's needed:

<System.ComponentModel.RunInstaller(True)> _
Public Class SimpleInstaller
    Inherits DefaultManagementProjectInstaller
End Class

To fire a custom event, you need a custom event class. All that's required to turn a class into a WMI event class is the InstrumentationType.Event Attribute. This attribute-driven approach makes it extremely simple to instrument your application.

<InstrumentationClass(InstrumentationType.Event)> _
Public Class HardcoreEvent
    Public hardcoreMessage As String
    Public methodName As String
End Class

To fire this event, I use the following:

System.Management.Instrumentation. _
   Instrumentation.Fire(myEvent)

The demo code associated with this article provides a button that fires this event. In production code, you might consider firing the event from within your exception handler. Once the application is built, it's necessary to register that assembly's namespace within the schema. You do this by installing the assembly using the installUtil.exe provided with the .NET Framework. In a command window, navigate to your built assembly's folder and type installUtil <AssemblyName> to register your application with the schema.

Once an event is fired, it's available to any WMI capable application, including Microsoft Operations Manager or the Management Event node of Visual Studio. To capture these events in Studio, right-click on Management Events, click Add Event Query..., and select Custom from the Event Type radio buttons. If you've run the installUtil as described earlier, you should see your application's node in the schema. If you expand the node, you'll see the custom event in the tree (see Figure 3).

Clicking OK will add an Event Query to your Visual Studio Server Explorer. When you run the demo and click Fire Custom Event, the Event Query will be triggered and print the event details to the output window.

The Event model in .NET uses delegates to allow multiple consumers for a single event. Your .NET code can consume these events synchronously by blocking until the event is fired, or asynchronously by using a ManagementEventWatcher (see Listing 4). You'll notice that since this is an asynchronous listener, I need to set up a delegate function to handle the event when it fires. In Listing 4, that function is called HandleEvent. The demo code for this article implements Listing 4 in a Windows Forms application.

Listing 4. Asynchronously listen for custom WMI events.

Dim wmiListener As New ManagementEventWatcher
' myQuery listens for HardcoreEvents to 
' fire every 5 seconds
Dim myQuery As New WqlEventQuery( _
  "HardcoreEvent", New System.TimeSpan(5))
wmiListener.Query = myQuery

' Set up a delegate to fire when the
' event arrives
AddHandler wmiListener.EventArrived, _
  AddressOf HandleEvent
wmiListener.Scope.Path.Server = "BULLDOG"
wmiListener.Scope.Path.NamespacePath = _
  "root/HardcoreWMI"
' Start listening
wmiListener.Start()

The final piece of the puzzle is to publish entire classes to the schema. I've already shown how events can be published through the use of attributes. Entire classes can be published in the same manner.

<InstrumentationClass(InstrumentationType.Instance)> _
Public Class HardcoreBusinessObject
    Private _firstName As String

In this snippet I've tagged my class, HardcoreBusinessObject, with the .Instance attribute. You can now publish this class with:

Instrumentation.Publish(myEntity) 

myEntity is an instance of HardcoreBusinessObject. You can test this mechanism through Visual Studio: Right-click Management Classes and select Add Classes..., and then choose your applications' node and expand it until you come to the instrumented class. Click Add and OK. Now when the class is published to WMI, that instance becomes available to the Server Explorer (see Figure 4).

The sample applications

The provided solution contains two projects, a Web application and a Windows Forms application. In each case you need to update the machine name to the machine you're monitoring. Do a search and replace to replace "BULLDOG" with your own machine name. From the Web application you can do the following:

• Execute a WQL query.
• View statistics on the local machine through a generic dial type user control that indicates min, max, and current values for a particular data point.
• Publish an instance of a dummy business object–in this case, "HardcoreBusinessObject"–and view the published instance in Server Explorer.
• Start a service. The sample defaults to the SQLSERVER service, but you can enter any service name you'd like.
• Fire a custom event. You can verify the event has fired by building an Event Query as described earlier in this article.

The Windows Forms application will listen asynchronously for the custom event to fire. Once it fires, the event data is retrieved from WMI and added to the list box on the form.

What this article hasn't covered

This article has only scratched the surface in terms of what's possible with WMI. Other areas of interest not covered here are:

• Integration with other WMI consumers, such as Microsoft Operations Manager. Using WMI will allow your application to integrate with Microsoft Operations Manager out of the box.
• Security and access to data, all of which is accounted for in the current WMI spec. Windows 2000 and above actually ship with an MMC snap-in to allow management of security privileges, logging, and backup of WMI data.
• Consumption of SNMP traps. SNMP traps can be consumed through the WMI interfaces in a similar manner to the mechanism shown here. See the "References" sidebar for a link that provides more detail about SNMP.
• Exposure of management data through Web Services.

  • The Enterprise Instrumentation Framework (EIF) from Microsoft. This framework is built on top of things like WMI, the Event Log, and Tracing to unify all of these management tools into a common framework.

Conclusion

Hopefully this article has opened your eyes to the wealth of information that WMI provides. You've seen how to integrate WMI with Visual Studio and how to drag and drop management classes into your applications. Most importantly, I've shown you how to create your own WMI provider with management events and classes. With a little creativity you should be able to fully instrument your applications, thus allowing your administrator to stop and refuel next time before the server runs out of gas.

Download 404SHANAHAN.ZIP

Sidebar: References

• The Microsoft home page of WMI–http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_wmi.asp
• Diagnosis of "RPC Server is Unavailable" errors, which you may encounter when connecting to other machines in Visual Studio .NET–http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224370
• Full list of operating system and WMI component availability–http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/operating_system_availability_of_wmi_components.asp
• SNMP events–http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/receiving_snmp_events.asp
• For more information on the DMTF and its direction–www.dmtf.org

To find out more about Hardcore Visual Studio and Pinnacle Publishing, visit their Web site at http://www.pinpub.com/

Note: This is not a Microsoft Corporation Web site. Microsoft is not responsible for its content.

This article is reproduced from the April 2004 issue of Hardcore Visual Studio. Copyright 2004, by Pinnacle Publishing, Inc., unless otherwise noted. All rights are reserved. Hardcore Visual Studio is an independently produced publication of Pinnacle Publishing, Inc. No part of this article may be used or reproduced in any fashion (except in brief quotations used in critical articles and reviews) without prior consent of Pinnacle Publishing, Inc. To contact Pinnacle Publishing, Inc., please call 1-800-788-1900.