How WMI Event Notification Works

Microsoft® Windows® 2000 Scripting Guide

« Previous | Next »   

Just as there is a WMI class that represents each type of system resource that can be managed using WMI, there is a WMI class that represents each type of WMI event. When an event that can be monitored by WMI occurs, an instance of the corresponding WMI event class is created. A WMI event occurs when that instance is created.

There are three major types of WMI event classes, all of which are derived from the __Event WMI class: Intrinsic Events, Extrinsic Events, and Timer Events. Intrinsic Events, in turn, are represented by three distinct classes derived from the __Event class: __NamespaceOperationEvent, __InstanceOperationEvent, and __ClassOperationEvent.

Note

• Timer events are seldom, if ever, used in system administration scripts and are not discussed in this chapter.

The __Event-derived classes must be present in each namespace that includes resources that can be monitored using WMI. The hierarchy of __Event-derived classes in the \root\default namespace is shown in Figure 6.5.

Figure 6.5   Event Class Hierarchy

Event Class Hierarchy

Intrinsic Events

Intrinsic events are used to monitor a resource represented by a class in the CIM repository. Each resource is represented by an instance of a class. This means that monitoring a resource using WMI actually involves monitoring the instances that correspond to the resource.

Intrinsic events can also be used to monitor changes to a namespace or class in the repository. However, monitoring changes to namespaces or classes is of limited value to system administrators.

An intrinsic event is represented by an instance of a class derived from __InstanceOperationEvent, __NamespaceOperationEvent, or __ClassOperationEvent. Any changes to instances in WMI are represented by the __InstanceOperationEvent class and the classes derived from it: __InstanceCreationEvent, __InstanceModificationEvent, and __InstanceDeletionEvent.

Monitoring resources using WMI involves monitoring instances and all changes to instances are represented by __InstanceOperationEvent and the classes derived from it. This means that monitoring resources ultimately involves monitoring instances of __InstanceOperationEvent-derived classes.

You register interest in instances of one of these classes by issuing a notification query expressed in WQL. The query uses syntax similar to the following:

SELECT * FROM __InstanceOperationEventOrDerivedClass WITHIN PollingInterval WHERE TargetInstance ISA WMIClassName AND TargetInstance.WMIClassPropertyName = Value

The __InstanceOperationEvent-derived classes you register interest in depend on the event you want to monitor.

Creation of a resource: __InstanceCreationEvent

Suppose you are interested in receiving a notification if Notepad is run on a certain computer. When Notepad runs, a corresponding process is created. Processes can be managed by using WMI and are represented by the Win32_Process class. When Notepad starts running, a corresponding instance of the Win32_Process class becomes available through WMI. If you have registered your interest in this event (by issuing the appropriate event notification query), the availability of this instance results in the creation of an instance of the __InstanceCreationEvent class.

Notification queries that request notification of the creation of a resource and use intrinsic events all use syntax similar to the following:

SELECT * FROM __InstanceCreationEvent WITHIN PollingInterval WHERE TargetInstance ISA 'Win32_Process' and TargetInstance.Name = 'notepad.exe'

Modification of a resource: __InstanceModificationEvent

Suppose you suspect that a management application you are using is erroneously changing the startup type of a service on one of your servers. You want to write a WMI script to monitor any modifications made to the configuration of the service. As soon as a modification is made to a service, its corresponding TargetInstance reflects the modification.

If you register your interest in this event, a modification to the configuration of the service results in the creation of an instance of the __InstanceModificationEvent class.

Notification queries that request notification of the modification of a resource and use intrinsic events all use syntax similar to the following:

SELECT * FROM __InstanceModificationEvent WITHIN PollingInterval WHERE TargetInstance ISA 'Win32_Service' and TargetInstance.Name = 'alerter'

Deletion of a resource: __InstanceDeletionEvent

If you want to ensure that a particular antivirus scanner program continues to run on a computer, you can write a script that monitors the processes on the computer to determine whether any of them stop.

Notification queries that request notification of the deletion of a resource and use intrinsic events all use syntax similar to the following:

SELECT * FROM __InstanceDeletionEvent WHERE TargetInstance ISA 'Win32_Process' and TargetInstance.Name = 'notepad.exe'

Extrinsic Events

Extrinsic events are used to monitor a resource that is not represented by a class in the CIM repository. For example, to monitor whether a process modifies an entry in the registry, you make use of extrinsic events. There is no WMI class that represents a registry entry, so you cannot use intrinsic events. (If you are interested in learning how to write scripts to monitor registry keys, subkeys, and entries, see "Registry" in this book.)

Scripts that make use of extrinsic events follow the same three steps as scripts that use intrinsic events. However, when you register to receive extrinsic events, you will not refer to an event class derived from __InstanceOperationEvent, __ClassOperationEvent, or __NamespaceOperationEvent in your event notification query. Instead, you will refer to a class derived from the __ExtrinsicEvent class.

Unlike intrinsic events, extrinsic events must have an associated WMI event provider.

---

 Send us your feedback

« Previous | Next »