KB: Notification of Operations Manager alerts may not be received

System-Center-Team · ‎Feb 15 2019

First published on TECHNET on May 22, 2012

Here’s a new Knowledge Base article we published. This one describes an issue where recipients of Alert subscriptions may not receive e-mail notifications in OpsMgr.

=====

Symptoms

Recipients of Alert subscriptions may not receive e-mail notifications in System Center Operations Manager.

Cause

System Center Operations Manager is able to send e-mail notifications for new alerts, or alerts that have had a change in resolution state. E-mail notifications will be sent to all recipients that have subscribed to the alert, provided that the alert meets the defined criteria for the subscription, and all other pre-requisites have been met.If the alert does not meet all criteria, or notification is not configured correctly, intended recipients will not receive E-mail notification.

Resolution

Verify Notification Pre-Requisites have been met

The process for configuring System Center Operations Manager to send e-mail notifications via SMTP server is described in TechNet:

http://technet.microsoft.com/en-us/library/dd440890.aspx

The notification channel will need to be configured with the correct FQDN and port of the SMTP server. This address and port should be accessible from the RMS.If it is blocked by firewall rules or anti-malware software, exclusions for the RMS should be created.

The channel can be configured for Anonymous authentication or Windows authentication.If Anonymous is selected, the SMTP server should either allow anonymous connections, or be configured with an exclusion for the IP address of the RMS.If Windows Authentication is selected, a Run-as account will need to be created and associated with the Notification Account Run-As profile.This account will need permission to send e-mail through the SMTP server.See the associated help page in TechNet:

http://technet.microsoft.com/en-us/library/dd440886.aspx

Verify Subscriber configuration

Each subscriber can have a schedule during which time notifications will be sent to them.This is a general setting that affects all addresses configured for that subscriber.Each address that is defined for a subscriber can also have a schedule that specifies when that address is available to have notifications sent to it.This allows a great deal of flexibility with notifications.

For example:A subscriber could have general notification availability from 8:00am to 5:00pm every day of the week.This subscriber could have two addresses with different notification times, though, such as a work address that is configured for Monday - Thursday and an alternate address configured for Friday through Sunday.If e-mail notifications are not being received by the subscriber, the general subscriber availability and specific address availability must both be met before the notification can be sent.

The address the notification is sent to should also be verified as a valid address.The SMTP server and e-mail client of the subscriber should not have any filtering rules blocking e-mail from the Operations Manager server or the domain name.The Reply-To address defined in the notification channel can be added as an exemption to any filtering rules on the SMTP server or client, if needed.

Verify Subscription applicability

Subscriptions can have multiple criteria that must all be met for a notification to be sent.If any of the criteria are not met, no notification will be sent.

The first two available criteria are for the alert to be raised by an instance that is a member of a specific group and for the alert to be raised by an instance of a specific class.In these two criteria, the instance that raised the alert should be listed in the source field of the alert.The alert will only list the name of the instance, not the class.If the class that the instance is a member of is not clear, the Actions menu will list the available actions for that class when the alert is highlighted in an Alert view.The class should be included in the subscription, if class is a criterion, or the specific instance should be a member of any group that the subscription is defined for.

In some cases, an alert may be raised by a watcher node or replication partner on behalf of an instance.In this situation, the source of the alert would be the watcher node or replication partner, so alert subscriptions that do not include the watcher node or replication partner as a source would not send an e-mail notification.The most common instance of this would be missing agent heartbeat alerts, where the source is the instance of Health Service Watcher for that Health Service.

Subscriptions can be created for specific rules and monitors.A specific alert can be highlighted in an alert view and a notification subscription can be created for that alert from the Actions menu or by right-clicking the alert and choosing the Notifications submenu.If multiple alerts need to be included in a subscription, the “Created by rules or monitors” criteria can be selected in the new subscription wizard, and multiple rules and monitors can be selected at one time.

Subscriptions will notify on all alert severity and priority, by default, unless otherwise specified.Rules and Monitors that create alerts of specific severity and priority will usually expose overrides to change the severity and priority of these alerts.Overrides of these alert properties can be useful to include or exclude alerts raised by these rules and monitors from existing subscriptions.

If the criteria for resolution state is not specified, notifications will be sent when an alert is first raised (resolution state 0) and again when it is closed (resolution state 255).If custom resolution states are used in the management group, each time an alert’s resolution state is changed, a new notification will be sent.

NOTE :An alert notification will only be sent when an alert changes resolution state.If an alert is raised by a rule or monitor, alert suppression is enabled for that rule or monitor, and the conditions that caused the alert to be raised are encountered again before the original alert is closed or moved to a custom state, new notifications will not be sent.An increase in the repeat count of an alert will not send additional notifications.Once the alert is closed, however, any new detection of the conditions that raised the original alert will cause a new alert to be raised, with a corresponding notification.

Criteria that look for specific text in the name or in custom fields can also prevent some alert notifications from being sent.Any criteria that allow wildcard text may prevent notification if the wildcard values specified do not match the alert field specified.As a test, use a simpler wildcard value, or eliminate the criteria during testing to verify that the alert notification is sent.

=====

For the most current version of this article please see the following:

2709639 - Notification of Operations Manager alerts may not be received

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter :

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Products (50)

Special Topics (27)

Video Hub (462)

Most Active Hubs

Most Active Hubs

Video Hub

KB: Notification of Operations Manager alerts may not be received

Symptoms

Cause

Resolution