Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

Using Event Description as criteria for a rule

Using Event Description as criteria for a rule

  • Comments 19
  • Likes

When we write rules and monitors to look at events in the event log.... typically the most common criteria are Event ID and Source.  We also have a list of other common event properties to choose from:


However, this list doesn't always work.  For instance - if we add someone to a Global Group in AD.... this might create a Event ID 632 in the security event log on a DC - but possibly we only want to alert on this when the group being modified is "Domain Admins".  Somewhere in that event description is the word "Domain Admins". 

So - the BEST solution.... is to figure out "which parameter" the Domain Admins falls into.  To figure out which parameter is which value isn't always simple.  Here is a resource for security events:

Windows 2000 Security Event Descriptions (Part 1 of 2)  and Windows 2000 Security Event Descriptions (Part 2 of 2)

What we can see here is that for event ID 632 - the value of "Domain Admins" will be placed as "Target Account Name" which from the links above... is Parameter 3.  Therefore - we could make our rule look like so:


Now.... this works great.... but what if we don't *know* which parameter is which value?  See below for some cool tools on finding even parameters.


One option is to use something like "anywhere in the event description, contains specific text".  The problem is - we don't let you pick "Event Description" in the most common event fields... for GOOD reason.

Before we continue - let me STRESS that using event parameters is the correct way to match on specific lines in an event description wherever possible.  If we try and search the entire event description, there is a substantial cost to doing this... from an agent design/performance perspective.... as matching on parameter is the lowest impact.  If you match on an event description - this description is localized text and wont work in all locales.  By writing a rule that matches on event description.... if you didn't specify several other criteria... there is a risk that every single event description would be searched, across all agents.  Very bad.  So keep this in mind.... if you decide to use this.

Ok - warnings aside:  Here is how you can use that:

Instead of using a common field, or a parameter - type in a "Parameter name not specified above".  At some point, we should document what all is available here.


Your new rule should look like this:



Now.... back to the "right" way to do this.... using event parameters. 


Stefan has posted about a tool which allows you to determine the event parameter number and value for just about any event log event, and even XML and CSV files, using LogParser:

Check it out and make MUCH better rules!  Thanks Stefan!

Get it here:

Here is an example event that I want to match on:

Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 636
Date:  6/9/2008
Time:  7:46:34 AM
User:  OPSMGR\kevinhol
Computer: OMTERM
Security Enabled Local Group Member Added:
  Member Name: -
  Member ID: OPSMGR\test
  Target Account Name: Administrators
  Target Domain: Builtin
  Target Account ID: BUILTIN\Administrators
  Caller User Name: kevinhol
  Caller Domain: OPSMGR
  Caller Logon ID: (0x0,0x16C2B850)
  Privileges: -

Here is an example command line using LogParser:

C:\Program Files\Log Parser 2.2>Logparser.exe "select top 1 Strings AS Parameters FROM security where EventID=636"

Here is the output:



We can gather a few things from this.  Parameters will be delimited by a "|" symbol.  The first parameter in this example is "-".  We can also gather that this tool does not resolve GUID's properly, by looking at the second parameter, which is actually.  The the "Member ID" value of "OPSMGR\test" which is a domain user account.  Lastly - the 3rd parameter, which is what I am looking to match on, is "Administrators". 

Even if the tool does not resolve GUID's, that is of little concern, and the point of using the tool is to determine the parameter values in the first place.


Using LogParser with an exported EVT file:

I want to add another example.... lets say you have an exported log in EVT format - and want to search that log in LogParser:

Logparser.exe -i:EVT "select top 1 Strings AS Parameters FROM 'C:\Temp\exportedlog.evt' where EventID=2115"

This will parse a saved EVT export of any log that was copied to C:\Temp


NOTE on Server 2008:

I got notified recently that LogParser threw an error when trying to find event parameters in the Security event log on Windows 2008 Server.  As usual – this was caused by UAC getting in the way.  Make sure you right click LogParser shortcut and run “As an Administrator” in order to make this work – otherwise it will throw a Syntax error about Strings and TEXTLINE.  If you run this “As an Administrator” it worked just fine on 2008 server…. even on x64 version.


