Windows Event Log Monitoring: How To Get The Proper Event Source

First some background information
With SCOM it’s a straight forward process to create new Monitors/Rules which are triggered by certain Windows event log entries. However, you only want to trigger those Monitors/Rules on the correct type of event logged in the Windows event log since every false-positive Alert is one too many, breaking down the overall acceptance of SCOM and playing down the importance of the Alerts shown in the SCOM Console.

No NOISE please!
So the more filtering in that particular Monitor/Rule takes place, the better. This way the false-positives are skipped and only the Alerts which truly matter are triggered.

In the case of the Monitors/Rule which are targeted at a certain event in the Windows Event log you need to add additional filters on top of the most basic one which is the Event ID itself.

These additional filters can be used for instance:

1. Event Source;
2. EventDescription as described by Kevin Holman in this blog posting. Also take notion of his warning using this additional filter, stated in the same posting.

In SCOM these two additional Parameter Names (which are the filters) will be added and configured:

So far so good. But beware. The Parameter Name Event Source can be bit tricky. And when you don’t get it right from the start, NOT a single event will be captured by SCOM. Why? By default all these ‘filters’ (Parameter Names) are ANDed, so ALL of the filters must be met, or SCOM won’t pickup that event:

So when you get the Event Source wrong, not all filters in the AND group are met, thus causing SCOM to skip that particular event you want to be caught by SCOM in the first place…

What proper value to use
So what Value do you have to use for the Parameter Name Event Source in order to make it work as intended?

When you know it (duh!) it’s easy. First I want to show you what value NOT to use for Event Source:

For any given EventID you want SCOM to trigger an Alert or to capture it for Reporting purposes and you use the Event Source as well, you DON’T use the Source of that EventID as depicted in the screen dump shown above.

Even when you select the whole Source (which is in this example  Microsoft Windows security auditing., the dot included) SCOM won’t react at all.

Instead, open the EventID you want SCOM to act on and go to the second tab Details > select the option XML View > in the XML View go to Event > System > Provider Name:

The yellow highlighted entry is required for SCOM, which is in this example Microsoft-Windows-Security-Auditing. In SCOM the Value for Parameter Name Event Description will look like this:

And now we have the proper Event Source for SCOM which enables far more granular monitoring for certain EventIDs in the Windows Event Log.

Recap
When building Monitors/Rules in SCOM which are triggered by certain EventIDs, the more filtering is used the better. However keep Kevin Holman’s remarks in mind and when using the Event Source as one of the filers, make sure you use the proper Value for it. Otherwise that Monitor/Rule will fail to work.