この記事は、アラート サブスクリプションの受信者が System Center 2012 Operations Manager で電子メール通知を受信しない可能性がある問題を解決するのに役立ちます。
元の製品バージョン: System Center 2012 Operations Manager
元の KB 番号: 2709639
原因
System Center Operations Manager は、解決状態が変化した新しいアラートまたはアラートの電子メール通知を送信できます。 電子メール通知は、アラートがサブスクリプションに対して定義された条件を満たし、その他すべての前提条件が満たされている限り、アラートをサブスクライブするすべての受信者に送信されます。 アラートがすべての条件を満たしていない場合、または通知が正しく構成されていない場合、目的の受信者は電子メール通知を受信しません。
通知の前提条件が満たされていることを確認する
SMTP サーバーを介して電子メール通知を送信するように System Center Operations Manager を構成するプロセスについては、「 通知の構成」を参照してください。
通知チャネルは、SMTP サーバーの正しい FQDN とポートを使用して構成する必要があります。 アドレスとポートは、System Center 2012 Operations Manager の通知リソース プールの一部であるすべての管理サーバーから使用できる必要があります。 アドレスまたはポートがファイアウォール規則またはマルウェア対策ソフトウェアによってブロックされている場合は、リソース プール サーバーの除外を作成する必要があります。
チャネルは、匿名認証またはWindows 認証用に構成できます。 匿名認証が選択されている場合、SMTP サーバーは匿名接続を許可するか、通知リソース プール管理サーバーの IP アドレスの除外を使用するように構成する必要があります。 Windows 認証が選択されている場合は、実行アカウントを作成し、通知アカウントの実行プロファイルに関連付ける必要があります。 このアカウントには、SMTP サーバー経由で電子メール メッセージを送信するアクセス許可が必要です。 詳細については、「 通知アクション アカウントの作成と構成」を参照してください。
サブスクライバー構成の確認
各サブスクライバーには、通知を送信する時間を指定するスケジュールを設定できます。 これは、そのサブスクライバー用に構成されているすべてのアドレスに影響を与える一般的な設定です。 サブスクライバーに対して定義されている各アドレスには、そのアドレスが通知を送信できるタイミングを指定するスケジュールを設定することもできます。 これにより、通知を使用して多くの柔軟性を実現できます。
たとえば、サブスクライバーは、毎日午前 8 時から午後 5 時までの一般通知を利用できます。 ただし、このサブスクライバーは、通知時間が異なる 2 つのアドレスを持つことができます。 たとえば、サブスクライバーは月曜日から木曜日に構成された職場のアドレスと、金曜日から日曜日に構成される代替アドレスを持つことができます。 サブスクライバーが電子メール通知を受信していない場合は、通知を送信する前に、一般サブスクライバーの可用性と特定のアドレスの可用性の両方を設定する必要があります。
通知の送信先のアドレスも有効なアドレスとして検証する必要があります。 サブスクライバーの SMTP サーバーと電子メール クライアントには、Operations Manager サーバーまたはドメイン名からの電子メール メッセージをブロックしているフィルター処理規則を含めないようにする必要があります。 必要に応じて、通知チャネルで定義されている応答先アドレスを、SMTP サーバーまたはクライアントのフィルター処理規則の除外として追加できます。
サブスクリプションの適用性を確認する
サブスクリプションには、通知を送信するために満たす必要がある複数の条件を設定できます。 いずれかの条件が満たされていない場合、通知は送信されません。
Operations Manager 2007 R2 では、最初に使用できる 2 つの条件は、特定のグループのメンバーであるインスタンスによってアラートが発生すること、および特定のクラスのインスタンスによってアラートが発生する条件です。 これら 2 つの条件では、アラートを発生させたインスタンスをアラートのソース フィールドに一覧表示する必要があります。 アラートには、クラスではなく、インスタンスの名前のみが一覧表示されます。 インスタンスがメンバーであるクラスが明確でない場合、アラート ビューでアラートが強調表示されているときに、 Actions メニューにそのクラスで使用可能なアクションが一覧表示されます。 クラスが条件の場合は、そのクラスをサブスクリプションに含める必要があります。 または、特定のインスタンスは、サブスクリプションが定義されている任意のグループのメンバーである必要があります。
System Center 2012 Operations Manager では、アラート通知の条件としていくつかの条件が追加されました。 1 つのサブスクリプションで複数の条件を指定できます。 ただし、通知を送信するには、すべての条件を満たす必要があります。 クラスとグループのメンバーシップに適用される規則は、Operations Manager 2007 R2 で適用される規則と同じです。
場合によっては、インスタンスの代わりに監視ノードまたはレプリケーション パートナーによってアラートが発生することがあります。 この状況では、アラートのソースは監視ノードまたはレプリケーション パートナーになります。 そのため、監視ノードまたはレプリケーション パートナーをソースとして含まないアラート サブスクリプションでは、電子メール通知は送信されません。 この最も一般的なインスタンスは、ソースがその正常性サービスのヘルス サービス 監視のインスタンスであるエージェントのハートビート アラートが見つからない場合です。
特定のルールとモニターに対してサブスクリプションを作成できます。 アラート ビューで特定のアラートを強調表示できます。通知サブスクリプションは、Actions メニューから、またはアラートを右クリックして [通知] サブメニュー選択することで作成できます。 サブスクリプションに複数のアラートを含める必要がある場合は、新しいサブスクリプション ウィザードで Created by rules or monitors 条件を選択でき、複数のルールとモニターを一度に選択できます。
既定では、サブスクリプションは、他の動作が指定されていない限り、すべてのアラートの重大度と優先度レベルに関する通知を送信します。 特定の重大度と優先度のアラートを作成するルールとモニターは、通常、オーバーライドを公開して、これらのアラートの重大度と優先度を変更します。 これらのアラート プロパティのオーバーライドは、これらのルールとモニターによって発生する既存のサブスクリプション アラートに含める場合や、既存のサブスクリプションからそのようなアラートを除外する場合に役立ちます。
System Center 2012 Operations Manager では、解決状態自体が条件でない限り、解決状態に関係なく、アラートが最初にすべての条件を満たすと、アラート通知が送信されます。 アラートを生成するルールまたはモニターに対してアラート抑制が有効になっている場合、サブスクリプションの条件が最初に満たされたときに送信される通知は 1 つだけです。 アラートが閉じられ、すべてのサブスクリプション条件を満たす新しいアラートが発生するまで、追加の通知は送信されません。
名前またはユーザー設定フィールドで特定のテキストを検索する条件により、一部のアラート通知が送信されないようにすることもできます。 指定されたワイルドカード値が指定されたアラート フィールドと一致しない場合、ワイルドカード テキストを許可する条件によって通知が妨げる可能性があります。 テストとして、より単純なワイルドカード値を使用するか、テスト中に条件を排除してアラート通知が送信されることを確認します。
通知の遅延
アラート サブスクリプションは、アラート条件がしばらく変更されていない場合にのみ通知を送信するように構成できます。 たとえば、20 分後に電子メール メッセージを送信するように構成されたサブスクリプションは、通知条件を満たさないようにアラート プロパティのいずれかが 20 分未満で変更された場合、メッセージを送信しません。 アラートのプロパティがサブスクリプションの条件に再び一致するように変更され、20 分以上残っている場合は、通知が送信されます。
通知が送信される前に変更される可能性があるプロパティは、重大度、優先度、解決状態、またはユーザー設定フィールドのプロパティです。 アラートがモニターによって生成され、アラートの重大度がモニターの状態と一致するように構成されている場合、遅延間隔の有効期限が切れる前にモニターの状態が変化すると、アラートの重大度が変更され、通知基準として特定の重大度を使用するサブスクリプションによる通知が防止される可能性があります。
通知リソース プール管理サーバーでリソース使用率またはワークロードが高い期間が発生している場合は、アラート通知が遅れる可能性があります。 通知ワークフローは、System Center Management サービスによって実行されます。 そのため、このサービスが利用できない場合や負荷がかかっている場合は、他の管理機能やデータ処理が通常どおりに発生しているように見えても、通知が受信されないか、遅延する可能性があります。