First time administrators of Operations Manager (OpsMgr) are often uncertain of how notifications work . In this blog post, I will explain how they work, provide a few tips for using them effectively, and provide some references for further reading and advanced notifications scenarios.

Three Parts of a Notification

In the Administrator Console, under Administration and Notifications, three folders are available: channels, subscribers, and subscriptions. Together, these are components are used to create notifications.

Think about these components as…

Channels– how the notification will be sent and what it will look like

Subscribers– who will get the notification and when they will receive it

Subscriptions– which alerts will be sent

Simple enough, or so it seems…

Don’t create an “All Alerts, All the time to Everyone” subscription… unless you mean it!

One of the least useful ways to leverage notifications is to create a single subscription for all alerts. That is, all alerts raised by all agents, regardless of severity, sent to one or more persons. That’s usually not very effective for a few reasons:

• You don’t need a very large environment before the number of alerts generated daily will dwarf the capacity for anyone to process.
• You end up treating every alert as equal in priority, regardless of the source (e.g., a tier-1 DB versus any random services on any server).

Some exceptions do exist when this is useful, however. For example, some customers would send the alerts to a folder or mailbox automatically monitored by a helpdesk/service desk software. The service desk software would pick up the new emails and generate service desk tickets and/or incidents based on those alerts.

If you are still working this way today, look at Systems Center Orchestrator for automating and maintaining the OpsMgr alerts lifecycle within your helpdesk/service desk.

Using Subscriptions

Instead of creating an “all alerts, all the time to everyone” subscription, use the flexibility of the components that make up a notification (channels, subscribers, and subscriptions) to create notifications that will route the right alerts to the right people, at the right time. Below are a few pointers with using those components:

Channels

Many OpsMgr administrators who only use SMTP channels (i.e., emails) may miss out on the fact that through the same delivery method (for example, Exchange), you can create two versions of the same notification, but with a different consumption device in mind. For example, for alerts on a smartphone, you may want less information than the same alerts being read through a full email client such as Outlook.

On the Format window of the channel, you can modify the subject and message.  Below shows the default content:

As shown below, you may add the text <Short> in the subject line (presumably to indicate a message format for smartphones) and remove a number of parameters from the message body to only send the essential information, which will be easier to read on a small screen.

Another use for multiple channels is to generate various email subjects for easier filtering. An example would be to prepend <ACTION REQUIRED> to specifically critical alerts (for example, alerts related to certain LOB components).

Subscribers

Subscribers allow you to specify when to send notifications in addition to whom to send them to. In conjunction with the multiple channels options discussed earlier, you could have alternative formats sent to the same person depending on the time of day.

As an example, you could receive verbose critical alerts between 8 am and 6 pm, when you’re expecting to consume the alerts through your Outlook client, but receive shorten messages on your Windows Phone after business hours.

Try to leverage distribution lists for subscribers, even with few recipients. They offload the management of subscribers outside of OpsMgr and allow you to easily add or remove individuals as needed such as when an administrator goes on vacation or if you have an after-hours support rotation.

Subscriptions

So far it’s been pretty easy: channels and subscribers are straight forward to understand. Subscriptions however, are more complicated. That’s because they provide the flexibility of sending alerts from a combination of criteria such as which class or group raised the alert, the severity and priority rating, and also custom fields.

Don’t go overboard with subscriptions, especially with subscriptions that are filtered out to a single rule or monitor. Things can get out of hand quickly here.

Remember that much like actionable alerts in the console, you want the notifications that are being sent to also be actionable. Some planning should go into building notifications in order to get the most out of them.

Subscriptions have an option for “Alert aging” (see below), which tells OpsMgr to hold off sending the notification until a set number of minutes have passed and if the conditions remain unchanged. This is very useful to create an escalation notification. In the screenshot below, a delay of 25 minutes has been set. This would be used for example, to ensure that if after 25 minutes if an alert hasn’t been addressed (acknowledged/closed/etc.), then an alert would be sent to a second subscriber, such as a team lead or escalation team.

A few nifty tricks and other resources

• Kevin Holman has a few interesting posts on advanced notifications:
• Using OpsMgr notifications, and
• Creating granular alert notifications, which describes how to make changes to the criteria logic directly from the xml file (i.e., the MP that contains the notifications).
• Steve Rachui has one that’s a bit outside the box: using PowerShell to modify alerts through a subscription.
• Stefan Stranger has a blog post on pushing notifications to your Windows Phone.

Final Thoughts

So there you have it. There’s no need to limit notifications to one for all. Through the careful planning of channels, subscribers, and subscriptions, you’ll avoid subscriptions becoming a spam engine and instead be useful for the recipients.

Comments welcome.