ルーティングのトラブルシューティング

ここでは、Microsoft® Exchange 組織でルーティングが中断する可能性のある、いくつかの一般的な状況について説明します。ここでは、以下のトピックについて説明します。

• WinRoute の使用
  ここでは、ルーティングの問題をトラブルシューティングする場合に WinRoute ツールが役に立つことを示します。
• 一般的なリンク状態の問題
  ここでは、ルーティング グループ間の接続の切断、ルーティング グループ マスタの競合、削除済みのルーティング グループ、使用可能としてマークされないコネクタ、および不安定な接続によって発生する問題と、これらの状況を改善する方法について説明します。
• リンク状態通知の中止
  ここでは、ルーティング グループのブリッジヘッド サーバーを Exchange Server version 5.5 サーバーから Exchange 2000 Server または Exchange Server 2003 ブリッジヘッド サーバーに変更した後で、もう一度 Exchange 5.5 サーバーに戻したときに発生する問題について説明します。

WinRoute の使用

WinRoute は Exchange 2003 のツールの 1 つで、ルーティング マスタで認識されているルーティング トポロジとリンク状態のルーティング情報を把握するために使用します。このツールは、Exchange 2000 と Exchange 2003 のメッセージング環境で発生するルーティングの問題を解決する場合に、最初の手順で使用する必要があります。このツールで Exchange 2000 サーバーまたは Exchange 2003 サーバー上のリンク状態ポート (TCP ポート 691) に接続し、組織のリンク状態情報を取得します。リンク状態情報は、一連の GUID で構成されています。WinRoute は、この GUID を使用して Microsoft Active Directory® ディレクトリ サービス、コネクタ、およびブリッジヘッド サーバーのオブジェクトを照合し、人が理解しやすい形式にして示します。

注 :
WinRoute ツールとそのユーザー ドキュメントは、Exchange Server 2003 のダウンロード Web サイトで入手できます (このサイトは英語の場合があります)。組織のすべての Exchange 2000 サーバーおよび Exchange 2003 サーバーにこのツールをダウンロードして使用することをお勧めします。Exchange 2000 に付属している WinRoute ツールではなく、ダウンロードした WinRoute ツールを使用してください。

一般的なリンク状態の問題

Exchange は、TCP ポート 691 を使用して、ルーティング グループ内のルーティング グループ マスタとルーティング グループ メンバ間で、リンク状態とルーティング情報の更新に関する通信を行います。2 つのルーティング グループ間では、2 台のルーティング グループ ブリッジヘッド サーバーがダイジェストを比較し、X-LINK2STATE コマンドを使用してリンク状態情報を交換します。このダイジェストは Orginfo パケット内の暗号化されたデジタル署名で、それぞれのブリッジヘッド サーバーのリンク状態情報が格納されています。これらのダイジェストに違いがあると、2 台のサーバーが SMTP ポート 25 を使用してリンク状態情報を交換します。

ルーティング グループ マスタは、ルーティング グループ内の各サーバーが管理しているリンク状態の変更を反映するようにリンク状態を調整し、Active Directory から更新を取得します。ルーティング グループ マスタを使用できなくなると、ルーティング グループ内のすべてのサーバーは、ルーティング グループ マスタとの接続を失った時点の情報に従って動作を継続します。

ルーティング グループ マスタが再び使用できる状態になると、マスタはすべてのサーバーとコネクタを使用不可としてマークしてから、マスタのリンク状態情報を再構築します。次に、ルーティング グループ マスタは、使用不可になっているすべてのサーバーを検出し、ルーティング グループ内のメンバを更新します。

ここでは、以下のリンク状態の問題および推奨される解決方法について説明します。

• ルーティング グループ メンバとルーティング グループ マスタ間の接続の切断
• ルーティング グループ マスタ間の競合
• 削除済みのルーティング グループによって発生する問題
• "停止" としてマークされないコネクタ
• 不安定な接続

ルーティング グループ メンバとルーティング グループ マスタ間の接続の切断

