共用方式為

WMI Events in OpsMgr 2007

  • 發行項

I've already explained how to work with WMI events in MOM 2005 in an article in TechNet Magazine.  Most of the information in that article still applies since it covers the basics of how WMI events work and how to write a query to detect them.  What has changed significantly though is how to use them in Operations Manager.  I suppose a follow up article would be in order, but a simple blog post should be enough to give you the information you need.

First of all, WMI events in OpsMgr 2007 are used for exactly the same purpose as in MOM 2005.  The one big difference is that we no longer have WMI providers for OpsMgr objects to monitor for things like the modification of an alert.  We're working on such a different platform though, that those old scenarios don't really apply anymore anyway. 

I'm going to speak completely in terms of the Operations Console since that's where most people work with Operations Manager - at least at this early stage of its life.  If you're more comfortable working directory with the XML of a management pack, then you'll know exactly what pieces of this information to pull out.

You can create a monitor or rule for a WMI event using the appropriate wizard in the Operations Console.  If I have to guide you to those or define the different between an rule and a monitor, then you probably want to start on some more basic monitoring before tackling this topic.  The namespace and query are going to be exactly the same as the ones you created in MOM 2005.  Again, check my TechNet article if you need some help there.

WMI Event Filter Expressions 

As discussed in my article, you can specify criteria in the WMI query itself, or you can write a general query and specify the criteria separately.  In MOM 2005, that meant specifying criteria in the rule.  In OpsMgr 2007, you need to provide a filter expression.  The question is how to build it.

The wizard for creating a WMI Event monitor/rule actually won't let you specify no criteria.  The Next button won't be active until you provide some entry.  If you have a query that doesn't need any filter (which is entirely reasonable), then just specify some bogus filter.  Once the monitor/rule is created, open up its properties and delete the filter.  It's entirely valid to have a monitor/rule with no filter - the wizard just doesn't let you do it.

If you are going to provide filter, the parameter name needs to be in following format:

Collection[@Name='TargetInstance']/Property[@Name=<property name>]

Example - No Filter 

We can show this with a simple example.  Let's fire the rule when Notepad starts.  One method would be to use the following criteria with no filter:

SELECT * FROM __InstanceCreationEvent WITHIN 30 WHERE TargetInstance ISA 'win32_process' AND TargetInstance.Name = 'notepad.exe'

Example - Filter 

The second option would be to use the following query:

SELECT * FROM __InstanceCreationEvent WITHIN 30 WHERE TargetInstance ISA 'win32_process'

with the following filter:

Parameter Name: Collection[@Name='TargetInstance']/Property[@Name='Name'] equals
Operator: Equals
Value: notepad.exe

Comments

  • Anonymous
    January 01, 2003
    Summary This document will provide guidance to online links, resources, tools and blogs to assist in