Home > SCOM 2012, System Center Family, Tips&Tricks > Making Alert Processing Rules More Useful in SCOM 2012

Making Alert Processing Rules More Useful in SCOM 2012

More often than not, the most useful information in an Event is in its Description. Alert Generating Rules (AGRs) are easy to create but I often find information is not in the most convenient location and a few additional mouse clicks are needed to find it. What can I say, I am lazy.

For example, let’s consider Windows Security event 4740. It is generated whenever a user account is locked out. You can easily create an AGR for event ID 4740 from the Security log. 11
Kinda’ useful except in order to find out What Account was locked out and from which computer it was locked out I need to open the Alert. When viewing Alerts in a NOC or any environment using heads up displays, chances are the view is locked. It would be more efficient if the critical pieces of data were available without any additional mouse-clicks. What you need when you need it.

This is actually very easy to do in Windows Server 2008. The AGR needs to be modified to ‘expose this data in the available Custom Fields. In order to do this, we need to figure out how the data in the Description field maps to the event specific Parameters the AGR uses as criteria. In Windows 2003, it’s a royal pain. You actually need to manually parse the events. If you are working on Windows Server 2003, Check out Kevin Holman’s blog – Using Event Description as Criteria for a Rule

Fortunately, in Windows Server 2008, this is much easier. The ‘Data Name’ fields under ‘Event Data’ in the actual event’s XML view maps directly to the corresponding Parameter number. (Yeah that makes much more sense). Let’s try this. If I open ‘Event Viewer’ and go to the ‘Security’ log and open event ‘4740’, click on the ‘Details’ tab and select ‘XML View’, I will see something similar to this: 21
So the first entry under ‘Event Data’ is Parameter 1. The second entry is ‘Parameter 2’ and so on.
Data Name Parameter
TargetUserName ” > pchomak
TargetDomainName ” > O
TargetSid ” > S-1-5-21-1115392254-4180257764-468871738-1601
SubjectUserSid ” > S-1-5-18
SubjectUserName ” > O$
SubjectDomainName ” > MOBIEUSSYSTEMS
SubjectLogonId ” > 0x3e7
We are interested in what account was locked out (Parameter 1) and from which computer it was locked out from (Parameter 5) so now all that is left to be done is to configure the AGR to insert this data into one of the twelve available custom fields.

We will need to edit the appropriate AGR so go to the ‘Configuration’ tab. Under ‘Responses’ click ‘Edit’:
Now click ‘Custom Alert Fields’:
Enter the following variables:
n case image is distored, the variable is $Data/Params/Param[n]$ where n is the corresponding Parameter value.

So now the locked out account will appear in Custom Field 1, the computer from where the account was locked out in Custom Field 2 and the domain the account belongs to in Custom Field 3.

So far we just discussed how to expose some additional information from the Description field. What about using that information as criteria to generate the Alert in the first place? Simple. When constructing your Data Source Expression, simply add Parameter in the correct number:
Now the Alert will only be generated if this particular user account gets locked out. Surgical not broad. The techniques described here can be used in a boat load of situations, not just security events.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: