パブリック フォルダーのレプリケーションのトラブルシューティング – パート 3: レプリカの削除と共通の問題のトラブルシューティング
原文の記事の投稿日: 2011 年 11 月 28 日 (月曜日)
US ブログへの最初の投稿日: 2006 年 1 月 24 日
この記事は、パブリック フォルダーのレプリケーションの問題のトラブルシューティングに関する 3 番目の投稿です。最初の投稿 (英語)では、新しい変更のレプリケーションのトラブルシューティングについて説明しました。2 番目の投稿 (英語)では、既存のデータのレプリケーションのトラブルシューティングについて説明しました。連載記事の最後となるこの投稿では、レプリカの削除と共通の問題のトラブルシューティングについて説明します。トラブルシューティングの全体像を把握するには、すべての連載記事をお読みください。
レプリカの削除のトラブルシューティング
すべてのフォルダーのレプリカ一覧から古いサーバーを削除したのに、ESM でこの古いストアのパブリック フォルダー インスタンスに移動すると、一連のフォルダーがまだ残っています。この現象は、レプリカを削除するプロセスに問題があるために発生します。Exchange 2003 SP2 バージョンの ESM では、この状態にあるパブリック ストアを削除しようとすると、次のメッセージがダイアログ ボックスに表示されます。
“フォルダー レプリカが含まれているため、このパブリック フォルダー ストアを削除できません。データの損失を避けるには、パブリック フォルダー ストアを右クリックし、[すべてのレプリカを移動] をクリックしてレプリカを別のサーバーに移動してください。コンテンツが新しいサーバーに複製され、ローカル レプリカが削除されるまで、数時間かかることがあります。”
フォルダーのレプリカ一覧からストアを削除しても、そのストアからデータはすぐに削除されません。そうする代わりに、ストアから特別な 0x20 ステータス要求が他のすべてのレプリカに送信されます。この要求は、Replica Delete Pending Status Request (RDPSR) と呼ばれるものであり、アプリケーション ログでは通常のステータス要求と区別できません。RDPSR には、レプリカが削除保留中であることを示すフラグが含まれます。他のストアはこの 0x20 を受信すると、Replica Delete Pending Ack (RDPA) と呼ばれる特別な 0x10 で応答します。RDPA はデータの削除を了解したことを意味しますが、他のストアは削除保留中のレプリカが持つすべての CN がすでにある場合にのみこの 0x10 を送信します。レプリカが実際に削除されるのは、他のストアがデータを持つことを示す 0x10 を元のストアが受信した後のことです。
したがって、パブリック フォルダーが空になる前にストアを削除すると、データの損失を招く可能性があります。この操作に警告が表示されるのは、2003 SP2 ESM だけです。それ以前のバージョンでは、パブリック フォルダーを手動でチェックして、ストアを削除してもかまわないかを確認する必要があります。パブリック ストアを削除する場合は、そうする前に必ずパブリック フォルダー インスタンスをチェックしてください。2003 SP2 ESM の使用時にデータ損失の警告が表示された場合は、それを無視したり迂回しようとはしないで、レプリカ削除プロセスのトラブルシューティングを行う必要があります。
Exchange 2003 SP2 よりも前のバージョンでは、レプリカ一覧から削除されたサーバーは RDPSR を一度だけ送信します。これに応答がなければ、フォルダーはパブリック フォルダー インスタンスに無期限に残留します。これを削除するには、ストアをレプリカ一覧に追加してから再び削除して、新しい RDPSR が送信されるようにする必要があります。2003 SP2 では、この動作が変更され、いずれかのストアから RDPA が応答されるまで、1 時間間隔で再試行するように改められました。
トラブルシューティング
バックフィル プロセスをトラブルシューティングするときと、ほぼ同じ方法を使用します。
1. 削除保留中のレプリカは 0x20 を送信したか ?
レプリカを削除するときにログを有効にしていない限り、この動作は確認できません。幸い、レプリカを再び追加してから改めて削除することができます。そうした後で、アプリケーション ログをチェックして 0x20 を探します。
2. 0x20 は他のレプリカに到達したか ?
これはすでに確認できる状態になっているはずです。他のレプリカのアプリケーション ログをチェックして、0x20 が受信されたかどうかを確認してください。
3. 他のレプリカから 0x10 が応答されたか ?
恐らく、この動作を確認するために集中して取り組むことになるでしょう。レプリカが削除保留中のレプリカから 0x20 を受信したにもかかわらず 0x10 で応答しないのは、他のレプリカが持たないデータが削除保留中のレプリカにあることを意味します。他のレプリカが 0x20 を受信したということは、そのレプリカは欠落しているデータがどれなのかもすでにわかっているということです。したがって、そのフォルダーからのバックフィル要求が 24 ～ 48 時間以内に届くことが予想できます。アプリケーション ログを調べて、前に説明した手順に従って通常のバックフィル プロセスと同じ方法でトラブルシューティングを行います。
4. 削除保留中のレプリカは 0x10 を受信したか ?
他のレプリカにすべてのデータが渡ると、そのレプリカは 0x10 で応答します。削除保留中のレプリカは、この 0x10 を受信すると、最終的にデータを削除しようとします。ただし、データがすぐに削除されるわけではありません。このレプリカを使用するクライアントがある場合は、後でオンライン メンテナンスが行われるときまでデータは削除されません。データをすぐに削除する必要があれば、ストアのマウントの解除とマウントを行ってクライアントを切断することによって、処理を早めることができます。
共通の問題
サーバーがなんらかの種類のレプリケーション メッセージを別のサーバーに送信したにもかかわらず、受信側サーバーがこの受信メッセージをアプリケーション ログに残さないケースがあります。ただし、メッセージ追跡で調べると、メッセージがそのサーバーのストアにローカルに配信されたことがわかります。このような動作は、通常、 レプリケーション 状態 テーブルに問題があるか、SMTP 仮想サーバーにアクセス許可の問題があることを示します。
簡単なケースから先に説明しましょう。受信側サーバーで受信レプリケーション メッセージが無視される原因の 1 つは、 レプリケーション 状態 (ReplState) テーブルの問題です。ReplState テーブルに問題があると、一部のフォルダーに関してバックフィル要求 (0x8) が発行されないという別の問題も発生するため、以下の説明はこの現象の解明にも役立ちます。各パブリック ストアでは、複製されたフォルダーのレプリケーション状態を追跡するために ReplState テーブルが使用されます。このテーブルには、フォルダーごとに複数の行があり、これらの行のそれぞれが 1 つのレプリカを表します。ReplState テーブルの行がレプリカ一覧と同期しておらず、行が多いことや少ないことがあります。レプリカ一覧からサーバーを削除し、この変更を適用した後で、すぐにそのサーバーをレプリカ一覧に戻すことによって同期を回復できることもありますが、常にこの方法で対処できるとは限りません。幸い、ReplState テストの機能が isinteg に追加されました。詳細については、KB889331 (Exchange 2003 の使用時) または KB892485 (Exchange 2000 の使用時) を参照してください。更新された isinteg.exe と store.exe があれば、isinteg を使用して ReplState テーブルの問題を修正できます。ReplState テストのみを実行するのであれば、短時間で操作は完了します。大きなパブリック ストアでも 1 分かかりません。isinteg を実行した後でも、場合によっては手順をさかのぼってフォルダーを変更して、ReplState テーブルをレプリカ一覧に同期させる必要があります。これらが同期すると、サーバーは受信レプリケーション メッセージを処理したりバックフィル要求を通常どおりに発行できるようになります。
受信レプリケーション メッセージが無視されるもう 1 つの共通の問題は、Exchange 2003 の使用時に限り発生します。Exchange 2003 では、送信元サーバーが受信側 SMTP 仮想サーバーの "送信者" 権限を持つことが要求されます。つまり、ServerA が Exchange 2003 であり、ServerB が PF レプリケーション メッセージを ServerA に送信すると仮定した場合、ServerB は ServerA の SMTP 仮想サーバーの "送信者" 権限を持つ必要があります。それ以外の場合、ServerA は受信レプリケーション メッセージを処理しません。このアクセス許可は、通常、Exchange Domain Servers グループを介して付与されます。この "送信者" 権限の問題があると、特定のサーバーからのすべての受信レプリケーション メッセージは無視されます。レプリケーション メッセージがサーバー間で転送される間にネットワーク トレースを実行すると、この問題は簡単に識別できます。このとき、サーバー間で交わされるのは次のようなやり取りです。
ServerA: 220 ServerA.microsoft.com Microsoft ESMTP MAIL Service...
ServerB: EHLO ServerB.microsoft.com
ServerA: 250-ServerA.microsoft.com Hello
250-TURN
250-SIZE
250-ETRN
250-PIPELINE
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-X-EXCH50
250 OK
ここで重要なのは、ServerA は GSSAPI NTLM LOGIN オプションを必ずアドバタイズすることです。これらのオプションが ServerA の EHLO への応答に見当たらなくても異常ではありません。統合 Windows 認証が SMTP 仮想サーバーで有効になっていないからです。これについては、KB843106 の手順 1. と KB842273 の手順 3. で言及されています。これらの認証の動詞が含まれる限り、以下のように ServerB がそれらを使おうとすることが確認できます。
ServerB: X-EXPS GSSAPI
ServerA: 334 GSSAPI supported
ServerB: <一連の base64 エンコード データ>
ServerA: 334 <その他の base64 エンコード情報>
ServerB: CRLF
ServerA: 235 2.7.0 Authentication successful.
正しく認証されなかった場合は、Kerberos の問題が発生したか、ServerB 用のコンピューター アカウントに問題があると考えられます。次に、サーバーはリンク情報情報をやり取りします。その後で、ようやく電子メールの転送に取りかかることができます。
ServerB: MAIL FROM:<ServerB-IS@microsoft.com>
ServerA: 250 2.1.0 ServerB-IS@microsoft.com....Sender OK
ServerB: RCPT TO:<ServerA-IS@microsoft.com> NOTIFY=NEVER
ServerA: 250 2.1.5 ServerA-IS@microsoft.com
ServerB: XEXCH50 2404 2
ServerA: 354 Send binary data
これが XEXCH50 動詞への最後の応答であり、重要なメッセージです。応答が "354 Send binary data" であれば、少なくとも SMTP 仮想サーバーへのアクセス許可に関しては、すべて順調だったとわかります。GSSAPI NTLM ログイン オプションがアドバタイズされなかったか、認証が失敗に終わった場合は、ServerA から "504 Need to authenticate" の応答があります。ここまでの手順が正しく完了したにもかかわらず、ServerA から "354 Send binary data" ではなく "504 Need to authenticate" の応答が返される場合は、ServerB が ServerA の SMTP 仮想サーバーの "送信者" 権限を持ちません。この状況が発生するシナリオは複数あります。たとえば、"Exchange 管理者 (完全)" などの権限を ESM で委任すると、そのユーザーまたはグループは "送信者" 権限の拒否を継承します。したがって、ESM を使用して管理者権限をコンピューター アカウントに委任すると、Exchange Domain Servers グループ、または Exchange Server が含まれるその他のグループは、パブリック フォルダーのレプリケーションを妨げます。別のシナリオとして考えられるのは、コンピューター アカウントが Exchange Domain Servers グループに含まれないことです。通常、コンピューター アカウントはこのグループに含まれることで "送信者" 権限を得ます。SMTP 仮想サーバーでのアクセス許可を評価し、送信元サーバー用のコンピューター アカウントが適切な権限を持たない原因を特定します。"504 Need to authenticate" 問題の詳細については、KB843106 および KB842273 を参照してください。
まとめ
この記事を読んで気付かれた方もおられるでしょうが、Exchange 2003 SP2 には、レプリケーションの問題が起こることを防止し、それらの問題のトラブルシューティングに役立つ重要な機能強化がいくつか含まれます。複数のパブリック ストアがある環境では、SP2 の導入によって多大なメリットが得られます。特に、サーバー間でレプリカを移動したりパブリック ストアの追加や削除を行うときに効果が顕著です。
この記事が皆様のお役に立てば幸いです。査読に協力していただいた Dave Whitney に感謝します。
これはローカライズされたブログ投稿です。原文の記事は、「Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems」をご覧ください。