ルーティング グループ メンバがルーティング グループ マスタに接続できない場合、WinRoute ではそのルーティング グループ メンバの横に赤い X 印で切断された状況が示されます。

この問題を解決するには、次の手順を実行します。

• Microsoft Exchange ルーティング エンジン サービス (RESvc) が起動していて、ルーティング グループ内の関連するすべてのサーバー上で制御された状態にあることを確認します。ルーティング エンジン サービスが不安定な状態にあると、ルーティング グループ メンバはルーティング グループ マスタに接続できなくなる可能性があります。まず、サービスが不安定になった原因を調査します。

• 関連するサーバーとマスタ ノードのポート 691 に対して Telnet セッションを開始し、ファイアウォールでポート 691 の使用が制限されていないことを確認します。このポートがアクティブな状態であることを示す、Microsoft ルーティング エンジンのバナーが表示されます。

• コマンド ラインに、次のように入力します。

  netstat -a -n 
  

  マスタ ノードのポート 691 に接続しているすべてのルーティング グループ メンバとマスタ自体が、次のような形式で表示されます。

  TCP    127.0.0.1:691          127.0.0.1:691         ESTABLISHED
  

• イベント ビューアのアプリケーション ログで、コンピュータ アカウント (ドメイン\サーバー名) を使用した認証に失敗したことを示すイベントを確認します。以下のトランスポート イベントを監視します。

  • メンバ サーバーがルーティング グループ マスタで認証されないと、イベント ID 961 が記録されます。
  • クライアント ノードがルーティング サービス (RESvc) で認証されないと、イベント ID 962 が記録されます。
  • クライアント ルーティング ノードがルーティング エンジン サービスで正常に認証されると、イベント ID 996 が記録されます。
  • ルーティング グループ メンバがルーティング グループ マスタで正常に認証されると、イベント ID 995 が記録されます。

• 関連するサーバーのネットワーク アドレス属性にある ncacn_ip_tcp 値を調べ、認証プロセスに使用する SPN (ServicePrincipalName) をそのサーバーが生成できることを確認します。この作業は、LDP (ldp.exe)、ADSI Edit (adsiEdit.msc) などのディレクトリ アクセス ツールを使用して実行できます。
  ルーティング グループの各メンバは、ルーティング グループ マスタに接続して相互に認証する必要があります。これを実行するために、メンバは DsClientMakeSpnForTargetServer を呼び出し、Exchange サーバーのネットワーク アドレス属性にある ncacn_ip_tcp 値を使用してマスタ ノード用の SPN を生成します。その後、ルーティング グループ メンバは Kerberos を使用して認証を行うことができます。この値が NetBIOS 名またはインターネット プロトコル アドレスではなく、完全修飾ドメイン名 (FQDN) であることを確認してください。Exchange ルーティング エンジン サービスを再起動します。

• ドメイン コンピュータ アカウントのパスワードの有効期限が切れていないことを確認します。

• ルーティング グループのメンバシップが複数のドメインにまたがる場合、子ドメインまたはルート ドメインに関する DNS の構成が誤っているためにその問題が発生しているのではないことを確認します。

• アクセス許可またはセキュリティを制限する Microsoft 以外のアプリケーションまたはグループ ポリシー オブジェクトを確認します。

• ルーティング グループ内の別のサーバーをルーティング グループ マスタとして構成します。この方法は一時的な解決策として利用できます。ルーティング グループ マスタの役割を別のサーバーに移すと、問題が解決するまでの代役として利用することができます。

• ルーティング グループ マスタまたは任意のルーティング グループ メンバに送信者アクセス許可がない場合、WinRoute はサーバーを [Am I connected to the Master?: NO] として表示します。このサーバーまたは所属するグループが、ルーティング グループ マスタに対する送信者アクセス許可を明示的に拒否されていないことを確認します。

ルーティング グループ マスタ間の競合

