So.... Say I am an Exchange Administrator in a global company.... in the good old USA.
My company has recently implemented OpsMgr 2007 to monitor our Exchange servers. I am going to configure my notification subscriptions so I can get an email anytime one of my Exchange servers has an issue.
Try #1: I start by creating a notification subscription, and I dont scope it by groups or classes (all groups, all classes). I think this sounds fine. However, instantly I find I am flooded with email notifications from every single alert coming into the console. This is NOT good!
Try #2: Therefore – I decide I really need to see only Exchange alerts. I scope the notification *classes* down to just Exchange classes. This will ensure I only receive notifications from Exchange target classes. Good? Nope.... I soon find that when an alert comes in from the base OS, or heartbeat, or hardware, we won’t get those. We need to add those classes back. If we add the heartbeat (Health Service Watcher) class – we will now get heartbeat failures for ALL machines… not just restricted to exchange servers. No good.
Try #3: So – we need to scope the subscription using groups. We create a group with all our Exchange Server Windows Computer objects in it. We can manually add these in (Explicit) or we can use a dynamic rule based on criteria - I chose NetBIOS name, and used a naming standard of EX* (all my exchange servers start with "ex"). I used an "OR" statement since the wildcard is case sensitive.
Now I create a subscriptions - and scope it to this group - and choose ALL classes.... thinking that this way, we should get ALL notifications, including base OS, exchange, and heartbeat alerts… right?
Nope. Because of the object oriented monitoring model – we will only receive alerts from a rule/monitor with a target class that has a child relationship to the Windows Computer class. This is the only class type in the group we created. So – using the model in #3, we will get notifications from pretty much any class needed – except heartbeats. These come from the Health Service Watcher class, and have no relation to the Windows Computer class.
Try #4: I am thinking, we must add the class type to our group – and any instances of that class we are interested in. Since most object classes are a child of Windows Computer, there should not be many of these that we will have to do.
In the group – add the Health Service Watcher display name instances, in the same way we add the Windows Computer NetBIOS names:
The AND/OR verbiage is misleading…. This was opened as a bug then closed – because it is “as designed”.
Essentially – The or group at the top will include ANY of the following and groups below it…. BOTH the windows computer objects AND the Health Service Watcher objects are included: (you can right click any group and choose to show members)
I tested all kinds of Exchange alerts, and heartbeat failures – and this works. It is possible there will be other alerts we wont get in this subscription.... IF the rule or monitor that created the alert was using a target class that was unique, and not a child of "Windows Computer"
I don’t think this will be a huge hassle moving forward… because MOST alerting is done on a target which is a child of Windows computer. If we find one that is not – we just need to go back and add that class’s instances to the groups we create for notifications.
Want alert by alert notifications? Where you can subscribe to a single alert, rule by rule, monitor by monitor? Check out: