通知メールのトラブルシュートについて

こんにちは、SharePoint サポートの大関です。
本日は、通知メールに関してよくお問い合わせをいただく内容を取り上げ、メールが届かない時に確認するべき内容をご案内したいと思います。

通知メールが届かない、というお問い合わせを SharePoint のバージョンに関わらずいただくことが多くあります。
通知メールの仕組み自体は、SharePoint 2013 以外同様で、以下のような処理を経て送付されます。

1) コンテンツに通知を設定する

2) コンテンツ データベース の ImmedSubscriptions テーブルにエントリーが作成される
3) 通知対象の動作が実行される (アイテムの追加、編集、削除…)
4) コンテンツ データベースの EventCache テーブルにエントリが作成される (EventData カラムにバイナリで通知内容のデータが入る)
5) “即時の通知” タイマージョブが実行される
6) EventCache テーブルの EventData カラムが NULL になる
7) セキュリティ トリミングが実行される
8) 通知が送付される

通知メールが届かない場合、上記の処理のいずれが失敗しているのかを特定することで、トラブルシュートを行うことが可能です。
なお、よくお問い合わせをいただく内容の中では、要因は大きく分けて以下の 4 点のいずれかが大半を占めます。

1) タイマージョブの問題 (影響範囲:Web アプリケーション)
--------------------------------------------------------------------------------------
上記 5) の処理が失敗しているパターンです。
 “即時の通知” タイマージョブが正常に動作していないことが考えられます。即時の通知は Web アプリケーションごとに動作するジョブのため、この場合、特定の Web アプリケーションにホストされているすべてのサイトで、通知が送付されないという現象が発生します。
サーバーの全体管理サイトから、[監視] - [ジョブ状態の確認] をご確認いただき、即時の通知のタイマージョブがきちんと成功ステータスとなっているかご確認ください。
失敗している場合は、詳細なトラブルシュートが必要ですが、タイマーサービスの再起動で解消できる場合もあります。

2) 通知を送付する Web サーバーの問題 (影響範囲:コンテンツ データベース)
-----------------------------------------------------------------------------------------------------------
こちらも上記 5) の処理が失敗しているパターンです。
通知メールを送付してくれるサーバーは、サーバーの全体管理サイトの送信メールの設定に指定された SMTP サーバーとなりますが、SMTP サーバーに対してメール データを送付するのは、SharePoint の Web サーバーです。
具体的には、Microsoft SharePoint Foundation Web Application のサービスが開始されているサーバーが、通知メールを処理できます。また、Microsoft SharePoint Foundation Web Application が開始されているサーバーであれば、どれでも通知を処理できるのではなく、各コンテンツ データベースごとに通知を処理するサーバーが 1 対 1 で紐づいており、これをタイマーロックと呼びます。そのため、複数の Web サーバーが存在している場合も、タイマーロックを所持したサーバーが正常に稼働していない場合、特定のコンテンツ データベースにホストされたサイト内でのみ、通知が送付されないという現象が発生します。

SharePoint 2010 以降の場合、手動でロックを取得しているサーバーを切り換えることで、現象が回避できる可能性があります。
[サーバーの全体管理サイト] - [アプリケーション構成の管理] - [コンテンツ データベースの管理] から、対象のコンテンツ データベースをクリックし、"タイマー ジョブの優先サーバー" を指定します。

なお、SharePoint 2007 には残念ながら、上記のようにロック先サーバーを指定する機能が備わっていません。
そのため、SharePoint 2007 では  Microsoft SharePoint Foundation Web Application のサービスが開始されていないサーバーが誤ってロックを取得していまい、通知メールが送付出来ないという現象が多く報告されていました。
この場合、ロックはタイマーサービスの再起動で切り替わりますので、タイマーサービスの再起動によって現象が回避できる可能性があります。
※なお、ロックの切り替えはタイマーサービスの再起動の度に行われる訳ではないため、1 度の再起動では別のサーバーに切り替わらない場合があります。また、ロックを取得しているサーバーで Microsoft SharePoint Foundation Web Application のサービスを開始することも回避方法となります。

- 補足

ロック取得先サーバーは SQL Server に以下のクエリを実行することで確認が可能です。

SharePoint 2007 の場合
^^^^^^^^^^^^^^^^^^^^^^^

USE WSS_Content
SELECT * FROM TimerLock

※ WSS_Content には、対象のコンテンツ データベース名をご指定ください。

SharePoint 2010 以降の場合
^^^^^^^^^^^^^^^^^^^^^^^^^^^

SELECT t1.Name,t2.LockedBy FROM SharePoint_Config.dbo.Objects AS t1
JOIN WSS_Content.dbo.TimerLock AS t2
ON t1.Id = t2.LockedBy

※ WSS_Content には、対象のコンテンツ データベース名をご指定ください。
※ SharePoint_Config には、構成データベース名をご指定ください。

3) 通知対象ユーザーの権限の問題 (影響範囲:特定ユーザー)
------------------------------------------------------------------
上記 7) の処理が失敗しているパターンです。
通知メールをユーザーに送付する際には、セキュリティ トリミングが実行され、通知対象のユーザーが対象のコンテンツに対して権限を有しているかがチェックされます。
コンテンツに対するアクセス権限が無い場合には、通知メールは送付されません。
このような状況は、管理者の方が一括でユーザーへの通知を設定した場合に発生しえます。(なお権限が無い場合も、通知を設定した旨を通知する初回のメールは届きます)
特定のユーザーに通知メールが届かない場合、対象のユーザーがコンテンツに対して閲覧以上の権限を有しているかご確認ください。

4) SMTP サーバーの問題 (影響範囲:全ユーザー)
--------------------------------------------------------------------
上記 8) の処理が失敗しているパターンです。
2) 通知を送付する Web サーバーの問題のセクションに記載しましたとおり、最終的にメールを配信するのはサーバーの全体管理サイトで設定されている SMTP サーバーです。
正しい SMTP サーバーが指定されていない、SMTP サービスが開始されていない、ネットワーク経路に問題あるなど、SMTP サーバーに正しく接続できない場合、通知メールは送付されません。
たとえば、SMTP サーバーが使用できない時には SharePoint サーバーのイベントログに以下のようなログが記録されます。

------------
ログの名前:         Application
ソース:           Microsoft-SharePoint Products-SharePoint Foundation
日付:            20XX/MM/DD hh:mm:ss
イベント ID:       6857
タスクのカテゴリ:      電子メール
レベル:           エラー
キーワード:       
ユーザー:          contoso\Administrator
コンピューター:       sps.contoso.com
説明:
SMTP ホスト exchange.contoso.com に接続できません。
------------

ファーム内のすべての通知メールが処理されていない場合、SMTP サーバーの正常性もご確認いただければと思います。

いかがでしたでしょうか。
通知メールが送付されない範囲によって、確認ポイントが異なることがお分かりいただけるかと思います。
通知メールのトラブルシュートに、上記内容が少しでもお役に立てれば幸いです。

また、上記に該当しないトラブルもたくさんあるかと思います。
お困りの場合は、弊社サポートサービスに是非ご相談ください!