パブリック フォルダーのレプリケーションのトラブルシューティング – パート 2: 既存のデータのレプリケーションのトラブルシューティング
原文の記事の投稿日: 2011 年 11 月 28 日 (月曜日)
US ブログへの最初の投稿日: 2006 年 1 月 20 日
このブログ投稿は、パブリック フォルダーのレプリケーション問題のトラブルシューティングに関する 2 番目のブログ投稿です。最初の投稿 (英語)では、新しい変更のレプリケーションのトラブルシューティングについて説明しました。このブログ投稿では既存のデータのレプリケーションのトラブルシューティングについて説明し、このシリーズの最後の投稿 (英語)では、レプリカの削除と共通の問題のトラブルシューティングについて説明します。全容を理解するには、すべての説明をお読みください。
既存のデータのレプリケーションのトラブルシューティング
新しい変更はレプリケートし、元からあって変更されなかったものはレプリケートしないと、バックフィルの問題が起こります。階層のバックフィルが発生する最も一般的な状況は、新しいパブリック ストアが作成される場合です。最も一般的なコンテンツのバックフィルのシナリオは、フォルダーのレプリカ リストにパブリック ストアが追加された場合です。
このようなバックフィルの問題が起きた場合、既に起きているかもしれませんが、簡単な対処法があります。すべてのアイテムを変更するのです。こうすることで、壊れたバックフィル プロセスを回避し、すべてのものを新しい変更としてレプリケートできます。通常、この目的で使用する両ツール (PFDAVAdmin および ModifyItems) を私自身が作成したのは事実ですが、一般には、バックフィル プロセスのトラブルシューティングを行い、根本的な原因を修正するのが最適です。すべてを変更してレプリケートする場合、レプリカが再び同期しなくなったときに、同じバックフィルの問題が繰り返される可能性があります。そこで、バックフィルの説明に移りましょう。バックフィル プロセスについて理解するには、最初に、変更の追跡方法について理解する必要があります。
ストア内のすべてのフォルダーとメッセージには、その作成時と変更のたびに変更番号 (CN) が割り当てられます。レプリケーションが発生すると、各オブジェクトの CN を使用して、そのオブジェクトをレプリケートする必要があるかどうかが判断されます。CN のグループを、変更番号セット (CNSet) と呼びます。特定のサーバー上の特定のフォルダーの CNSet を、ステータス情報と呼びます。このステータス情報は、すべてのレプリケーション メッセージに含まれます。すべてのメッセージ タイプ 0x2 には、送信側サーバーの階層ステータスが格納されています。同様に、すべてのメッセージ タイプ 0x4 には、送信側サーバーの特定のフォルダーのステータス情報が格納されています。他のすべてのレプリケーション メッセージ タイプにも、対応するフォルダーのステータス情報が格納されています。
新しいパブリック ストアが初めてマウントされると、階層のステータス要求 (タイプ 0x20) が既存のすべてのパブリック ストアに送信されます。同様に、フォルダーのレプリカ リストに新しいストアが追加されると、そのフォルダーの他のすべてのレプリカに 0x20 が送信されます。すべてのレプリケーション メッセージのように、ステータス要求には、元のストアが持つ該当のフォルダー (または階層) の、すべての CN から成る CNSet が含まれており、他のストアに対して、元のストアが持っていない CN を持っている場合は応答するように求めます。Exchange 2003 SP2 より以前は、すべてのレプリカがステータス要求への応答を求められることはなく、元のストアにない変更があっても、ステータス要求を無視するストアもありました。2003 SP2 サーバーはすべてのレプリカから応答を要求し、元のサーバーが具体的に要求していない場合であっても、元のサーバーにない変更がある場合は、応答します。このため、バックフィル プロセス時に行われる判断が大きく向上します。ステータス要求に関して注目すべき点は、これにはレプリケートするデータが含まれていないことです。含まれているのは、変更番号のリストだけです。他のストアはステータス メッセージ (0x10) で応答しますが、これは、同じフォルダー (または階層) の各自の CNSet のリストです。元のサーバーは、0x10 メッセージを受信すると、中に含まれている CNSet を自身の CNSet と比較します。持っていない変更が 0x10 に含まれている場合、バックフィル プロセスが開始します。
バックフィル プロセスの最初の手順では、問題になっているフォルダーのバックフィル配列にエントリを追加します。これらのエントリは、不足している変更を示す CNSet 、および、不足データをストアがいつ要求するかを示すタイムアウト値を持ちます。バックフィル タイムアウトは、状況に応じて異なります。新しいパブリック ストアがオンラインになる場合や、フォルダーの新しいレプリカが追加される場合、初期のタイムアウトは 15 分です。
通常の操作の過程でも、バックフィル エントリがバックフィル配列に追加されることがあります。あるパブリック ストアが、2 つの別々の 0x2 メッセージで 2 つの変更をブロードキャストする場合を考えてみましょう。管理者が最初の 0x2 メッセージをキューから削除しましたが、2 番目のメッセージは通過するものとします。他のサーバーがこの 0x2 を受信し、ステータス情報内の CNSet に、受け取ったことがない CN が含まれていることに気が付きます。そのため、そのデータのバックフィル エントリを作成します。レプリケーションの通常の過程で検出された不足データのバックフィル エントリは、データが同じルーティング グループ (RG) 内にある場合は 6 時間のタイムアウトで開始し、異なる RG 内にのみある場合は 12 時間のタイムアウトで開始します。バックフィル要求が送信されるたびに、次のタイムアウトは、RG 内要求の場合は 12 時間、次は 24 時間になり、RG 間要求の場合は 24 時間と 48 時間になります。
ストアは、5 分ごとに、バックフィル エントリがタイムアウトに達したかどうかを確認します。タイムアウトに達すると、不足している CN についてバックフィル要求 (タイプ 0x8) が送信され、タイムアウトが次の間隔に設定されます。バックフィル要求はブロードキャストではありません。宛先は単一のサーバーです。これは、要求サーバーに送信したステータス情報で不足している CN があることを以前に示した、サーバーの 1 つです。そのサーバーが 0x8 を受信すると、直ちに要求を処理し、1 つまたは複数のバックフィル応答 (階層の場合は 0x80000002、コンテンツの場合は 0x80000004) で応答します。これには、要求された変更番号の実際のデータが含まれています。バックフィル要求と同様、バックフィル応答もブロードキャストではありません。要求サーバーにのみ送信されます。
要求サーバーが、受信したバックフィル応答を正しく処理すると、含まれていた CN はそのストア上のバックフィル配列からクリアされます。実際、受信メッセージに、バックフィル配列内の未処理の CN が含まれていると、その CN は配列からクリアされます。
トラブルシューティング
ご覧のように、バックフィル プロセスをトラブルシューティングするには、多くの問いに答えていく必要があります。
1. ストアはデータが不足していることを理解していますか?
要求する必要がある変更を他のストアが持っていることをサーバーが理解しているかどうかを、最初に判断する必要があります。残念ながら、バックフィル配列を直接表示して、そこに何があるかを確認できるサポート ツールやユーティリティはありません。しかし、これを把握する間接的な方法はいくつかあります。
1 つの方法は、待つことです。データが不足していることをサーバーが理解していれば、少なくとも 24 時間または 48 時間に 1 回は要求が行われます。つまり、ログを調べて、0x8 メッセージが送信されたかどうかを確認するのです。該当のフォルダーの 0x8 が確認できず、しかし、他のフォルダーの 0x8 が確認できた場合は、未処理バックフィル制限に達した可能性があります。これについては、後述します。
もう 1 つの方法は、サーバーに最新のステータス情報を確実に受信させることです。サーバーは、新しいレプリカを追加した後に 1 回のみ、ステータス要求を送信します。その後、受信した唯一のステータス情報が、通常のレプリケーションの過程で使用されます。応答内の 0x20 または 0x10 が失われていたり、削除されたために、ステータスを取得しようとした最初の試みが失敗すると、その状態がいつまでも続き、場合によってはデータが不足していることを理解していない可能性があります。サーバーにフォルダーのステータス情報を確実に受信させるには、さまざまな方法があります。
- すべてのデータを持つサーバーに移動し、メッセージを追加、削除、または変更して、フォルダーを変更します。階層の場合は、フォルダーのプロパティを作成、削除、または変更します。その結果として生じる 0x4 または 0x2 には、該当のフォルダーまたは階層のステータス情報がそれぞれ含まれます。データが不足しているサーバーが、受信したレプリケーション メッセージを正常に処理すると、適切なエントリがバックフィル配列に追加されます。
- Exchange 2003 ESM の [コンテンツの同期] オプションを使用します。これはなかなか見つけにくいのですが、非常に役立つオプションです。このオプションを見つけるには、[パブリック フォルダー] ツリーの下に移動し、目的のフォルダーに移動します。左側のウィンドウでフォルダーを強調表示し、右側のウィンドウで [ステータス] タブをクリックします。すべてのデータを持っているサーバーを右クリックし、[コンテンツの同期] を選択します。これによって、2 つのことが行われます。サーバーはフォルダーのステータス要求 0x20 を送信し、すべてのバックフィル エントリが即時にタイムアウトされます。ここで、既にデータを持っているサーバーから [コンテンツの同期] を実行すると述べたことに注目してください。タイムアウトする必要があるバックフィル エントリを持っているのは別のサーバーなのに、なぜこのような操作を行うのか、疑問に思われるかもしれません。この時点では、データが不足しているサーバーに、バックフィルするものがあることを理解させているに過ぎません。そのために、データを持っているサーバーから [コンテンツの同期] を使用して、データを持っていないサーバーに 0x20 を送信するのです。ここでは、0x20 に対するステータス 0x10 応答の確認は、あまり問題ではありません。コンテンツが不足しているストアが、コンテンツを持つストアからフォルダーのレプリケーション メッセージを受信し、適切なエントリをバックフィル配列に追加できることが重要です。データを持つサーバーからの 0x20 が、この役割を担います。Exchange 2003 SP2 では、[パブリック フォルダー] ノード自体を右クリックすることで、階層について [コンテンツの同期] を使用できます。
- Replication Flags レジストリ値 (KB813629) を使用します。この値と、KB321082 (英語) に記載されている Enable Replication Messages At Startup 値を適切に設定すると、ストアは、スタートアップ時にすべてのフォルダーについてステータス要求 0x20 を送信します。この場合も、コンテンツを持つサーバーでこの操作を行う必要があります。この手順のポイントは、コンテンツを持つサーバーが、そのステータス情報を、コンテンツが不足しているサーバーに送信することです。
- 2003 ESM を使用して、バックフィル応答を送信します。2003 SP1 では、[階層の送信] オプションを使用して階層のバックフィル応答を送信し、[コンテンツの送信] オプションを使用してフォルダー コンテンツのバックフィル応答を送信できました。2003 SP2 では、この 2 つのオプションが、[変更内容の再送信] になりました。このオプションは、指定するデータ範囲のバックフィル応答を送信します。ただし、データ範囲全体を指定すべきではないでしょう。その場合、未処理のバックフィル エントリがすべて該当し、元の問題の対処に終始することになるためです。代わりに、1 日または 2 日のみの範囲を指定します。これによって 0x80000002 または 0x80000004 がターゲット サーバーに送信され、ここでも、データを持つストアのステータス情報を与えるという役割が果たされます。
上記の方法のいずれかを使用してステータス情報を強制的に送信し、データが不足しているストアがメッセージを受信したことをアプリケーション ログで確認できれば、データの不足を理解していることになります。
2. ストアが不足データを要求していますか?
データをバックフィルする必要があることをストアに理解はさせましたが、では、バックフィル要求は送信されているでしょうか。データのバックフィルが何回か行われると、次のバックフィル要求まで、24 時間または 48 時間待機しなければならない可能性があります。この値はそれぞれ、サイト内バックフィルおよびサイト間バックフィルの最長のタイムアウト間隔です。これをスピードアップする方法が 1 つあります。前述の [コンテンツの同期] を使用するのですが、今回は、データが不足しているサーバーからこれを使用します。これにより、そのフォルダーのバックフィル エントリが即時にタイムアウトします。しかし、それでも、目的のフォルダーのバックフィル要求をストアが送信しない場合があります。その場合は、次の 24 ～ 48 時間のアプリケーション ログを調べます。ストアが他のフォルダーのバックフィル要求は送信するのに、目的のフォルダーのバックフィル要求は送信しない場合は、未処理バックフィル制限に達した可能性があります。
多数のフォルダーのレプリカを新しいストアに追加した場合、レプリケーションが最初は順調でも、1 日か 2 日経つと動作しなくなる場合は、未処理バックフィル制限に達している可能性があります。未処理バックフィル制限とは、レプリケーションの調整を目的とするメカニズムです。既定では、ストアが許可する未処理のバックフィル要求は一度に 50 のみです。50 件 の未処理があると、解決されるまで、その 50 件が繰り返し再要求されます。1 つの未処理エントリが解決されると、OBL 内のスロットが解放され、新しいデータ セットが要求されます。つまり、50 件の要求が何らかの理由でその解決に問題がある場合、レプリケーションが処理されません。
このような状態になった場合は、アプリケーション ログを調べて、ストアが何を要求しているかを確認してください。現在の 50 件の未処理のバックフィル要求について 0x8 メッセージが断続的にあり、バックフィル応答は受信していない場合、それが未処理の原因です。その時点で、ストアが現在バックフィルを試みているフォルダーの 1 つをトラブルシューティングすることに、意識を変える必要があります。その問題を解決することで、他のフォルダーに進むことができます。
もう 1 つの方法は、未処理バックフィル制限 (OBL) を増やすことです。これは、該当のストアのレジストリ キーの下に、Replication Oustanding Backfill Limit という名前のレジストリ値を作成することによって行うことができます。最大値は 5000 (10 進) です。ただし、これを行うと、レプリケーションの歯止めが解かれ、問題を引き起こした 50 フォルダーを決定するのが困難になります。状態が再び落ち着くまで、トラブルシューティングを先延ばしにする必要があるでしょう。一般には、制限値を増やして対処するよりも、制限値は 50 のままにして問題を修正することをお勧めします。
OBL が問題とは思えない場合、および、問題となっているフォルダーの送信 0x8 メッセージがやはりない場合は、このシリーズの最後の投稿 (英語)の「共通の問題」を参照してください。
3. 他のストアが要求に応答していますか?
バックフィル要求に注目したら、バックフィルのターゲットが要求を受け取ったかどうかを判断する必要があります。そのサーバーのアプリケーション ログで、受信した 0x8 を確認します。アプリケーション ログで、送信側からの送信イベントに示されているメッセージ ID を検索することもできます。アプリケーション ログに記録がない場合は、メッセージ追跡を使用して、その行方を確認します。0x8 を受け取った場合は、1 つ以上の 0x80000002 メッセージまたは 0x80000004 メッセージでほぼ即時に応答する必要があります (多くの場合、1 つのバックフィル要求に対して複数のバックフィル応答が存在します。これは、変更がすべて 1 つのメッセージで送信されるとは限らないからです)。もちろん、バックフィル応答メッセージを生成するのにかかる時間は、フォルダー内のデータとレプリケーション メッセージのサイズ制限によって異なります。たとえば、レプリケーション メッセージの最大サイズが 1 GB に設定されている場合、応答サーバーは階層全体を 1 つのバックフィル応答にまとめようとするため、まとめるだけで 1 時間以上かかる可能性があります。
4. 要求サーバーが応答を受け取っていますか?
次に、要求サーバーのアプリケーション ログで、バックフィル応答を受信したかどうかを調べます。受信していない場合は、メッセージを追跡して、その行方を確認します。バックフィル応答を受信しており、アプリケーション ログに記録されている場合、バックフィル要求は対処されており、次に進むことができるはずです。
前述のように、メッセージ追跡ではこれらのメッセージの 1 つがストアに送信されたことが示されているのに、アプリケーション ログにはレプリケーション メッセージの受信の記録がない場合は、このシリーズの最後の投稿 (英語)の「共通の問題」を参照してください。
次回のブログ投稿は、「レプリカの削除と共通の問題のトラブルシューティング (英語)」です。
これはローカライズされたブログ投稿です。原文の記事は、「Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data」をご覧ください。