Scoping Notifications, Alerts and Views

Suppose one has a group of certain servers which run processes/services for which two different IT departments are responsible. These IT departments do not want to see the Alerts of the other department, nor do they want to get notifications of each other. Yet, they monitor the same servers...

Also they do not want Alerts related to hardware or system outages. To make it a bit more complicated, since they are in a migrationprocess, these requirements will change in the near future and will be mixed as well.

Also they monitor processes/services on these servers for which no ready made MPs are available. So for each of these aspects new rules/monitors have to be built.

How to go about it?

How does one scope it in such a way that all these requirements are met AND that it is easily managed within SCOM without building a solution that does the job but is a nightmare to maintain?

A blogposting (section: ‘Using Alert Priority as a notification filter strategy’) of Kevin Holman gave me the direction how to go about it.

First I asked myself the question: Which IT department is going to get the most rules/monitors?

This is a very important question since it will save the customer (and me) a lot off work to be done in the end, applying the needed overrides.

Then I decided what scoping to use. Of course, all the Alerts generated by the rules/monitors (yet to be built) will have the Severity Critical. But for one department the Priority will be set to High (integer 2), for the other department the Priority will be set to Low (integer 0).

Then I looked into the needed rules/monitors and how to make them work. I am a strong believer in the credo KISS: Keep It Simple Stupid. This credo doesn’t come from me but from Kelly Johnson.

The simpler a rule/monitor is, the better it works and the longer it will be used.

For the department which got the most rules/monitors I decided they would get the Priority High and the same way would the rules/monitors be set as well.

With all this information I started to built the needed rules/monitors, Views and Notification Models. Of course, all rules/monitors are disabled by default. All rules/monitors are targeted at the Windows Server 2003 Computer object.

Besides that I built a group containing all the servers to be monitored by these departments.

For one department I scoped the View to show only the Alerts <> 255 Resolution State, Priority High scoped to the new group. The other department got a new View with <> 255 Resolution State, Priority Low also scoped to the same group.

For the Notificationmodel I used the same method. One department would be notified for Critical High Alerts, the other department would receive notifications which are Critical Low Alerts for the new group.

Then I started to ‘fire-up’ the rules/monitors by using overrides. For most overrides I used the newly made group. Depending on the department I changed the Priority setting as needed.

In other situations I made an override based on a single server and changed the Priority level as needed.

Fieldtested it and it works like a charm. The Views, the Alerts and Notifications do not only get filled/out properly, but also to the destination where they are supposed to go to.

And the third department (Hardware) get’s a notification when these servers go down since they have a Notificationmodel scoped on Agent Health Service and Health Service Watcher for these servers.

Phew!

And yes, everything has been neatly documented.