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)
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”
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.
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.
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.
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:
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:
Then select the Channel type, and the email address:
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.
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:
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:
Next we add the subscribers to the subscription:
We also need to choose which Channel we want to use for this subscription:
On this same screen – there is an option for delay aging:
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:
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 ‘firstname.lastname@example.org’. 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 ‘email@example.com’. 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:
Input the user account credentials:
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:
Click “Add”, and in the Option field – change it to “Search by Resource Pool Name” and click Search:
Choose the Notifications Resource Pool, click Add, and OK:
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:
Select our Notification Run As Account, and click OK
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:
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.