ルーティング グループ内に最初にインストールされるサーバーが、マスタ ノードつまりルーティング グループ マスタとして自動的に指定されます。他にサーバーがインストールされると、別のサーバーをルーティング グループ マスタとして指定することができます。

いずれの時点においても、1 台のサーバーのみが自身をマスタとして認識し、他のサーバーからもマスタとして認識される必要があります。マスタはルーティング グループ内にある (N/2) +1 台のサーバーが同意して認める必要があるとするアルゴリズムに従って、この構成が運用されます。この N は、ルーティング グループ内のサーバーの台数を表します。その結果、メンバ ノードがリンク状態の ATTACH データをマスタに送信します。

ときには、複数のサーバーが間違ったサーバーをルーティング グループ マスタとして認識することがあります。たとえば、別のマスタ ノードを選択しないでルーティング グループ マスタを移動するか削除すると、この操作はルーティング グループ マスタを指定する Active Directory の属性 msExchRoutingMasterDN にリンクされていないため、この属性が削除済みのサーバーをポイントしたままになる可能性があります。

また、古いルーティング グループ マスタがマスタ指定の解除を拒否したり、不正なノードがリンク状態の ATTACH 情報を古いルーティング グループ マスタに送り続けると、この状況に陥ることもあります。Exchange 2003 では、msExchRoutingMasterDN が削除済みのオブジェクトをポイントしている場合、マスタ ノードがマスタとしての役割を放棄し、マスタの役割のシャットダウンを開始します。

この問題を解決するには、次の手順を実行します。

• ルーティング グループ内のポート 691 に正常なリンク状態が通知されていることを確認します。ファイアウォールまたは SMTP のフィルタが通信をブロックしていないことも確認します。
• 停止している Exchange サービスがないことを確認します。
• Windows Resource Kit に用意されている Active Directory レプリケーション モニタ ツール (Replmon.exe) を使用して、Active Directory をレプリケートする際の待ち時間を調べます。
• ネットワークの問題と待ち時間について調べます。
• 存在しなくなった削除済みのルーティング グループ マスタまたはサーバーについて調べます。この場合は、イベント ビューアのアプリケーション ログに、ルーティング グループ マスタが存在していないことを示すトランスポート イベント 958 が記録されます。LDP (ldp.exe)、ADSI Edit (adsiEdit.msc) などのディレクトリ アクセス ツールを使用して、この情報を確認します。

削除済みのルーティング グループによって発生する問題

サーバーをルーティング グループ外に移動した後やその他の理由でグループを削除した場合、WinRoute に削除したオブジェクトに関する "object_not_found_in_DS" メッセージが表示されることがあります。

Exchange サーバーは、削除済みのオブジェクトを参照したままのリンク状態テーブルを保持しますが、関連するオブジェクトを検索するためにルーティング エンジン サービスで Active Directory を初期化して確認すると、これらのオブジェクトは見つかりません。

Exchange のルーティングでは、削除済みのルーティング グループとそのメンバ (つまり、サーバーとコネクタ) をリンク状態テーブルから自動的に削除できません。ルーティングは、削除済みのルーティング グループと存在し機能しているルーティング グループを区別なく扱います。まれに、削除済みのルーティング グループが、ルーティングとメール ループで誤動作の原因になることがあります。削除済みのルーティング グループは、Exchange 5.5 サイトが Exchange 2003 組織に参加するトポロジに重大な影響を与える可能性があります。

また、これらの削除済みルーティング グループのオブジェクトによってリンク状態テーブルのサイズが大きくなるため、リンク状態情報を交換するネットワーク トラフィックが増加する原因になる可能性もあります。

最後に、個人用アドレス帳 (PAB) またはオフライン アドレス帳 (OAB) に、削除済みルーティング グループと一致する従来の Exchange ドメイン名がある場合、削除済みルーティング グループのオブジェクトによって、PAB または OAB に存在しないユーザー宛てに送信されるメールは、配信先に到達できないメッセージを含むキューに追加されます。既定のタイムアウト値である 2 日が経過した後、メールは配信不能レポート (NDR) と共に送信者に返されます。削除済みルーティング グループのオブジェクトがない場合、存在しないユーザーに送信されるメールは、最初にキューに追加されるのではなく、NDR と共に直ちに送信者に返されます。

