Operations Manager Management Pack Authoring - Events

Operations Manager Management Pack Authoring - Events

This document is part of the Operations Manager Management Pack Authoring Guide.  The Microsoft System Center team has validated this procedure as of Revision #2.  We will continue to review any changes and periodically provide validations on later revisions as they are made.  Please feel free to make any corrections or additions to this procedure that you think would assist other users.

The following table lists the kinds of events that can be used for monitors and rules in an Operations Manager management pack:

Text Log Text log file that has a single line per entry.
Text Log (Delimited) Text log file that has a single line per entry and fields separated by a specific character.
Windows Events Events in the Windows event log matching specified criteria.
WMI Events Events created by Windows Management Instrumentation (WMI).
Syslog Events Events from Unix systems and other devices.

Details on each event data source are provided in the following sections. This includes the information that is required to retrieve the required data, properties available in the resulting data, and what workflows the event data source supports.

Windows Events

Many Windows-based applications post information to events in a Windows event log. These events follow a standard format and frequently contain detailed information about the particular issue


In addition to the Application log to retrieve events from, workflows using a Windows event must specify sufficient criteria to identify the particular events that relate to the issue being identified. Frequently, the Event ID and the Event Source will be sufficient for this purpose. This depends on the kind of information that the application provides in the particular event in addition to the target that is being used for the monitor. If the class being used as the target for the monitor is expected to have multiple instances on a particular agent, then these two properties are probably insufficient for uniqueness. Unless the criteria included a key property for the target class then the criteria would possibly apply to all instances.

For example, the Microsoft Windows DNS 2008/R2 Server management pack uses an event to detect an error in a zone transfer. This event will have a publisher name of Microsoft-Windows-DNS-Server-Service and an event number of 6002. This monitor is called Microsoft.Windows.DNSServer.2008.Monitor.ZoneTransfer.ReinitializeZoneTransfer and uses the Microsoft.Windows.DNSServer.2008.Zone class for a target. This class is expected to have multiple instances on a particular agent. If multiple zones were hosted on a single DNS server, and only the publisher name and event number were used then the single event would be recognized by each instance. Each instance would set a negative health state even though the event was intended for only one zone. In this case, the name of the zone experiencing the issue is provided in parameter 2 of the event. Criteria is added to the monitor to match the name of the zone with the value in this event parameter to ensure that the criteria for each event matches only one instance of the Microsoft.Windows.DNSServer.2008.Zone class.


The following table lists the properties available from Windows Events. These properties can be accessed for setting criteria in monitors and rules and can be included in alert descriptions.

Property Name Description
PublisherName Source of the event. Generally used in the criteria of the monitor or rule.
Channel Name of the event log such as Application or System.
LoggingComputer Name of the computer logging the event.
EventNumber Number of the event.
EventCategory Category of the event.
EventLevel Severity of the event that uses one of the following values.
  • 0 - Success
  • 1 - Error
  • 2 - Warning
  • 4 - Information
UserName Name of the user account that was used to create the event.
EventDescription Full event description.
Params Collection of event parameters.

Workflows Supported

Windows Events can be used in the following kinds of workflows:

  • Monitors
  • Alerting Rules
  • Collection Rules

Text Logs

A text log is a text file that an application uses to log event information. In order to use a text log data source in a management pack, each entry in the log must be on a single line. If the log file does not fit this requirement, then a custom script has to be created to read the log. Using a standard text log, the monitor reads the whole line as a single entry. With a delimited text log, a delimiter is used to separate the fields in the entry.

Applications that use log files frequently create a new file each day or when one file reaches a certain size. To support this functionality, monitors and rules specify a Directory and a Pattern for the text logs being monitored. Directory is the path of the directory where the text logs will be located. This must be an absolute path without wildcard characters. A $Target variable could also be used if the path to the log files is stored in a property of the target class. Pattern is the name of the log file including wildcard characters as appropriate.

For example, an application might create a log file each day with the date included in the name as in log20100316.txt. A pattern for such a log might be log*.txt which would apply to any log file following the application’s naming scheme.


The expression for a text log monitor will include criteria that matches text in the log entry. For a standard text log this includes a search of the whole log entry treated as a single line. For a delimited text file, this will include a search of one or more of the included fields. The contents of a text log are included in the parameters of the event. For a standard text file, this is referenced by the parameter $Data/Params/Param[1]$. A delimited text file uses the same $Data variable by using the index number of the required parameter. The first field would be referenced with $Data/Params/Param[1]$, the second field would be referenced with $Data/Params/Param[2]$, and so on.

The following table lists the common properties available from text log monitors and rules:

Property Name Description
LogFileDirectory Directory that the log file is located in.
LogFileType CSV Log File Format for a delimited text log.
Generic Log File Format for text log.
LogFileName Name of the log file that the event was taken from.
Param[1] Complete entry in a standard text file.
Param[#] Specific parameter in a delimited text file. # represents the number of the field.

Workflows Supported

Text Logs can be used in the following kinds of workflows:

  • Monitors
  • Alerting Rules
  • Collection Rules

WMI Events

WMI events are created from WMI queries that detect particular actions in the operating system or in applications that create their own WMI events. These events can be used to detect such actions as a process ending, a file being created, or a registry key being modified. WMI events are not persisted. Therefore, any WMI events that are created when the agent service is not running are lost.

This guide assumes knowledge of how to build a WMI notification query. For a an overview of this topic and sample queries see Unlocking the Mystery of WMI Events in MOM.

WMI monitors and rules require a namespace, a query, and a poll interval. The poll interval specified in the monitor or rule should match the poll interval in the query.


Because criteria can be specified in the WHERE clause of the WMI query, criteria is frequently not required in the monitor or rule. It is only required if the query is expected to return multiple records.

The Authoring Console wizards require that criteria be specified in WMI Event monitors and rules. If no criteria is required, then dummy criteria should be specified in the wizard and then removed by viewing the properties of the monitor or rule.



Workflows Supported

WMI events can be used in the following kinds of workflows:

  • Monitors
  • Alerting Rules
  • Collection Rules

Syslog Events

Syslog events can be used to collect messages from Unix systems and other devices. Syslog rules can be run on an agent that is the receiver of messages from one or more devices. When the rule is run, the agent will listen for messages on UDP port 514. This is the only port that can be used.


The Syslog data properties are shown in the following table:

Property Name Description
Facility The facility of the event that uses one of the values from the table that follows.
Severity Numeric value that indicates the severity of the event using one of the following values:
  • 0 - Emergency
  • 1 - Alert
  • 2 - Critical
  • 3 - Error
  • 4 - Warning
  • 5 - Notice
  • 6 - Info
  • 7 - Debug
TimeStamp Time that the message was sent.
HostName Name of the device sending the message
Message Text of the message

Facility Values

The value for the facility property defines the part of the system that the message originated from. It will have one of the values from the following table:

Facility Description Value
0 Kernel Kernel messages
1 User User-level messages
2 Mail Mail System
3 Daemons System daemons
4 Auth Security and authorization
5 Syslog Syslog internal messages
6 LPR Line printer subsystem
7 News Network news
8 UUCP Unix-to-Unix copy program
9 Crom Cron daemon
10 Auth2 Security and authorization
11 FTP FTP daemon
12 NTP Network time subsystem
13 LogAudit Log Audit
14 LogAlert Log Alert
15 Cron2 Cron daemon
16 Local0 Local use 0
17 Local1 Local use 1
18 Local2 Local use 2
19 Local3 Local use 3
20 Local4 Local use 4
21 Local5 Local use 5
22 Local6 Local use 6
23 Local7 Local use 7

Workflows Supported

Syslog events can be used in the following kinds of workflows:

  • Alert Rules
  • Collection Rules
Leave a Comment
  • Please add 4 and 1 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
  • Richard Mueller edited Revision 2. Comment: Fixed duplicate <a name> tags in HTML so TOC works properly, added tags

Page 1 of 1 (1 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
  • Richard Mueller edited Revision 2. Comment: Fixed duplicate <a name> tags in HTML so TOC works properly, added tags

Page 1 of 1 (1 items)