Exchange 2013 メールフロー トラブルシューティング
Exchange Server をご利用の皆様
こんにちは。Exchange サポートの河本です。
今回は Exchange Server 管理者を悩ませる一つであるメール フローに関するトラブル シューティングについて紹介します。
メール フロー問題の症状やそれぞれの要因は多岐に渡るため、全てについて解説するのは難しいですが、今回は Exchange Server 2013 環境におけるトラブル シューティングするために有効なログの取得方法、解析方法について以下の 5 つの項目分けて解説させていただきます。
・Exchange Server 2013 のトランスポート アーキテクチャー
・DSN と NDR
・メッセージヘッダー
・追跡ログ
・キュー
・SMTP プロトコル ログ
A. Exchange Server 2013 のトランスポート アーキテクチャー
Exchange Server 2013 環境でメール フローのトラブルシューティングする上で大切なことは、Exchange Server 2013 ではどのようにメールを受信し、メールボックスへ配信されるのかや メールを内部ユーザーまたは外部ユーザー宛てにメールを送信した際に、どのようにメールがルーティングされるのかについてある程度理解することです。本ブログではExchange Server 2013 のトランスポート アーキテクチャーの詳細な説明は割愛しますが、以下に参考となる情報を紹介します。
<アーキテクチャ ポスター>
Exchange Server 2013 のアーキテクチャを体系的に理解できる PDF ファイルです。 この PDF ではトランスポートだけではなく、他の Exchange Server 2013 の機能についても網羅されており、この PDF ファイルを熟知すれば Exchange Server 2013 の動作についておさえられると言っても過言ではありません。
Title: Exchange Server 2013 Architecture Poster PDF Download Available
Url: https://blogs.technet.com/b/exchange/archive/2013/06/10/exchange-server-2013-architecture-poster-pdf-download-available.aspx
<メール フロー/メール ルーティング>
Exchange Server 2013 のトランスポート コンポーネントやどのようにメールがルーティングされるのかを詳しく解説している情報です。この点をある程度理解するとメール フローのトラブルシューティングする上でどのログを見るべきかが見えてきます。
Title: メール フロー
Url : https://technet.microsoft.com/ja-jp/library/aa996349(v=exchg.150).aspx
Title: メール ルーティング
Url : https://technet.microsoft.com/ja-jp/library/aa998825(v=exchg.150).aspx
B. DSN と NDR
送ったメールが届いていないとかタイムリーに配信されていないという問題が出ている場合に、まず最初に確認するのが送信者が配信状態通知 (DSN: Delivery Status Notification) を受信していないかどうかです。受信者にメールが配信されていない場合は、通常 配信不能レポート (NDR) メッセージが送信者に配信されます。これらの DSN や NDR メッセージにはエラー コード、問題に関する技術的な詳細が含まれ、メッセージの送信者に対するトラブルシューティング手順が含まれることもあり、メール フローのトラブル シューティングする上で重要な情報です。DSN と NDR について以下の公開情報を参照し、受信したDSN と NDR メッセージからトラブルシューティングしてみて下さい。
Title: オンプレミスの Exchange 2013 と Office 365 の DSN と NDR
Url: https://technet.microsoft.com/ja-jp/library/bb232118(v=exchg.150).aspx
C. メッセージヘッダー
受信したメッセージには必ずメッセージ ヘッダーがあります。メッセージ ヘッダーから受信したメッセージがどのようなサーバーを経由して最終的に受信者までに配信されたのか確認できます。また経由したサーバーで時刻も記録されるので、メッセージを遅延して受信した場合、どこで遅延したのか確認することができます。
メッセージ ヘッダーの確認方法
メッセージ ヘッダーは Outlook の場合はメッセージをクリックして、 [ファイル] - [情報] - [プロパティ] から確認できます。
また OWA の場合にはメッセージを選択して "メッセージの詳細表示" から確認できます。
メッセージ アナライザーの利用
Remote Connectivity Analyzer のサイト (https://testconnectivity.microsoft.com/) のメッセージ アナライザーを使用するとどのようなフローでどこに遅延があるのか視覚的に確認できます。
注意事項:
Exchange ではないSMTP サーバーによって特殊なヘッダーが付与されていると、メッセージ アナライザーによって Exchange サーバーで遅延しているかのように誤って表示される場合がありますので、その場合は該当サーバーが Exchange サーバーであるかどうか確認するようにご注意下さい。
D. 追跡ログ
Exchange Server 2013 でのメッセージ追跡については以下のブログでも紹介しておりますので、是非ご確認下さい。
Title: Exchange 2013 でメッセージを追跡する
Url: https://blogs.technet.com/b/exchangeteamjp/archive/2015/03/17/3646601.aspx
Exchange Server 2013 のメッセージ追跡ログは既定では下記のディレクトリに出力されます。また、ファイルの日付は GMT で記載されていますので、日本時間から -9 時間した日付のファイルにログが書き込まれます。
<Exchange のインストール ディレクトリ>\V15\TransportRoles\Logs\MessageTracking
例: C:\Program Files\Microsoft\Exchange Server\v15\TransportRoles\Logs\MessageTracking
上述で Exchange Server 2013 のトランスポート アーキテクチャーを理解するのが重要であると説明しましたが、この追跡ログを解析する上でその理解が必要となるからです。Exchange Server 2013 メールボックス サーバーでは大きく分けると 3 種類のトランスポート サービス (メールボックス トランスポート発信サービス、メールボックス トランスポート配信サービス、トランスポート サービス) があり、それぞれサービス毎に異なる追跡ログファイルにメッセージ配信に関するログが記録されます。
1) メールボックスから、メールボックス トランスポート発信サービスへピックアップされたときのログ
ファイル フォーマット: MSGTRKMS{yyyyMMddHH-n}.LOG
* {yyyyMMddHH-n} は、日付と時間と連番で、2014 年 6 月 13 日 10 時であれば、"2013061310-1" のようになります。
2) トランスポート サービス内で処理された時のログ
ファイル フォーマット: MSGTRK{yyyyMMddHH-n}.LOG
3) メールボックス トランスポート配信サービスから、メールボックスへ配信された時のログ
ファイル フォーマット: MSGTRKMD{yyyyMMddHH-n}.LOG
- 追跡ログの有効/無効の確認、出力パスを確認する方法
追跡ログが有効であるかどうか確認したい場合は、Exchange 管理シェルから以下のコマンドを実行します。
出力された項目の MessageTrackingLogEnabled が True であれば有効です。また、MessageTrackingLogPath が出力パスとなります。
Get-TransportService "<メールボックス サーバー名>" | fl MessageTrackingLogEnabled, MessageTrackingLogPath
メッセージ追跡ログの検索
メッセージ追跡ログ ファイルを直接開いて確認するとなると敷居が高いように見えてしまうかもしれないですが、ご安心下さい。Exchange Server 2013 ではメッセージ追跡ログを検索するための UI 及びコマンド レットが用意されておりますので、これらのツールを使用して十分トラブル シューティングできます。
例えば 2015/11/06 から 2015/11/10 の期間で Administrator から UserA 宛てに送信したメールが届いていないという申告があったと仮定します。
その場合Exchange 管理シェルから以下のようにコマンドを実行することで該当期間の Administrator から UserA 宛てのメッセージ フローの一覧を出力することができます。
Get-MessageTrackingLog -Start 2015/11/06 -End 2015/11/10 -Recipients UserA@conto.com -Sender Administrator@contoso.com
出力結果の詳細を確認したい場合は、最後に |fl をつけてみると多くの情報が出てきます。
Get-MessageTrackingLog コマンド レットでは上記の例以外にも色々なパラメーターが用意されていますので、以下の公開情報を参考にしてパラメーターをうまく指定してトラブル シューティングを効率的に進めてみて下さい。
Title: Get-MessageTrackingLog
Url: https://technet.microsoft.com/ja-JP/library/aa997573(v=exchg.150).aspx
Title: メッセージ追跡ログの検索
Url : https://technet.microsoft.com/ja-jp/library/bb124926(v=exchg.150).aspx
なおメッセージ追跡ログ ファイルに記録されている各種フィールドやイベントについては以下の公開情報を参照することで、どのトランスポート処理で何が起こっているのか確認することができます。
Title: メッセージ追跡
Url: https://technet.microsoft.com/ja-jp/library/bb124375(v=exchg.150).aspx
UI として配信レポートによるメッセージの追跡機能があります。Exchange 管理センターへログインして、[メール フロー] - [配信レポート] より検索対象のメッセージを絞り込んで特定ユーザーとの間で送受信したメッセージ関する検索結果を絞り込むことができます。
配信レポートによるメッセージ追跡方法については以下の公開情報をご参考下さい
Title: 配信レポートによるメッセージの追跡
Url : https://technet.microsoft.com/ja-jp/library/jj150554(v=exchg.150).aspx
E. キュー
メール フローの問題の中で Exchange サーバー内でメールが滞留するという事象があります。滞留する要因はサーバーのパフォーマンス問題やネットワーク問題など多岐に渡りますが、キュー メッセージが滞留しているかどうかと滞留している場合のエラー内容を確認するのは重要なポイントです。
Get-Queue での確認
1.Exchange 管理シェルから以下のようにコマンドを実行することでメッセージが滞留しているかどうか確認できます。
Get-Queue -Server "<Exchange サーバー名>"
以下のように出力されますので、どのキューにどのくらい滞留しているのか確認します。
Identity DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
-------- ------------ ------ ------------ -------- --------- -------------- -------------
Ex2k13\3 SmartHost... Retry 29 0 Normal 0 akihidekex2-wjg-jp.mai...
Ex2k13\Submission Undefined Ready 0 0 Normal 0 発信
2.滞留しているキュー名を特定し、滞留している要因を確認したい場合は、以下のようにコマンドを実行します。
Get-Queue -Identity "<キューの識別名>" |fl
例)
Get-Queue -Identity "Ex2k13\3" |fl
以下のように出力されます。以下では451 4.4.0 DNS query failedエラーで外部にメッセージを送信できない状況であることが確認できます。
------ ここから ----
RunspaceId : 1956df48-996f-4a5a-b5f1-308daa3fc372
DeliveryType : SmartHostConnectorDelivery
NextHopDomain : akihidekex2-wjg-jp.mail.protection.outlook.com
TlsDomain :
NextHopConnector : 442313bd-9912-477f-af98-981284fe0f99
Status : Retry
MessageCount : 29
LastError : 451 4.4.0 DNS query failed. The error was: DNS query failed with error ServerFailure
RetryCount : 5
LastRetryTime : 2015/11/09 19:19:10
NextRetryTime : 2015/11/09 19:24:18
FirstRetryTime : 2015/11/09 19:09:19
DeferredMessageCount : 0
LockedMessageCount : 0
MessageCountsPerPriority : {0, 0, 0, 0}
DeferredMessageCountsPerPriority : {0, 10, 19, 0}
RiskLevel : Normal
OutboundIPPool : 0
NextHopCategory : External
IncomingRate : 0
OutgoingRate : 0
Velocity : 0
OverrideSource :
QueueIdentity : Ex2k13\3
PriorityDescriptions : {High, Normal, Low, None}
Identity : Ex2k13\3
IsValid : True
ObjectState : New
------ ここまで ----
3．更にキューに滞留しているメッセージの状態を確認したい場合には以下のようにコマンドを実行します。
Get-Queue -Identity "<キューの識別名>" |Get-Message |fl
例)
Get-Queue -Identity Ex2k13\3 |Get-Message |fl
以下のように出力されます。送信コネクタ "Outbound to Office 365 (2)" を経由して送信しようとしているメッセージであることが確認できます。
------ ここから ----
RunspaceId : f427aabf-f4ae-4f9c-ae70-c936f0247d91
Subject : Message November Test 4
InternetMessageId : <d3f630ae-3726-4d6c-ad1c-61d79f671bc5@journal.report.generator>
FromAddress : <>
Status : Ready
Size : 6.212 KB (6,361 bytes)
MessageSourceName : Journaling
SourceIP : 255.255.255.255
SCL : 0
DateReceived : 2015/11/10 9:16:05
ExpirationTime :
LastError :
RetryCount : 0
Recipients : {popuser01@ggg.com;2;2;[{LRT=};{LED=};{FQDN=};{IP=}];0;CN=Outbound to Office 365 (2),
CN=Connections,CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Excha
nge Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Contoso Corpor
ation,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com;0}
ComponentLatency :
MessageLatency : 00:32:10.3644108
DeferReason : None
LockReason :
Priority : Low
ExternalDirectoryOrganizationId : 00000000-0000-0000-0000-000000000000
Directionality : Originating
OriginalFromAddress : gbs19@contoso.com
AccountForest : contoso.com
MessageIdentity : Ex2k13\3\47678431952970
Queue : Ex2k13\3
Identity : Ex2k13\3\47678431952970
IsValid : True
ObjectState : New
------ ここまで ----
QueueViewer ログ
メッセージの滞留は一時的なネットワークの問題で発生している場合だと、Exchange 管理者が滞留していた事実すら気づかない場合があります。過去にいつ、どれだけのメッセージが滞留していたのかどうか確認する方法としてQueueViewer ログがあります。Exchange 2013 サーバー上のキューに関する情報は 1 時間毎に以下のパスに TRANSPORTQUEUEYYYYMMDD-n.LOG というファイルに記録されます。
<Exchange のインストール ディレクトリ>\V15\TransportRoles\Logs\Hub\QueueViewer
例: C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\QueueViewer
以下のように記録されます。以下では 11/9 18:56 以降から 23 件のメッセージが滞留し、451 4.4.0 DNS query failed エラーとなっていることが確認できます。
------ ここから ----
2015-11-09T10:06:53.026Z,,SUMMARY,,,,,,,,,,,,,,,,,,TotalMessageCount = 0; PoisonMessageCount = 0,
2015-11-09T10:07:54.192Z,,SUMMARY,,,,,,,,,,,,,,,,,,TotalMessageCount = 0; PoisonMessageCount = 0,
2015-11-09T10:08:54.402Z,1,QUEUE,Ex2k13\Submission,Ready,Undefined,発信,(submission)::0:0:000000:0::0:0:;,29,0,0,1.05,0.64,-0.41,Internal,Normal,0,00000000-0000-0000-0000-000000000000,,,,
2015-11-09T10:08:56.166Z,,SUMMARY,,,,,,,,,,,,,,,,,,TotalMessageCount = 23; PoisonMessageCount = 0,
2015-11-09T10:09:54.937Z,1,QUEUE,Ex2k13\3,Retry,SmartHostConnectorDelivery,akihidekex2-wjg-jp.mail.protection.outlook.com,(akihidekex2-wjg-jp.mail.protection.outlook.com)::1:4:442313:0::0:0:;,29,0,0,0,0,0,External,Normal,0,442313bd-9912-477f-af98-981284fe0f99,,451 4.4.0 DNS query failed. The error was: DNS query failed with error ServerFailure,,
------ ここまで ----
公開情報
その他のキューの管理に関する参考情報として以下を参照にしてください。
Title: Exchange 管理シェルを使用してキューを管理する
Url : https://technet.microsoft.com/ja-jp/library/aa998047(v=exchg.150).aspx
F. SMTP プロトコル ログ
メール フローのトラブル シューティングでメッセージ追跡ログに対象のメッセージに関する情報が出てこない場合があります。このようなシナリオは多種多様ですが、例えば Exchange 2013 サーバーと外部の SMTP サーバー間で正しく SMTP 通信ができていないという場合があります。このような場合には SMTP レベルでの確認が必要となるので、後述の SMTP プロトコル ログを採取してトラブルシューティングしていきます。
なおここでも Exchange Server 2013 のトランスポート アーキテクチャーをある程度理解していないと SMTP プロトコル ログの解析は苦労します。また追跡ログのようにSMTP プロトコル ログをツールを使用して確認する方法がないため、ログ ファイルを開いて確認を進めることになります。まずは受信コネクタと送信コネクタのログの有効化とログ ファイルが保存されている場所について説明します。
受信コネクタ ログ
送信コネクタのプロトコル ログは既定で有効ではないため、ログを採取するには前もって有効にします。
受信コネクタのプロトコル ログは、以下のフォルダー内に “RECVyyyymmdd-n.log” の形式で保存されております。
プロトコル ログは既定では下記のフォルダーに格納されます。
(クライアント アクセス サーバー上にあるログ)
<Exchange のインストール ディレクトリ>\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
(メールボックス サーバー上にあるログ)
<Exchange のインストール ディレクトリ>\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
- 補足
Exchange 管理シェルより、下記のコマンドを実行することで、受信コネクタ プロトコル ログが有効であるかどうか、確認することができます。
Get-ReceiveConnector | fl Name, ProtocolLoggingLevel
* ProtocolLoggingLevel が "None" なら無効、"Verbose" なら有効です
ログが無効な場合は、下記の手順で有効にすることができます。有効にすると、それ以降の SMTP 送受信の SMTP コマンドが記録されます。
Set-ReceiveConnector "<受信コネクタ名>" -ProtocolLoggingLevel Verbose
* <受信コネクタ名> は、上記の確認コマンドで Name に表示される値です。
* 無効に戻すには、-ProtocolLoggingLevel に None を指定します。
送信コネクタ ログ
送信コネクタのプロトコル ログは既定で有効ではないため、ログを採取するには前もって有効にします。
送信コネクタのプロトコル ログは、以下のフォルダー内に “SENDyyyymmdd-n.log” の形式で保存されております。
プロトコル ログは既定では下記のフォルダー配下に格納されます。
(クライアント アクセス サーバー上にあるログ)
<Exchange のインストール ディレクトリ>\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend
(メールボックス サーバー上にあるログ)
<Exchange のインストール ディレクトリ>\V15\TransportRules\Logs\Hub\ProtocolLog\SmtpSend
- 送信コネクタ ログの有効化
Exchange 管理シェルより、下記のコマンドを実行することで、送信コネクタ プロトコル ログが有効であるかどうか、確認することができます。
Get-SendConnector | fl Name, ProtocolLoggingLevel
* ProtocolLoggingLevel が "None" なら無効、"Verbose" なら有効です
ログが無効な場合は、下記の手順で有効にすることができます。有効にすると、それ以降の SMTP 送受信の SMTP コマンドが記録されます。
Set-SendConnector "<送信コネクタ名>" -ProtocolLoggingLevel Verbose
* <送信コネクタ名> は、上記の確認コマンドで Name に表示される値です。
* 無効に戻すには、-ProtocolLoggingLevel に None を指定します。
-組織内送信コネクタ ログの有効化
Exchange 組織内でのメール送信、例えば CAS サーバーから MBX サーバーへの送信や以前のバージョンの Exchange サーバーへの送信には暗黙的な不可視の組織内送信コネクタと呼ばれる特殊は送信コネクタが利用されます。
既定では組織な送信コネクタ プロトコル ログは無効です。後述している “プロトコル ログからの解析例” ではこの組織な送信コネクタ プロトコル ログを有効にすることでトラブル シューティングしている例を記載していますので、Exchange
管理者が組織内送信コネクタを理解し、必要に応じてプロトコル ログを有効にすることは重要です。
Exchange 管理シェルより、下記のコマンドを実行することで、組織内送信コネクタ プロトコル ログが有効であるかどうか、確認することができます。
Get-TransportService |fl Name,IntraOrgConnectorProtocolLoggingLevel
* ProtocolLoggingLevel が "None" なら無効、"Verbose" なら有効です
ログが無効な場合は、下記の手順で有効にすることができます。有効にすると、それ以降の SMTP 送受信の SMTP コマンドが記録されます。
Set-TransportService -Identity "<Exchange サーバー名>" -IntraOrgConnectorProtocolLoggingLevel:Verbose
* 無効に戻すには、-ProtocolLoggingLevel に None を指定します。
公開情報
SMTP プロトコル ログの出力については以下の公開情報もご参考下さい。
Title: プロトコル ログ出力を構成する
Url : https://technet.microsoft.com/ja-jp/library/bb124531(v=exchg.150)
プロトコル ログからの解析例
さて上記の例を元に各プロトコル ログ出力を構成したとします。例えば Exchange 2010/2013 の混在環境で Exchange 2013 ユーザーから Exchange 2010 ユーザーへのメッセージが滞留しているとします。なぜ滞留しているのか確認するために SMTP プロトコル ログが効果を発揮します。どのログを見るかはExchange Server 2013 のトランスポート アーキテクチャーの理解が前提となりますが、Exchange 2013 から Exchange 2010 へのメール送信フローとして Exchange 2013 メールボックス サーバーの トランスポート サービスから Exchange 2010 のハブ トランスポート サーバーへメールがルーティングされるので、Exchange 2013 メールボックス サーバーの トランスポート サービスの送信コネクタのログ (<Exchange のインストール ディレクトリ>\V15\TransportRules\Logs\Hub\ProtocolLog\SmtpSend
) に着目します。今回の例では以下の SMTP 通信ログがあるとします。
------ ここから ----
2015-11-10T00:05:20.917Z,組織内の SMTP 送信コネクタ,08D2E8A2916499FA,339,192.168.1.52:9404,192.168.1.52:475,-,,Local
2015-11-10T00:16:10.994Z,組織内の SMTP 送信コネクタ,08D2E8A291649A03,0,,192.168.1.53:25,*,,attempting to connect
2015-11-10T00:16:32.714Z,組織内の SMTP 送信コネクタ,08D2E8A291649A03,1,,192.168.1.53:25,*,,"Failed to connect. Winsock error code: 10060, Win32 error code: 10060, Error Message: 接続済みの呼び出し先が一定の時間を過ぎても正しく応答しなかったため、接続できませんでした。または接続済みのホストが応答しなかったため、確立された接続は失敗しました。 192.168.1.53:25"
------ ここまで ----
上記の例で IP アドレス 192.168.1.52 は Exchange 2010 ハブ トランスポート サーバーの IP アドレスであるため、Exchange 2013 メールボックス サーバーからExchange 2010 のハブ トランスポート サーバーへ SMTP 通信が確立できなかったことが分かります。実際に Exchange 2010 ハブ トランスポート サーバーの Microsoft Exchange Transport サービスが停止していたため、起動することでメール滞留が解消しました。このようにプロトコル ログからメール滞留の原因特定と解決策に繋がる情報を得ることができます。
最後に
メール フローのトラブルシューティング方法は多種多様であり、今回のブログではそのすべてをカバーできているわけではないですが大半のメール フローの問題は案内しているいずれかの方法で解決の糸口となる情報を得られると思っています。Exchange サポート チームにメール フローの問題でお問い合わせされる場合は、今回ご案内した
ログの依頼があるかもしれませんが、本ブログでそれぞれのログの意味や Exchange 管理者様でトラブルシューティングできるための有益な情報として少しでもお役に立てれば幸いです。
今後とも、弊社サポート ブログをよろしくお願いいたします。