この問題を解決するには、まず、サーバーのルーティング情報を表示するために使用しているアカウントに適切なアクセス許可があることを確認します。可能であれば、システム アカウントと AT 対話型コマンドを使用して WinRoute にログオンします。適切な読み取りアクセス許可がないと、WinRoute に間違った object_not_found_in_DS メッセージが表示される可能性があります。

以下の方法の 1 つを使用すると、削除済みのルーティング グループをリンク状態情報から削除することができます。

• 組織内にあるすべてのサーバーを同時にシャットダウンしてルーティング キャッシュ情報を更新し、削除済みのルーティング グループとコネクタを削除します。
• 組織内にあるすべての Exchange サーバーの Exchange と WMI (Windows Management Instrumentation) サービスすべてを同時にシャットダウンします。

この問題は、Remonitor.exe を使用して、削除済みルーティング グループのフットプリント サイズを減らし、ルーティング グループを削除済みとマークすることで解決することもできます。

Remonitor.exe は、Exchange 組織にカスタム ルーティング パケットを導入できるツールです。カスタム パケットは、削除済みルーティング グループ パケットを変更したものです。この変更されたパケットにはサーバーやコネクタ エントリがないため、ルーティング グループ オブジェクトのサイズが大幅に削減されます。また、この変更されたパケットでは、ルーティング グループが削除されたコネクタ エントリが原因でルーティングの誤動作または遅延が発生する可能性がなくなります。このツールはコネクタ エントリのない変更されたパケットを導入するため、ルーティング グループが削除されたコネクタ エントリが存在することはありません。最後に、サーバーまたは接続エントリがこの削除済みルーティング グループに追加されることがないように、Remonitor.exe は変更されたルーティング グループのバージョン番号を更新します。

詳細については、「Remonitor.exe をローカル システム アカウントとして導入モードで実行する方法」を参照してください。

Remonitor.exe を実行すると、ルーティング パケットにはサーバー メンバやコネクタが含まれなくなります。ルーティング グループ アドレスの先頭には、キーワード deleted が付けられます。また、ルーティング グループ オブジェクトのバージョン番号が増加します。

"停止" としてマークされないコネクタ

コネクタが実際には使用できない状態、つまり "停止" 状態にあるときに、そのリンク状態が "稼動" としてマークされることがあります。以下の状況では、ルーティングでコネクタのリンク状態が停止としてマークされません。

• DNS を使用してアドレス空間内のドメインにルーティングするコネクタ (たとえば、DNS を使用する SMTP コネクタ)。
• リンク状態ルーティングを使用しない、Exchange 5.5 またはカスタム EDK (Exchange Development Kit) コネクタ。
• すべてのローカル ブリッジヘッドのローカル ブリッジヘッド サーバーとして使用するルーティング グループ コネクタ。ルーティング グループを作成する際に [すべてのローカル サーバーがこのコネクタ経由でメールを送信する] チェック ボックスをオンにして、すべてのローカル ブリッジヘッド サーバーをローカル ブリッジヘッドとして指定します。
• 1 台のブリッジヘッド サーバーが Exchange 5.5 サーバーであるルーティング グループ コネクタ。

その他に、以下のような通常と異なる状況があります。

• ルーティング グループ内において、メールの中継を行う際、ルーティング グループ内でのメッセージ転送エージェント (MTA) のループを防止できない。
• ごく最近変更されたスマート ホストを使用して構成したコネクタ。

ルーティングでコネクタを停止状態としてマークするには、すべてのソース ブリッジヘッド サーバーを VS_CONN_NOT_AVAILABLE または VS_CONN_NOT_STARTED の状態で停止する必要があります。WinRoute を使用すると、状態を確認できます。

不安定な接続

