Many customers will want to send specific notifications, raised on specific event IDs to specific groups of people. Unfortunately, in System Center Operations Manager 2007 notifications are based on Alerts, and not on Events. This means that by default, event information is not available for the notifications to be raised on. It is, however, possible to make event data available and to create these notifications based on event details. This document outlines the steps to follow to achieve this.
One such example of a customer request is a customer who wished to alert her first-line help-desk staff when an Account Lockout event was recorded on her Domain Controllers.
The first step was to create an Alert Generating Event rule to monitor for this particular event. (In this case the client didn’t need or want to monitor state, so we created a Rule rather than a monitor).
I targeted the rule at the Windows Domain Controller class, and selected the Security log. The next step was to build the Event Expression. For my needs I simply filtered on Event ID = 644 and Source = Security.
One thing worth highlighting here is that if you wish to filter on the contents of the Event Description it won’t appear in the drop down list of “common event properties”. If you do wish to filter on this, then you can add it as a “parameter name not specified above” its name is EventDescription, with no spaces. (Thanks Emre). Beware of the performance overhead of searching within this field and do consider other ways of achieving the same results if possible.
On the Configure Alerts page, select the Priority and Severity you wish to assign to this alert. This is also the page where we can add our event data to the Alert, so select the Custom alert fields... button.
This allows us to send event details through to the alert so that we can use this information when filtering notifications. The detail I wanted to add was the Event ID, so I added to Custom Field 1, the Event Id by clicking on the Data button shown below.
I also added the EventDescription parameter as Custom Field 2, as it appears that adding the initial custom field changes the description that is displayed in the email. We are adding that description here, so that we can then display that in the end notification.
These instructions presume that the SMTP server has already been setup and that a recipient has already been created, and for this example, his name is Bob.
So I proceeded to create a new notification subscription for the recipient Bob.
I decided not to filter on groups or classes as I had a specific property to filter on and I wanted to keep the filter simple.
On the Alert Criteria page, you can now choose to filter on the severity or priority to match your rule. Notice that here the top severity is Error, which matches the severity defined as Critical in your rule!
I changed the severity to information as it matched my rule, and then simply took the other defaults as they matched with my initial rule.
I then went on to complete the wizard and save the rule. As you will have noticed, nowhere above was I offered the capability of filtering on any other properties. Other properties are not exposed via the UI, but they are available to be filtered on. Alert are saved in the Alert table in the Operations database and you can filter notifications on any of these columns, just not through the UI.
The notification subscriptions are saved in the Notifications Internal Library Management Pack. So the next step was to export that management pack in its XML format. Use the Administration pane in the Ops Manager console to do this.
I then opened this document, Microsoft.SystemCenter.Notifications.Internal.xml, using XML notepad, which can be downloaded from here.
Stored within this document is a list of recipients which can be found by searching for the word recipient.
(the original image can be viewed at http://blogs.technet.com/photos/jchornbe/picture2724481.aspx)
Listed by the recipient Names, are the RecipientIDs. Note the recipient ID for your newly created notification rule.
Further down in the document are the Monitoring – Rules which is where we are going to add the extra filtering criteria. If it is the latest added rule it should appear at the bottom, but to ensure you are dealing with the correct rule you should verify that the recipientID under the Condition Detection node of the rule matches, as below.
(the original image can be viewed at http://blogs.technet.com/photos/jchornbe/picture2724491.aspx)
The bit we are really interested in is the Criteria Expressions under the AlertChangedSubscription node.
(the original image can be viewed at http://blogs.technet.com/photos/jchornbe/picture2724494.aspx)
As you can see there is an expression in there that is checking for Severity = 0.
We can copy this rule, being careful to maintain the Boolean logic of ANDs and Ors, to the appropriate place and edit it to suit our needs.
I selected the SimpleExpression node that filtered on Severity = 0 and copied that as below.
(the original image can be viewed at http://blogs.technet.com/photos/jchornbe/picture2724503.aspx)
All that remained for me to do was to edit the Expression to read CustomField1 equal 664, and I was done.
(the original image can be viewed at http://blogs.technet.com/photos/jchornbe/picture2724500.aspx)
The name of the CustomField1 property is the name of the column in the Alert database. This is the property we populated with the Event ID when creating our original event rule.
At this point you can get as flexible as you like as long as you use the XML query syntax, and the property names from the Alert table.
Once you have made all of the necessary edits then save this file, and re-import it using the Ops Manager console. You will get a warning indicating that a management pack with that name and version already exists, but simply ignore it, go ahead and import and you are done.
Brian McDermott Escalation Engineer