Using Event Description as criteria for a rule


<!--[if lt IE 9]>

<![endif]-->

Comments (23)

  1. Anonymous says:

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

  2. Anonymous says:

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

  3. Anonymous says:

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

  4. Anonymous says:

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

  5. Kevin Holman says:

    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….

  6. Kevin Holman says:

    the problem may be using "contains".

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

  7. mike says:

    When I try this, I get:

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

  8. Stephan Lalonde says:

    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!!!

  9. Will Kaiser says:

    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?

  10. Roger says:

    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 Settingsrcline>"C:Program Files (x86)Log Parser 2.2LogParse

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

    Parameters

    ——————————————————————————–

    ———–

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

    )|912|-|-|-

    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 ?

  11. Andrew Blumhardt says:

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

    $Data/Params/Param[1]$

    $Data/Params/Param[2]$

    $Data/Params/Param[3]$

    $Data/Params/Param[4]$

    $Data/Params/Param[5]$

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

  12. colin says:

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

  13. RonBen says:

    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 ) ) )

    Ron

  14. Craig says:

    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

    %tAccesses:%t%12%n

    %tProperties:%n%t%13%n

    %tAdditional Info:%t%14%n

    %tAdditional Info2:%t%15%n

    %tAccess Mask:%t%16%n

  15. mac3847 says:

    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

  16. Anonymous says:

    I recently had an unpleasant surprise when I realized that I …

  17. sil844 says:

    How to catch the event based on event data because event description is empty?

  18. sil844 says:

    Use ‘EventData/DataItem’ Contains ‘OutOfMemory’ expression helps filter the logs stored in event data.

  19. JTP says:

    If you wanted to use this to catch event ID 1074 – CcmExec.exe triggered restarts… would you just use EventDescription matchesregularexpression CcmExec.exe?
    Is there a better way to just catch this event id when SCCM triggers a reboot?

  20. MattS says:

    Preliminary testing seems to indicate that you can also use WMI to get the parameters of any EXISTING event. The class is Win32_NTLogEvent and the property is InsertionStrings. Using WMI has the benefit of being more readily accessible than LogParser, both for local access and remote event log access
    Here’s an example using Powershell’s Get-WmiObject cmdlet (New PS versions should use Get-CimInstance instead):

    PS > Get-WmiObject -query ‘select * from Win32_NTLogEvent WHERE LogFile = “Windows PowerShell”‘ -ComputerName RemoteSys | Select-Object -First 1 -ExpandProperty InsertionStrings
    Registry
    Started
    ProviderName=Registry
    NewProviderState=Started
    […]
    PS >

    Equivalent in LogParser:
    C:\> LogParser.exe “SELECT Top1 Strings As Parameters FROM ‘Windows Powershell'”
    Registry|Started| ProviderName=Registry
    NewProviderState=Started

    C:\>

    1. MattS says:

      In case it helps anyone…
      After further research, I’ve come up with the following ways to identify Positional Parameters (aka Insertion strings) (excluding the logparser method of course):

      The first two are the best options, but the 3rd (GWMI) could be useful if PS remoting is not setup.

      1) Using the Event Viewer GUI under Details->Friendly View, you can see them under EventData.

      2) Using Powershell’s Get-WinEvent and calling ToXML() on the event objects (Reference: http://www.plattsoft.net/2015/12/03/reading-the-event-log-with-windows-powershell/)
      PS> … | % { ([xml]$_.ToXml()).Event.EventData.Data }

      3) Using Powershell’s Get-WMIOjbect and the Win32_NTEventLog class *
      PS> Get-WmiObject -query ‘select * from Win32_NTLogEvent WHERE LogFile = “Windows PowerShell”‘ -ComputerName RemoteSys | Select-Object -First 1 -ExpandProperty InsertionStrings

      4) Using Powershell’s Get-EventLog (included for thoroughness)
      PS> Get-EventLog -LogName Application | select -first 1 | select -expand ReplacementStrings

      * To use WMI to get insertion strings in the EXTENDED event logs, first you have to add a Key to the registry similar to this example:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Microsoft-Windows-PrintService/Admin.
      Reference: https://kc.mcafee.com/corporate/index?page=content&id=KB81367

  21. mitheun says:

    Hi,
    I was trying to capture all the “errors” send out by a specific source. But it seems the monitor woudn’t report a second error, even if the event id is different because the monitor always works on a (1 or 0) basis. Is there anyway I can use a monitor to capture all the Errors from a source? I understand we can use a rule, but since that does not auto close , it is out of question

    Thanks
    Mitheun

    1. Kevin Holman says:

      Ill be honest – monitors are a TERRIBLE solution for that. Monitors should ONLY be used when:

      1. We need to visually demonstrate health state of an object.
      2. We understand the impact to availability statistics.
      3. We have a solid, reliable way of communicating “good” health returning to the monitor.

      Events in general, are terrible datasources for a monitor, UNLESS all three of the above are met.

      Auto-close is not really important. Notifying you of an problem then getting that data into an incident management system, for assignment, accountability, and tracking is important. Auto-close is a “nice to have” but should only be leveraged when it makes sense, and we still need to track that the problem happened, but resolved itself or was a temporary issue.

      If you have a bad event, and a good event, and this is reliable in behavior – then this would be an option. However, once a monitor goes into a negative health state, it can only generate a new alert on the state change, and it will stay that way until it is told to change back to healthy. In the past, the product groups used things like manual reset, or timer reset, both of which are terrible solutions and do not represent the health state correctly. This is why rules are far preferred. Rules do auto close…. there is a global setting to close rule based alerts after a specific period of time has passed if you just want to clear them out. If you assign a ticket to a person, and they resolve the issue, you can create an automation workflows via Orchestrator to find all alerts with a given name for a given computer, and close those if you desire that functionality.

Skip to main content