This is an old subject and EVERYBODY should know how to create an Alerting rule that detects a certain event and triggers and alert. However, the way things are laid out in SCOM can make your daily life difficult. Just run in to an issue yesterday that was giving me (more) gray hair.
The requirement was simple: detect abnormal BSOD or power related shutdowns. Easy as pie, right?
The events are fairly easy to pinpoint. Say, for example, event ID 1001:
Cool. All you have to do is create an Alerting rule in SCOM, with this criteria:
Event ID: 1001
Here’s what I’ve experienced. When testing the rule, I run a simple PowerShell command to create a fake event:
Write-EventLog –LogName System –Source “BugCheck” –EntryType Error –EventID 1001 –Message “This is a test message.”
Event is pretty similar:
That should have triggered my alerts. It didn’t however. Since I have ‘faked’ the event, the message shows me a bit more than just ‘This is a test message.’:
Now, notice this:
Why does it say the source is Microsoft-Windows-WER-SystemErrorReporting when the source is supposed to be “BugCheck”?
So, I’ve decided to change the rule to:
Bingo! Now, the alert was generated correctly. In summary, the source you see in the event log is what SCOM sees when detecting the event. The same applies for Kernel-Power, for example:
Now the reason for that is in the details of the event:
In fact, the EventSourceName is ‘BugCheck’. The Provider Name is considered the souce by SCOM, as you can see above and below:
The way to fix it, if you want to use the EvenSourceName is to use a custom field. Notice SCOM doesn’t provide a native ‘EventSourceName’ option:
You can then use:
And there you have it!
Hope this helps!