Menu Close

OpsMgr 2012: Configure notifications

Setting up notifications for email, IM, or command channels is almost identical to how this was configured in OpsMgr 2007 R2.  This article will just serve as a walk through to the process, such as immediately after deploying OpsMgr 2012.  The key difference here is that Notifications are now managed by a Resource Pool, instead of just depending on the RMS.

 

Notifications in OpsMgr are made of of three primary components – the Channel, Subscriber, and the Subscription.  The Channel is the mechanism that we want to notify by, such as Email.  The subscriber is the person or distribution list we want to send to, and the subscription is a definition of criteria around what should be sent.

 

The SMTP Channel:

 

We will first need to create the channel:  Under Administration pane > Notifications > Channels.  Right click and choose New channel > Email (SMTP)

image

 

Give your channel a name.  We might have multiple email channels.  Once for emails to our primary work mailboxes.  Maybe another with different formatting for sending email to cell phones and pager devices.  Lets just call this one our “Default SMTP Channel”

image

 

Click Add, and type in the FQDN of your SMTP server(s).  This can be an actual SMTP enabled mail server, or a load balanced virtual name.

I am going to select “Windows Integrated” for my Authentication mechanism, since my mail server does not allow Anonymous connections.

image

 

For the Return Address – I have created an actual mail enabled user to send Email notifications through SCOM.  This might not be a requirement to be a real mail address – mostly that depends on your mail server security policies.

image

 

Next up is the email format.  We can customize this with very specific information that is relevant to how we want emails to look from SCOM.  I will just accept the defaults for now.  I can always come back and customize this one, or create additional channels with different formats later.

 

 

The Subscriber:

Next up – creating the subscriber.  Right Click “Subscribers” and choose “New Subscriber”

This will default to show your domain account.  You can change this to whatever you like:

image

Next – we need to choose when Kevin wants to receive email notifications.  This is especially important for things like on call pager devices, or when people work shifts and only want to see emails during certain times.

Next – we need to add an email address to the subscriber.  I will add my default work email:

image

Then select the Channel type, and the email address:

image

 

Additionally – you can configure a specific schedule for this specific address.  The previous schedule was for the subscriber itself, but a subscriber can have multiple addresses with different schedules if needed.  I will keep things simple and choose “Always send”.   Click Finish a couple times and your subscriber is set up.

 

The Subscription:

 

Now we create a new subscription – Right Click “Subscriptions” and choose New Subscription.

Give your subscription a descriptive name that describes what it is and who it is to.  Like – “Messaging team – all critical email alerts”  Here is mine:

image

 

On the criteria screen – we have some very granular capabilities to scope this subscription.  My goal for this simple one is just to send me any new critical alert that comes into my environment:

 

image

 

Next we add the subscribers to the subscription:

 

image

 

We also need to choose which Channel we want to use for this subscription:

 

image

 

On this same screen – there is an option for delay aging:

image

 

What that does – is allow for you to have multiple alert subscriptions – and using delay – create an escalation path if an alert is not modified in a way that takes it out of the notification path for these subscriptions.

Click “Finish” and we are all set.  Behind the scenes – what happened is that all this information was actually written to a special management pack – the Microsoft.SystemCenter.Notifications.Internal MP.

Let’s test our work.

 

I have a test rule that generates a critical alert whenever a specific event is written to the event log.  Since I subscribed to all critical alerts – this should trigger my subscription and deliver an email:

 

It worked!

image

 

 

Advanced configuration – setting up a Run As Account to authenticate to the SMTP server:

 

Note – there is a Run-As Profile that ships with SCOM called the “Notification Account”.  If this is not configured, SCOM will try to authenticate to the Exchange server using the Management Server Action Account.  If this is not allowed to authenticate, you might need to configure this Run-As profile with a Run As Account.

For instance – I disabled the ability for mail relay on my Exchange server.  When I do this – only mail enabled Exchange servers can connect to it.  Subsequent notifications fail to go through – and I will see two possible alerts in the console:

Failed to send notification

Notification subsystem failed to send notification over ‘Smtp’ protocol to ‘kevinhol@opsmgr.net’. Rule id: Subscription02e8b6be_528d_407c_8edf_5f29dddaae6b

Failed to send notification using server/device

Notification subsystem failed to send notification using device/server ‘ex10mb1.opsmgr.net’ over ‘Smtp’ protocol to ‘kevinhol@opsmgr.net’. Microsoft.EnterpriseManagement.HealthService.Modules.Notification.SmtpNotificationException: Mailbox unavailable. The server response was: 5.7.1 Client does not have permissions to send as this sender. Smtp status code ‘MailboxUnavailable’. Rule id: Subscription02e8b6be_528d_407c_8edf_5f29dddaae6b

In this case – I must configure the Run-As account with a credential that is able to authenticate properly with my Mail Server.  I already have a user account and mailbox set up:  OPSMGR\scomnotify

Under Administration > Run As Configuration > Accounts – create a Run As Account.

The account type will be “Windows” and give it a name that makes sense:

image

Input the user account credentials:

image

Choose “More Secure” and click Next, then Close.

 

So – we have created our Run As Account – next we need to choose where to distribute it.  Account credential distribution is part of the “More Secure” option – we need to choose which Health Services will be allowed to use this credential.  In this case – we want to distribute the account to the management server pool in SCOM 2012 that handles notifications.

Open the properties of our newly created action account, and select the Distribution tab:

image

 

Click “Add”, and in the Option field – change it to “Search by Resource Pool Name” and click Search:

image

 

Choose the Notifications Resource Pool, click Add, and OK:

 

image

 

Now we have created our Run As Account for notifications, and then distributed it to the Notifications Resource Pool (which contains all management servers dynamically)

Next – we need to configure the Run As Profile – which will associate this account credential with the actual Notification workflows.

Under Administration > Run As Configuration > Profiles, find the “Notification Account” profile.  Open the properties of this Profile.

Under Run As Accounts – click Add:

image

 

Select our Notification Run As Account, and click OK

image

Then Save it.  This will update the Microsoft.SystemCenter.SecureReferenceOverride MP with these credentials and configurations for notification workflows.

From this point forward – Whichever Management server in the Notifications Resource Pool that is currently responsible for handling notifications, will spawn a MonitoringHost.exe process under our credential that we configured:

image

 

This credential will be used to authenticate to the Exchange server to send SMTP notifications.  Now my email notifications are flowing smoothly once again!  If the current management server goes down, another management server in the Notifications Resource Pool will pick up this responsibility and spawn the process, and continue sending notifications.

 

High availability out of the box.  One of the benefits of the improved SCOM 2012 architecture improvements.

3 Comments

  1. Sam Persis

    Hi

    Many thanks for your article.
    Is there anyway to define a global email rule for all monitored equipment regardless type of the equipment? When there is no answer to ping an email shall be send to the servicedesk.

    Is it possible to make more complex rules such as the one that follows:

    – A monitored equipment stopped responding to ping.
    – SCOM keeps trying to ping for a period of time.If response ok then clear alarm else send an email to servicedesk.
    – When servicedesk cleared the problem, SCOM keep an eye on the equipment for some period of time to check it is functioning properly.

    Many thanks.

    Kind regards,
    Sam

  2. Andy

    Hello,

    Working in SCOM 2019.

    For some reason, under the Subscription Scope, I’m on able to see two available conditions..?
    ::: raised by any instance in a specific group
    ::: raised by any instance of a specific class

    Not exactly sure what would cause this… ?

    Any help or explanation would be much appreciated,
    Thanks!!

Leave a Reply

Your email address will not be published. Required fields are marked *