パブリック フォルダーのレプリケーションのトラブルシューティング – パート 1: 新しい変更のレプリケーションのトラブルシューティング
原文の記事の投稿日: 2011 年 11 月 28 日 (月曜日)
US ブログへの最初の投稿日: 2006 年 1 月 17 日
注: このブログ投稿は、パブリック フォルダーに関するトラブルシューティング シリーズの第 1 回です。同シリーズのパート 2 (英語)、パート 3 (英語)、およびパート 4 (英語) もご覧ください。
はじめに
このブログ記事は、パブリック フォルダーのレプリケーションの問題に関するトラブルシューティング ガイドを提供することを目的としています。発生する可能性のあるあらゆるレプリケーション関連問題の解決方法を示すものではありません。ここでは、発生する可能性のあるレプリケーション関連問題の発生源を集中的にトラブルシューティングできるように、問題箇所を特定する方法について説明します。たとえば、「古いサーバーの内容が新しいサーバーにレプリケートされない」という問題の記述を、「新しいサーバーからのステータス要求に古いサーバーが応答しないので、新しいサーバーはデータの欠落を認識せず、バックフィルを試行しない。つまり、問題の原因は古いサーバーにある」という記述にまで絞り込めるようにすることを目的としています。また、特に発生しやすいレプリケーション関連問題の見分け方についても説明します。トラブルシューティングの詳しい説明に進む前に、まず、このような問題への全般的アプローチについて概要を説明します。
パブリック フォルダーのレプリケーションのトラブルシューティングに最も役立つツールはアプリケーション ログです。レプリケーション関連の問題を特定するには、ログでレプリケーション イベントを追跡して、プロセスにおける問題発生場所を正確に知る必要があります。通常、トラブルシューティングはまず、レプリケーション受信 (Replication Incoming) およびレプリケーション送信 (Replication Outgoing) の診断ログを [最大] に設定して開始します。ストアがレプリケーション メッセージを送信または受信するたびに、そのイベントがログに記録されます (ログ記録を設定した場合)。レプリケーション メッセージのさまざまな種類は、イベント記述の "種類" で区別できます。次のような理由から、イベント ID より種類に注目します。
- イベント ID は Exchange のバージョンごとに異なります。たとえば、Exchange 5.5 では送信バックフィル要求のイベント ID は 3014 でした。Exchange 2000 および 2003 では 3016 です。
- 受信と送信のイベント ID は種類ごとに異なります。送信階層メッセージのイベント ID は 3018 ですが、受信階層メッセージのイベント ID は 3028 です。
- ステータス要求とステータス メッセージはそれぞれ別の種類のメッセージですが、どちらにも同じイベント ID が使用されます。つまり、イベント ID だけではこの 2 つを区別できません。
種類に注目すると、少し簡単になります。関連するイベント ID はアプリケーション ログで簡単に調べることができます。種類は 7 つのみであり、送信メッセージと受信メッセージの区別はイベントのカテゴリで確認できます。イベント ID より種類に注目する場合は、次のものを覚えるだけで済みます。
階層 - 0x2
内容 - 0x4
バックフィル要求 - 0x8
バックフィル応答 - 0x80000002 (階層) または 0x80000004 (内容)
ステータス - 0x10
ステータス要求 - 0x20
また、レプリケーション エラー (Replication Errors) のログ記録はあまり有用ではありません。ほとんどのサーバーでは、レプリケーションが正常に動作していても多くのレプリケーション エラー イベントが生成されます。たとえば、プロパティの読み取り時にエラーがあったことを示すイベント ID 3093 などです。ほとんどの場合、プロパティはレプリケーションに影響しないので、このエラーは無視できます。以前のこちらのブログ記事 (英語)で説明しているような特定の問題を調べる場合を除き、レプリケーション エラーのログ記録は [なし] にすることをお勧めします。
新しい変更のレプリケーションのトラブルシューティング
パブリック フォルダーのレプリケーションのトラブルシューティングを行うには、まず、レプリケーションの正常動作時のメッセージ フローをよく把握している必要があります。その知識に基づいて問題の発生場所を特定できます。新しい変更のトラブルシューティングについて説明する前に、まず、正常動作について説明します。
階層のレプリケーション
階層の新しい変更のレプリケーションが実行されるのは、フォルダーの作成または削除、あるいはパブリック フォルダーのプロパティ (レプリカ一覧、クライアントのアクセス許可、説明、管理メモ、格納域の制限など) の変更が行われたときです。電子メールが有効なフォルダーの電子メール アドレスは、これに含まれないので注意してください。電子メール アドレスは Active Directory のディレクトリ オブジェクトに格納されるので、これを変更しても階層のレプリケーションは実行されません。階層のレプリケーションが実行されるのは、パブリック ストア自体に格納されているプロパティが変更されたときのみです。
フォルダー プロパティの変更は、(既定では) 15 分ごとに、ストアから 1 つまたは複数の階層レプリケーション メッセージでブロードキャストされます。レプリケーション送信 (Replication Outgoing) のログを [最大] に設定している場合、階層が変更されたサーバーでは次のようなイベントが記録されます。
イベントの種類: 情報
イベント ソース: MSExchangeIS パブリック ストア
イベント カテゴリ: Replication Outgoing Messages
イベント ID: 3018
説明:
送信レプリケーション メッセージが発行されました。
種類: 0x2
メッセージ ID: <91ACCD0758385549A56A10971798985572D5@bilongexch1.bilong.test>
データベース "First Storage Group\Public Folder Store (BILONGEXCH1)"
CN 最小: 1-72CF、CN 最大: 1-72D3
RFI: 1
1) FID: 1-6994、PFID: 1-1、オフセット: 28
IPM_SUBTREE\NewFolder
説明の最初にある "種類: 0x2" は、これが階層レプリケーション メッセージであることを示しています。
階層レプリケーション メッセージは、元のサーバーから他のすべてのパブリック ストアに直接送信されます。新しい変更のレプリケーションにトポロジの概念はありません。階層の変更はすべて、変更が行われたサーバーから、同じ階層に関連付けられているパブリック ストアを持つ他のすべてのサーバーへ直接送信されます。他のすべてのサーバーでは、受信レプリケーション メッセージが正常に処理されたときに種類 0x2 を示す受信イベントのログが記録されます。
内容のレプリケーション
内容のレプリケーションが実行されるのは、メッセージの作成または削除、あるいはメッセージのプロパティの変更が行われたときです。ストアがフォルダーの内容の変更をブロードキャストする時間は、そのフォルダーのレプリケーション スケジュールで変更できますが、既定では、階層の場合と同様、15 分ごとに変更がブロードキャストされます。内容レプリケーション メッセージは、イベント記述で種類 0x4 として示されます。この場合も、新しい変更のブロードキャストにトポロジの概念はありません。いずれかのレプリカでフォルダーの内容が変更されると、そのレプリカから 0x4 メッセージがそのフォルダーの他のすべてのレプリカに直接送信されます。そしてこの場合も、すべての受信サーバーでは、受信メッセージが正常に処理されたときに 0x4 受信イベントのログが記録されます。
トラブルシューティングの手順
レプリケーションの最も基本的なシナリオは 2 種類あります。階層または内容の新しい変更が、あるサーバーから別のサーバーへ反映されない場合、トラブルシューティングは単純です。
1. サーバーは送信レプリケーション メッセージを生成したか
たとえば、フォルダーに変更を加えた場合、または特定のサーバーのフォルダーに内容を追加した場合、その内容が他のサーバーに反映されなかったとします。最初に確認することは、その対象サーバーから変更がブロードキャストされていたかどうかです。トラブルシューティングを行うときは、変更時にどのサーバーで作業していたかを追跡することが重要です。これを調べるにはいくつかの方法があります。ESM では、パブリック フォルダーのノードを右クリックし、[接続先] をクリックして特定のストアを指定します。ほとんどの場合、指定したストアに対して変更が行われますが、クライアントのアクセス許可だけは例外です。Exchange 2003 SP2 より前のバージョンでは、クライアントのアクセス許可を変更した場合、アクセス許可は階層内のフォルダーのプロパティとして格納されてレプリケーションは不要であるにもかかわらず、ESM はフォルダーのレプリカが格納されているストアに変更を行おうとします。ESM 2003 SP2 ではこの動作が変わり、指定した階層に変更が行われます。2003 SP2 以降の ESM を使用しない限り、クライアントのアクセス許可の変更がどのストアに対して行われるか予測できないので、ESM で変更を加えて階層のレプリケーションをテストする場合は、クライアントのアクセス許可を使用しないようにしてください。Outlook を使用している場合にフォルダーのどのレプリカが対象であるか確認するには、MFCMAPI などのツールを使用してフォルダーの PR_REPLICA_SERVER プロパティを調べます。このプロパティは、Outlook がそのフォルダーの内容にアクセスするために使用するサーバーの名前を示します。
問題のフォルダーのレプリケーション スケジュールが [常に] に設定されており (階層の場合は常にこの設定になります)、送信 0x2 または 0x4 が 15 分間発生していない場合は、元のサーバーに問題があることを意味しています。サーバーから送信階層ブロードキャストまたは送信内容ブロードキャストが生成されない場合は、レプリケーション エージェントが開始に失敗している可能性があります。よくあるシナリオの 1 つは、KB272999 で説明されているシナリオです。この場合、次のような 3079 イベントに注意してください。
イベント ID: 3079
ソース: MSExchangeIS パブリック
種類: エラー
カテゴリ: Replication Errors
説明:
予期しないレプリケーション スレッド エラー 0x3f0 が発生しました。
EcGetReplMsg
EcReplStartup
FReplAgent
このイベントは、パブリック ストアのマウント時に追加ログ記録を設定していなくても記録されます。3079 に "EcReplStartup" が含まれている場合は、レプリケーション エージェントが開始に失敗しており、問題を解決してストアをマウントし直さないと新しい変更はブロードキャストされないことを示しています。
階層のレプリケーションの場合も、組織に Exchange 5.5 パブリック ストアがあると、アクセス許可の問題が発生する可能性があります。Exchange 2000 または 2003 のサーバーは、Exchange 5.5 サーバーに階層レプリケーション メッセージを送信するとき、ptagNTSD プロパティ (2000 形式の SID ベースのアクセス許可) から ptagACLData プロパティ (5.5 形式の legacyExchangeDN ベースのアクセス許可) を生成する必要があります。つまり、各 SID を legacyExchangeDN に変換する必要があります。SID から legacyExchangeDN へのこの変換は、いくつかの原因によって失敗することがあります。たとえば、1 つの SID が複数のユーザーに該当する場合、次のようなイベントが発生することがあります。
イベント ID: 9528
カテゴリ: General
ソース: MSExchangeIS
種類: エラー
説明:
DS 内の 2 人のユーザーから SID S-1-5-21-408248388-469072634-37170099-1391 が見つかったため、この SID を一意なユーザーにマップすることができません。
次のユーザーが含まれます:
/DC=com/DC=company/CN=Users/CN=User1
/DC=com/DC=company/CN=Users/CN=User2
この場合、SID を legacyExchangeDN に変換できず、ストアは送信階層ブロードキャスト メッセージの生成に失敗します。
2. 変更を受信しなかったサーバー宛にメッセージが送信されているか
元のサーバーで送信メッセージが生成されていた場合、次のステップは、データを受信しなかったサーバーにそのメッセージが送信されていることを確認します。これを確認する最も簡単な方法は、メッセージを追跡することです。メッセージ追跡では、送信レプリケーション イベントでレポートされたメッセージ ID を追跡します。[メッセージの履歴] ウィンドウに表示される [宛先] 行を確認します。変更を受信しなかったストアがここに表示されていない場合は、元のサーバーに問題があると考えられます。元のサーバーは組織のそのサーバーを参照していますか。そのサーバーではパブリック ストア オブジェクトに電子メール アドレスを格納していますか。元のサーバーでは、問題のフォルダーのレプリカ一覧でそのストアを指定していますか。
3. メッセージは配信先サーバーに届いたか
メッセージが配信先サーバー宛に送信されていることを確認したら、次に確認することは、メッセージがそのサーバーに届いたかどうかです。これはメッセージ追跡で確認できます。メッセージ追跡ではメッセージがそのストアへ配信されたことが示されているのに、メッセージを確認したという受信レプリケーション イベントが記録されていない場合、このシリーズの最終回の記事 (英語)の「共通の問題」を参照してください。
次回のブログ投稿は「既存のデータのレプリケーションのトラブルシューティング (英語)」です。
これはローカライズされたブログ投稿です。原文の記事は「Public Folder Replication Troubleshooting ? Part 1: Troubleshooting the Replication of New Changes」をご覧ください。