Also check out the MOM 2005 Wizard post I wrote – another way to look at events, find parameters, and find all possible events for a known event source:

  • When I try this, I get:

    Alert description: {0} {1} {2} {3} {4}

  • This came up in a discussion group.... and while it maybe not be all that interesting of a topic....

  • This does not work.  It fails to filter out the correct information and when you specify these parameters as part of the alert description to see which one is which, you get {0} {1} {2} {3} {4} etc...  As previously stated!!!

  • Just to elaborate, the above posts are ultimately correct.

    The log parser does indeed give you parameter numbers for an event log, and you can indeed build a rule based on that which will fire off appropriately.

    The problem is that when you use parameters you apparently cannot pull other data from the event log into the alert description.

    So in my case, I'm looking for 'logon type: 10' in a particular security event log.  I used the log parser to discover that '10' is parameter 4.  I built my rule to watch for parameter 4 is equal to 10.  It works, an alert is generated when that specific log is created, HOWEVER, when I attempt to display information from that event log in the alert description, the values are '{1} {2}' etc instead of the actual data from the alert, which renders this approach worthless.

    Note that I have roughly 40 other rules that watch security event logs like this, and I have created a template that I paste into the body of alert that provides the alert description as well as the alerting source in a readable fashion.  That template works with all other event log based rules and passes the event description into alert body successfully.  Using the above approach, I now only get '{1} {2} {3}...'.

    Any thoughts on this?  Is there a way to translate the {1} values into actual data from the event?

  • I dont know what to say - it works fine for me.

    I would start by testing this - dont paste in anything - just use the flyouts... and add JUST PARAMETER 1.... using the UI controls.  Start with a blank alert description, click the ellipsis, click data, specify parameter 1 only, click ok.  

    Then - give that enough time to propogate down to the agent - then test the event...  then go back and add in all the appropriate parameters.  It works fine for me... I did get it to mess up once, but now I cannot repro it. It might have something about the alert description not liking a pasted in text dump from html... or the spaces, or the <BR /> in some combination.  I cannot repro it not working, however....

  • So…. with the introduction of Server 2008 into OpsMgr… as a monitored agent, you might need to re-evaluate

  • Using System Center Operations Manager 2007, you want to get an alert for any change in the domain admin

  • I am having trouble triggering on the User Name for 531 or 539 security events. The unit monitor works fine if I don't specify an AND User Name condition.

    Here is my log parse output

    C:\Documents and Settings\rcline>"C:\Program Files (x86)\Log Parser 2.2\LogParse

    r.exe" "select top 1 Strings AS Parameters FROM security where EventID=531"




    scomsql|ACEINA|4|Advapi  |Negotiate|USSBYSCOM302|USSBYSCOM302$|ACEINA|(0x0,0x3E7


    Here is my unit monitor Event Expression

    ( ( Parameter 1 Contains scomsql ) AND ( ( Event ID Equals 539 ) OR ( Event ID Equals 531 ) ) )

    What am I missing here ?

  • I'm currently using a dummy rule to expose the parameter information for a given event using SCOM alert description criteria. For example:






    Now I just have to wait for my target alert to trigger to determine the parameters I need. Hope this helps. Thanks, Andrew

  • I require all event parameters stored into the datawarehouse.  How to achieve this?

  • I have this working if I'm only searching for 1 value in Param 1. The below query does not work. Is there something I'm missing?

    ( ( Event ID Equals 644 ) AND ( Event Source Equals Security ) AND ( ( Parameter 1 Contains scomusr ) OR ( Parameter 1 Contains tonyh99 ) ) )


  • the problem may be using "contains".

    Have you tried using a "matches wildcard" or "matches regular expression" ?

  • I actually use generic a unit monitor when developing a new rule or monitor to get identify which params contain which details.

    $Data/Context/EventDescription$ shows the actual with full parameter values.

    $Data/Context/RawDescription$ shows the event template without specific parameters.

    This is the Raw for a 566 event. You can pick the param numbers from the end of each line in between percent signs %##%

    Object Operation:%n

    %tObject Server:%t%1%n

    %tOperation Type:%t%2%n

    %tObject Type:%t%3%n

    %tObject Name:%t%4%n

    %tHandle ID:%t%5%n

    %tPrimary User Name:%t%6%n

    %tPrimary Domain:%t%7%n

    %tPrimary Logon ID:%t%8%n

    %tClient User Name:%t%9%n

    %tClient Domain:%t%10%n

    %tClient Logon ID:%t%11%n



    %tAdditional Info:%t%14%n

    %tAdditional Info2:%t%15%n

    %tAccess Mask:%t%16%n

  • I'll have to try this out one day..

  • Hi, I have used this blog to create rules for users being added to specific AD groups. However today i was asked to create a rule for to alert when a specific user is added to any AD group. Is this possible? If so could someone please help? Disconnected at work so need to check at home then test at work. Thanks in advance

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs