OpsMgr R2, Notifications – The Basics

Don’t know yet whether this will become a series. But there is much to tell. Many questions do exist about this topic. With R2 much has changed. To my personal opinion, these changes are very positive. Some things which were much used in RTM/SP1 have been dropped or changed in R2, like the Categories Filter. It is still present but not any more in the GUI. But the trade off is still a very good one: the Notification model in R2 has been improved hugely.

Why?

1. Decreased Overhead
   An OpsMgr Operator can now manage his/her own subscriptions as needed, without needing the help of an OpsMgr Administrator.
   
   
2. One-Click-Subscriptions
   When an Alert turns up in the Console which the Operator deems important enough to be sent out as a Notification, a subscription is easily created, again without the help of an OpsMgr Administrator.
   
   
3. Flexibility
   I have seen in many fairly big sized companies where OpsMgr RTM/SP1 was being used that the OpsMgr Administrators were overwhelmed by all the requests from the operators to adjust the subscriptions because of illness, days off, holidays, changes in night- and weekend shifts and so on. Made them feel like running an old fashioned telephone exchange.
    
   Now all this has gone and the operators can change the subscriptions as needed, all by themselves. Also, when it goes wrong, they have only themselves to blame, not the OpsMgr Administrators any more… :)

So how to go about it? How to use the new Notification model to its best? That’s hard to tell actually since every company uses OpsMgr in different ways. What I will try however it to share some insights and experiences from the field.

First lets start with some terminology:

• Channel:
  The delivery mechanism used for sending out an Alert. This can be e-mail, sms, instant message and command. The latter can be used to specify a path to a script or application. It is also used to connect to a delivery mechanism which is not directly supported by OpsMgr, like a pager.
  
  
• Notification Subscriber:
  Definition about when (schedule) and from what devices (channels) notifications will be sent.
  
  
• Subscriber:
  The user who receives the notification.
  
  
• Subscription:
  Here a subscriber can decide what type of Alerts to receive, based on criteria like the severity, priority, groups, classes, rules and monitors. And that is just a few of the criteria available. Also the channel can be chosen here and it can be turned on or off. All this can be done by the operator!

The Channels can only be created by the OpsMgr Administrators. Having said that, when a Channel is in place, an Operator can make a copy of it for his/her own subscriptions. In this copy the Operator can change the format of the notification. Some people like to receive a short message, where others like to receive a whole book :).

My two cents here: As an OpsMgr Administrator, create the needed Channels. Train & instruct the Operators in how to make copies BUT make some good agreements about how many. This way it will keep the Console neatly organized without having too many copies of the Channels. A thing to reckon with is that the copies of a Channel are connected to each other. Suppose, you change the SMTP server for an e-mail Channel, this will change the SMTP servers for the copies as well. Vice versa the same thing happens. Also the original Channel can not be deleted as long there are copies of it.

The rest (Subscriber & Subscription) is to be set/managed by the Operators themselves. Of course, as an OpsMgr Administrator you can setup the most common Notification scenario’s like the Notifications for the SQL department, Server OS department and the Exchange department for instance.

But be wise and leave the nitty gritty details to the Operators themselves. It will get them more involved into using OpsMgr as a whole which is a welcome side-effect as well. Of course, instruction/training is needed. Test it out and be surprised about the flexibility of the Notification Model in OpsMgr R2.

A last piece of advise: OpsMgr uses AD. So when a user account has been set properly and the e-mail address has been included in the properties of the account, OpsMgr picks it up.

I do realize there is much more to tell about Notifications in OpsMgr R2. This posting just touched the outside of it all without going deep. All I can say, test-drive it in order to get familiarized with it. The time spent is worth it, since a lean and mean Notification Model certainly pays off.