The following is information on how to get SCOM (System Center Operations Manager) 2007 to generate alerts based on the windows event log.

  1. The text that appears in the description of windows event log entries is actually made up of a series of parameters. If you want to filter based on content in the Description field, first you need to determine the parameter number that relates to the text you want to find. To find the parameter number, see the following post:

http://blogs.technet.com/stefan_stranger/archive/2008/05/13/opsmgr-2007-parameters-explained.aspx

  1. When using the Windows Event Viewer, it will parse some parameter fields so what you see in the event viewer is not what OperationsManager sees when it reads the event log.

E.g. for security event id 560, under ‘accesses’ field in the description, the windows event viewer could show (amongst other things) WRITE_DAC, but if you try and get Operations Manager to filter against parameter 15 for ‘WRITE_DAC’ it will not work, as that’s not what Operations Manager sees.

To get around this, the following command will create a text file with all events of type 560 that has the content in the same format that Operations Manager sees, if you then search this file for the specific event you are looking at in event viewer, you can match with what SCOM sees and what the event viewer sees to determine what you need to tell Operations Manager to search for:

LogParser.exe -q:ON “SELECT Strings AS Parameters FROM Security WHERE EventID=560” > 560.txt

Using the above you can determine that in SCOM that you need to filter for ‘Parameter 15 contains 1539’. You can also use this to find the parameter number (parameter number can be counted from the left starting from 1, not 0).

  1. PS I haven’t had success in filtering based on the ‘event type’ yet (EventType), including it in the filter stopped scom from picking up the alert.

  2. Create a test rule in the management pack you are creating the event log monitoring rule(s), which is basic search for application log, Source “User Event” and then use the logevent (http://support.microsoft.com/kb/315410) application to create a test event, to confirm that your management pack is actively running on the target device.

e.g.

logevent -s I -e 45 “Test Event”

Logevent download at: http://www.petri.co.il/download_free_reskit_tools.htm

  1. You can also check the ops mgr windows event log to see it has downloaded your changes, but step 4 will tell you for sure. This will also contain information if ops mgr can’t keep up with the event log and is falling behind in monitoring the event log.
  • Monitors are for monitoring for things that affect the health of an object, rules are where monitoring for things that don’t affect object health.

There are 3 types of monitors for the windows event log, manual health reset, automatic after a set time, and automatic after a specific event has been received.

  1. Use trial and error, start with basic filtering criteria, check that receive alerts and make it more specific, at each step checking if you receive an alert, being careful to not create a filter that is so generic that it will result in hundreds of alerts.

  2. To avoid possible performance issues during step 7, test against a single device by disabling your rule and specifically overriding it to enabled for a specific device, and removing the override and re-enabling once you know it is working if so required.

  3. Too many event log monitors could reduce the system wide performance of the monitored device(s).

  4. It is possible to filter based on the entire description field, using a parameter with name EventDescription (howto: http://contoso.se/blog/?p=250), but it is recommended to use parameters instead as searching the entire description will have a greater system wide performance impact on the monitored device(s).