信頼性の低いネットワーク上にあり、"有効" と "停止" の状態が交互に繰り返しマークされるコネクタは、サーバー間で過剰なリンク状態の更新が行われる原因になります。こうした状態の変更が発生すると、Exchange 内の経路についてコストの高い再計算が頻繁に実行されます。イベント ビューアでは、イベント ID 4005 が数多く記録され、"reset routes" メッセージが表示されます。Exchange 2003 では、コネクタの状態が頻繁に変わる状況が検出されると、サーバーが変更を監視する期間である 1 回のポーリング期間内は状態が有効にマークされたままになるため、このような状態変更の回数が減ります。ただし、異なるポーリング期間にこれらの変更が発生すると、不安定な接続によって引き続きリンク状態のトラフィックが発生する可能性があります。Exchange 2003 サーバーでは、既定の状態遅延の変更間隔は 10 分です。

Exchange のルーティングによって最適な経路が選択され、メッセージの次のホップ先となるサーバーが見つかり、この "次のホップ先" サーバーの名前がキューに指定されます。最適な経路は、コスト、メッセージの種類、制限などの変動要素を考慮して選択されます。したがって、コネクタの状態が不安定な場合、Exchange は最適な経路の再計算を繰り返し実行する必要があります。この場合、Active Directory に対するクエリが実行され、パフォーマンス コストが高くなります。

Exchange のキュー機能でコネクタのブリッジヘッド サーバーに対するリンクの障害が通知されると、ルーティングによってこの情報がルーティング グループ マスタに中継されます。ルーティング グループ マスタはこの情報の送信を最大 10 分間停止し、コネクタの状態が変動するのを防止します。ルーティングによってコネクタが停止状態としてマークされると、障害発生元のサーバーを含め、組織内のすべての Exchange サーバーにこの変更が伝えられます。この通知はリセット ルートと呼ばれ、CPU の使用率に関して非常にコストの高いプロセスです。障害が発生したコネクタにメールが送信されなくなるため、ルーティングで新しい配信経路を生成する必要があります。コネクタを有効としてマークする場合も、同じプロセスが発生します。

不安定な接続は、以下の状況で発生します。

• ネットワーク トレースで見つかる、ネットワークの問題。
• Microsoft 以外のアプリケーションによる X.400 または SMTP プロトコル レベルの妨害で発生する、基本的なプロトコル サービス (SMTP と MTA) からのリンク状態通知のコールバックに対する反応。この状況で、問題が明らかになるのは、ネットワーク モニタが収集した情報によってのみです。また、Microsoft 製品サポート サービスで入手できる remonitor.exe ツールを使用することもできます。

ネットワーク モニタ (Netmon.exe) または remonitor.exe ツールを監視モードで使用すると、不安定な接続の根本原因を特定して対処することができます。さらに、不安定な接続によって送信トラフィックが過剰になる場合は、根本的な原因が解決されるまでリンク状態変更の通知を抑制できます。

詳細については、「サーバーでリンク状態情報を抑制する方法」を参照してください。

リンク状態情報を抑制する方法の詳細については、「高度なルーティング構成」の「コネクタのリンク状態トラフィックの抑制」を参照してください。

リンク状態通知の中止

Exchange 5.5 サーバーはリンク状態情報を使用しませんが、代わりにゲートウェイ アドレス ルーティング テーブル (GWART) を使用してメッセージをルーティングします。混在モードの組織では、Exchange 2000 以降のバージョンがこの制限を認識し、Active Directory から Exchange 5.5 サーバーの構成を直接読み取ります。このため、Exchange 2000 サーバーと Exchange 2003 サーバーは、Exchange 5.5 サーバーとリンク状態情報の交換を行いません。

Exchange ルーティング グループ内の Exchange 5.5 ブリッジヘッド サーバーを Exchange 2000 サーバーまたは Exchange 2003 サーバーにアップグレードし、ブリッジヘッド サーバーとして指定すると、そのサーバーはリンク状態情報の交換に参加し、ゼロのメジャー バージョン番号を持たなくなります。Exchange 2000 サーバーと Exchange 2003 サーバーは、リンク状態テーブルを比較してリンク状態に関する最新の情報を使用できるようにするために、リンク状態テーブルにバージョン番号を付けます。ゼロのメジャー バージョン番号は、リンク状態情報に参加しないサーバーまたはリンク状態情報を交換したことのないサーバーを表します。Exchange 5.5 サイトはリンク状態情報を交換しないため、すべてがゼロのバージョン番号を持っています。サーバーを Exchange 2000 サーバーまたは Exchange 2003 サーバーにアップグレードすると、そのサーバーはリンク状態情報に参加するようになり、メジャー バージョン番号が増加します。このため、他のルーティング グループのブリッジヘッド サーバーは、新しくアップグレードされたサーバーがそのルーティング グループのリンク状態の変更を通知してくるのを待ちます。

ここで、このルーティング グループのブリッジヘッド サーバーとして Exchange 5.5 サーバーを指定すると、問題が発生します。他のサーバーは依然として、前は Exchange 2000 または Exchange 2003 のブリッジヘッド サーバーであった Exchange 5.5 ブリッジヘッド サーバーがリンク状態の通知に参加することを想定し、更新されたリンク状態情報が通知されるのを待ちます。一方、ブリッジヘッド サーバーは Exchange 5.5 に戻されているため、リンク状態テーブルを持っていません。このため、このルーティング グループは孤立し、組織の動的なリンク状態の更新に参加しません。

この孤立したルーティング グループは、図 11.4 に示すような環境で問題が発生する原因になります。具体的には、Exchange 5.5 ブリッジヘッド サーバーは前は Exchange 2000 または Exchange 2003 ブリッジヘッド サーバーであったため、他のサーバーはこのサーバーがリンク状態の通知に参加することを想定します。次の図の Exchange 5.5 Internet Mail Connector と Exchange 2003 SMTP コネクタの両方が、1 台のスマート ホストを使用してインターネットにメールをルーティングします。スマート ホストを使用できなくなると、Exchange 2003 ブリッジヘッド サーバーは SMTP コネクタを経由する経路を使用不可としてマークします。一方、このブリッジヘッド サーバーは Exchange 5.5 サーバーがそのルーティング グループとコネクタに関するリンク状態情報を送信してくると想定しているため、Internet Mail Connector を経由する経路が使用できるものとして、この経路を通したメッセージの配信を試みます。一度配信に失敗すると、Exchange 2003 サーバーはループが発生する可能性を検知し、この経路による配信を試みなくなります。

リンク状態の通知をブロックするファイアウォールがシステムに追加されている場合にも、リンク状態通知は中止される可能性があります。たとえば、ルーティング グループ内ではポート 25 と 691 が要求され、ルーティング グループ間ではポート 25 が要求されます。また、ESMTP (Extended Simple Mail Transfer Protocol) コマンド X-LINK2STATE は、ファイアウォールによってブロックされないことが必要です。

この問題を解決するには、次の解決策を使用することができます。

• Exchange 5.5 ブリッジヘッド サーバーを Exchange 2000 サーバーまたは Exchange 2003 サーバーにアップグレードするか、別の Exchange 2000 サーバーまたは Exchange 2003 サーバーを使用してもう一度このルーティング グループのリンク状態情報を送信します。この方法のいずれかを使用すると、最適で最も簡単な方法で問題を解決することができます。
• 接続されていないルーティング グループをリンク状態のメジャー バージョン番号 0 にリセットするには、組織内のすべての Exchange サーバーを同時にシャットダウンしてから、すべての Exchange サーバーを再起動します。
• リンク状態の通知が妨げられないようにファイアウォールを構成します。

孤立したルーティング グループまたは切り離されたルーティング グループとメジャー バージョン番号の詳細については、マイクロソフト サポート技術情報の文書番号 842026「Exchange 2000 Server または Exchange Server 2003 でルーティングの状態情報がすべてのサーバーに正しく伝達されない」を参照してください。