Sail Away Systems

Scom Notifications Config gotcha

| 0 comments

I was scratching my head on why scom was insisting to be authenticated when sending to my exchange relay, this is why…..

Got this from Keven Hoffmans Blog, very useful,

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: OPSMGRscomnotify

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.

Leave a Reply

Required fields are marked *.