パブリック フォルダのレプリケーションについて

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2008-07-14

パブリック フォルダのレプリケーションは、効率とフォールト トレランスの目的で、パブリック フォルダの内容とパブリック フォルダ階層が複数のサーバーにわたってレプリケートされる処理です。別のサーバーにある複数のパブリック フォルダ データベースで 1 つのパブリック フォルダ ツリーをサポートしている場合、Microsoft Exchange はパブリック フォルダのレプリケーションを利用してデータベースの同期を維持します。パブリック フォルダの内容は、特定のフォルダのレプリカを持つように構成された Exchange ストアにのみ存在します。内容と階層の情報は別々にレプリケートされます。各パブリック フォルダ データベースは階層のコピーを保持し、これには各フォルダの内容のレプリカを保持する他のパブリック フォルダ データベースの一覧が含まれています。内容のレプリカは、指定したパブリック フォルダ データベース上にのみ存在します。パブリック フォルダのレプリケーションを構成する方法の詳細については、「パブリック フォルダ レプリケーションを構成する方法」を参照してください。

パブリック フォルダ データベースは、次の 2 種類のパブリック フォルダ情報をレプリケートします。

  • 階層   階層のレプリケーションは、フォルダのプロパティやフォルダに関する組織上の情報が変更されたときに行われます。すべてのパブリック フォルダ データベースが階層情報のコピーを持ちます。以下のパブリック フォルダ情報を変更すると、階層のレプリケーションが発生します。

    • フォルダ名
    • レプリカ一覧
    • パブリック フォルダ ツリー内でのフォルダの位置 (すべての親フォルダと子フォルダを含む)
    • アクセス許可
      note注 :
      階層のレプリケーションは、メールが有効なパブリック フォルダの電子メール アドレスを変更したときには発生しません。電子メール アドレスは Active Directory ディレクトリ サービスのディレクトリ オブジェクトに格納されます。パブリック ストア データベース内のプロパティが変更された場合のみ、階層のレプリケーションが行われます。
  • 内容   内容のレプリケーションは、メッセージがパブリック フォルダに送信されたときや、データが追加されたときに行われます。たとえば、メールが有効なパブリック フォルダに電子メール メッセージを送信した場合や、パブリック フォルダに組織フォームを追加した場合に内容のレプリケーションが発生します。内容をレプリケートするには、特定のパブリック フォルダ データベースまたはデータベースの一覧に内容をレプリケートするようにフォルダを構成する必要があります。指定したデータベースのみが、内容のコピーを持つことになります。内容を含むフォルダのコピーは、"内容のレプリカ" と呼ばれます。

パブリック フォルダのレプリケーションの動作

パブリック フォルダまたはそのフォルダの内容を変更すると、変更されたパブリック フォルダのレプリカが含まれるパブリック フォルダ データベースから、そのパブリック フォルダのレプリカをホストする他のパブリック フォルダ データベースに、変更内容を示す電子メール メッセージが送信されます。ネットワークのトラフィックを削減するため、Exchange は複数の変更に関する情報を 1 つの電子メール メッセージに含めます。これらのメッセージに含められる情報の量は、レプリケーション メッセージに対して設定したサイズ制限に応じて変化します。メッセージのサイズが指定した制限を超えると、そのメッセージは個別のレプリケーション メッセージとして送信されます。Exchange は、他の電子メール メッセージをルーティングする場合と同じ方法でこれらのレプリケーション メッセージをルーティングします。パブリック フォルダのルーティングの詳細については、「パブリック フォルダへのメッセージのルーティング」を参照してください。

いくつかのフォルダに影響を与えるパブリック フォルダ階層を変更した場合は、レプリケーション処理に非常に多くのネットワーク帯域幅が必要になることがあります。たとえば、サーバー間でパブリック フォルダを移動するには、パブリック フォルダの移動先のサーバーに新しいレプリカを作成し、階層の変更が元のサーバーにレプリケートされるのを待ち、それから内容が新しいレプリカにレプリケートされるのを待つ必要があります。レプリカが同期されたら、古いサーバーからレプリカを削除する必要があります。レプリカの削除は階層の変更としてレプリケートされる必要があるため、古いサーバーからレプリカを削除することからもネットワーク トラフィックが生成されます。パブリック フォルダ階層に対するこれらの変更がシステムに与える影響の詳細については、このトピックの「状態要求と状態メッセージ」を参照してください。

階層と内容の基本的なレプリケーション処理

次の図とその後の説明文で、パブリック フォルダの階層と内容がレプリケートされる基本的な処理について説明します。

パブリック フォルダーのレプリケーションの基本的な処理

この処理の詳細は、以下のとおりです。

  1. ユーザーがパブリック フォルダを変更します。
  2. ローカルのパブリック フォルダ データベースに変更が記録されます。
  3. パブリック フォルダ データベースに対して設定したレプリケーション間隔によって決定される、次に予定されているレプリケーション周期で、パブリック フォルダ データベースはフォルダのプロパティを調査し、そのフォルダのレプリカを格納している他のサーバーを特定します。他のレプリカが存在する場合、データベースはどの情報をレプリケートする必要があるかを特定します。この情報がレプリカに対する更新になります。
    パブリック フォルダのレプリケーションはオブジェクト ベースです。オブジェクトの 1 つのプロパティが変更された場合は、オブジェクト全体をレプリケートする必要があります。変更をレプリケートするデータベースでは、受け取るレプリカのすべてが最新のものであると見なせないため、オブジェクト全体をレプリケートする必要があります。それぞれの種類のレプリケーションでは、以下を意味することになります。
    • 階層のレプリケーション   パブリック フォルダが作成または削除されたときや、パブリック フォルダのプロパティが変更されたとき (レプリカ一覧、クライアントのアクセス許可、説明、管理上のメモ、または格納域の制限に対する変更など) に、新しい階層の変更のレプリケーションが行われます。
    • 内容のレプリケーション   新しいメッセージが投稿されたり既存のメッセージが変更された場合、メッセージ全体とメッセージのプロパティが更新に含められます。
  4. パブリック フォルダ データベースが更新に変更番号を割り当てます。
    フォルダが更新を別のサーバーにレプリケートするときは、この変更番号が更新に含められます。受信側サーバーは次に、変更番号を使用して、更新が新しい変更を表しているかどうかを特定し、足りないデータがあるかどうかを確認します。
  5. パブリック フォルダ データベースは更新をレプリケーション メッセージにパックします。メッセージに含まれるすべての更新の変更番号が、"変更番号セット" (CNSet*)* と呼ばれます。
    パブリック フォルダ データベースは更新と一緒に、レプリケーション状態テーブル内に格納されているフォルダのエントリから得られる、レプリカに以前適用された CNSet などの情報をパックします。レプリケーション状態テーブルの詳細については、このトピックの「レプリケーション状態テーブル」を参照してください。
  6. メール トラフィックを削減するため、パブリック フォルダ データベースは複数の階層の更新を 1 つのレプリケーション メッセージにパックします。同様に、同じフォルダに対する複数の内容の更新を 1 つのレプリケーション メッセージにパックします。ただし、階層の更新を内容の更新と同じレプリケーション メッセージにパックすることはできないので、それぞれの内容のレプリケーション メッセージには 1 つのフォルダについての更新が含まれます。
  7. パブリック フォルダ データベースは、レプリケーション メッセージの宛先を、更新されたフォルダのレプリカをホストする他のパブリック フォルダ データベースにします。そして、前のレプリケーション周期以降にパックされた他のメッセージと共に、このメッセージを送信します。
    レプリケーション メッセージを配信するため、パブリック フォルダ データベースは Exchange の内部ルーティング コンポーネントを利用します。データベースはトポロジの詳細に基づいてレプリケーション メッセージを分割しようとはしません。フォルダの内容が変更され、そのフォルダには他のレプリカが 5 つある場合、データベースは 1 つのレプリケーション メッセージを生成し、これらのレプリカをホストする 5 つのデータベースすべてをメッセージの宛先にします。ルーティング コンポーネントがメッセージのルーティングおよび配信の方法を決定します。
  8. パブリック フォルダ データベースがレプリケーション メッセージを受信します。
  9. 受信側のパブリック フォルダ データベースは、レプリケーション メッセージから更新と状態情報をアンパックします。
  10. データベースは、新しい更新の変更番号を、格納済みの変更番号の一覧と比較し、以前に受信していない更新を識別します。
  11. データベースは、新しい更新を適切なフォルダのレプリカに適用します。
  12. 更新されたレプリカごとに、現在の更新の変更番号とレプリケーション メッセージからのフォルダ状態情報に基づいて、レプリケーション状態テーブルが更新されます。
    レプリケーション状態テーブルの情報から、他の CNSet がフォルダの他のレプリカに適用されたのに、このデータベースのレプリカには適用されていないことがわかると、データベースは足りない CNSet を "バックフィル配列" と呼ばれる場所に記録し、バックフィル要求を送信する準備をします。バックフィル要求の詳細については、このトピックの「バックフィル要求とバックフィル メッセージ」を参照してください。

レプリケーション メッセージ

レプリケーション処理では、個々のパブリック フォルダの Active Directory 属性ではなく、パブリック フォルダ データベースの Active Directory 属性が使用されます。個々のパブリック フォルダの Active Directory 属性は、フォルダとの間で通常の電子メール メッセージを送受信するためにのみ使用されます。パブリック フォルダ データベース オブジェクトは自動的に構成されて保持され、Active Directory の構成コンテナに置かれます。

レプリケーション メッセージは他の電子メール メッセージとは異なり、Exchange ではシステム メッセージとして扱われます。このため、レプリケーション メッセージはユーザーの電子メール メッセージに適用される制限 (サイズ制限や配信制限など) を受けません。

次の表に、Exchange で使用されるさまざまな種類のレプリケーション メッセージの一覧を示します。

note注 :
次の表のかっこ内に示されている値は、メッセージの種類の 16 進表記です。これらの表記はイベントとログで使用されます。16 進数の値は、レプリケーションの問題をトラブルシューティングするために利用できます。

パブリック フォルダのレプリケーション メッセージの種類と用途

メッセージの種類 * 用途

階層 (0x2)

ローカルのパブリック フォルダ データベースから、同じ階層をサポートする他のすべてのパブリック フォルダ データベースに階層の変更をレプリケートします。Exchange は、階層の変更を内容のレプリカの変更とは別に処理しますが、階層は別種のフォルダであるかのように扱われます。一部のイベント メッセージや他の操作では、Exchange は階層を Folder 1-1 として参照します。

内容 (0x4)

1 つのレプリカから、そのフォルダを対象にしている他の内容のレプリカすべてに内容の変更をレプリケートします。内容のメッセージには、1 つのフォルダに適用される情報のみが含まれます。

バックフィル要求 (0x8)

別のデータベースの CNSet 内にある、不足しているデータを要求します。このメッセージには、階層と、内容の変更番号が含まれます。

バックフィル応答 (0x80000002 または 0x80000004)

行われなかった更新を要求しているデータベースに、CNSet 内の不足しているデータを送信します。

状態 (0x10)

特定のフォルダの現在の CNSet を、そのフォルダの 1 つ以上のレプリカに送信します。このメッセージには、階層と、内容の変更番号が含まれます。

状態要求 (0x20)

レプリケートする必要がある CNSet または返す必要がある状態メッセージを要求します。このメッセージには、階層と、内容の変更番号が含まれます。

レプリケーション状態テーブル

各パブリック フォルダ データベースは、レプリケーション状態テーブルを保持してデータベース内の各レプリカの状態を追跡します。レプリケーション状態テーブルには、以下の情報が格納されます。

  • 各レプリカに対する更新を作成するために必要な基本的な情報。
  • ローカル データベースで発生した、各レプリカに対する最後の更新に関する情報。更新の変更番号も含まれます。
  • フォルダの他の既知のレプリカすべてに適用された更新のグループ。変更番号によって各グループ内の更新が識別されます。グループ内のすべての更新を表す変更番号のセットは CNSet と呼ばれます。更新情報は、レプリケーション処理の一部として、1 つのデータベースから別のデータベースに渡されます。

次の表に、レプリケーション状態テーブルがどのように機能するかの例を示します。この例では、サーバー A とサーバー B の両方のパブリック フォルダ データベースに、Projects という名前のフォルダのレプリカがあります。各サーバーのレプリケーション状態テーブルでは、そのサーバー上にあるレプリカの状態だけでなく、他のサーバー上にあるレプリカの状態も追跡されます。この情報を使用して、サーバー A は Projects フォルダのレプリカが、サーバー B 上にある Projects フォルダのレプリカと同期されているかどうかを特定します。サーバー B は同様に、サーバー A と比較してレプリカの状態を追跡します。

サーバー A のレプリケーション状態テーブルのサンプル データ

レプリカ データ

サーバー A 上にある Projects フォルダ

(ローカル レプリカ)

最後に送信した更新 : A-100

サーバー B 上にある Projects フォルダ

受信した A-100

受信した B-50

サーバー B のレプリケーション状態テーブルのサンプル データ

レプリカ データ

サーバー A 上にある Projects フォルダ

受信した A-100

受信した B-50

サーバー B 上にある Projects フォルダ

(ローカル レプリカ)

最後に送信した更新 : B-50

各パブリック フォルダ データベースでは、内容のレプリカが含まれるパブリック フォルダ データベースの一覧と、レプリケーション状態テーブルの情報を組み合わせることで、パブリック フォルダ ツリーをサポートする他のパブリック フォルダ データベースと比較して、そのデータベースがどれだけ最新の状態になっているかを特定することができます。

バックフィル要求とバックフィル メッセージ

バックフィルは、パブリック フォルダ データベースで、レプリケート対象のフォルダ (または階層) の更新をすべて受信していないため、不足している更新を別のパブリック フォルダ データベースから取得する必要があると判断されたときに発生します。

バックフィル処理を効率化するため、Exchange 2007 は不足している更新に関する情報をバックフィル配列に格納します。

以下のイベントは、パブリック フォルダ データベースにとって、バックフィル処理が必要な足りない更新があることの警告になる場合があります。

  • 受信レプリケーション メッセージの状態情報が、メッセージを送信したパブリック フォルダ データベース上のレプリカには、受信側データベース上にない更新が存在することを示している。受信側データベースは、不足している変更番号を識別して、その番号をバックフィル配列に格納します。
  • パブリック フォルダ データベースが初めて起動された。新しいデータベースは、階層内の他のデータベースに関する情報を得るために状態要求を送信します。対応する状態メッセージが到着すると、データベースはレプリケーション状態テーブルと、必要に応じてバックフィル配列にデータを格納します。バックフィル配列には、階層のエントリと、データベースでホストする必要がある内容のレプリカのエントリの両方が含まれる可能性があります。
  • 受信階層メッセージが、パブリック フォルダ データベースに新しい内容のレプリカを置く必要があることを示している。新しいデータベースは、階層内の他のデータベースにある、このレプリカで使用可能になる可能性がある内容についての情報を得るため、状態要求を送信します。対応する状態メッセージが到着すると、データベースはレプリケーション状態テーブルと、必要に応じてバックフィル配列にデータを格納します。

バックフィル配列には、指定された期間 ("バックフィル タイムアウト" と呼ばれます)、この情報が格納されます。この期間中に後続のレプリケーション メッセージで足りない更新が到着した場合、それらの更新はバックフィル配列から削除されます。次の表に、既定のバックフィル タイムアウト値の一覧を示します。タイムアウト値は、足りない更新がどこに存在するかと、以前に要求した更新かどうかによって異なります。

バックフィル要求で使用される既定のタイムアウト

要求の種類 内容がローカルの Active Directory サイトのデータベースに存在する場合 内容がリモートの Active Directory サイトのデータベースに存在する場合

初回のバックフィル

6 時間

12 時間

バックフィルの最初の再試行

12 時間

24 時間

バックフィルの 2 回目以降の再試行

24 時間

48 時間

バックフィルがタイムアウトしても更新が不足している場合、Exchange は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを決定します。

バックフィル ソースとして使用するサーバーを選択するため、Exchange は最初に、そのフォルダのレプリカがあるすべてのサーバーの一覧を作成し、以下に示す一連の基準に従って一覧を並べ替えます。

  1. サーバーの状態に従って並べ替えます。停止していたり、使用できないサーバーは一覧の最後になります。
  2. 優先するバックフィル サーバーによって並べ替えます (設定されている場合)。Exchange は、優先するバックフィル サーバーがないか、Active Directory のパブリック フォルダ データベース オブジェクトを調べます。この設定はあまり使用されません。ほとんどの状況では、バックフィル処理が最も効率的に動作するのは Exchange がバックフィル サーバーを自動的に選択する場合です。ほとんどの Exchange の展開では、優先するバックフィル サーバーは不要です。マイクロソフト製品サポート サービスでは、実際の展開で必要な場合は、優先するバックフィル サーバーを設定するスクリプトを提供できます。
  3. トランスポート コストに従って並べ替えます (最低から最高へ)。同じルーティング グループ内のサーバーは、リモートの Active Directory サイトのサーバーより優先されます。
  4. Exchange のバージョンに従って並べ替えます (最新バージョンから古いバージョンへ)。
  5. そのサーバーで入手できる必要な変更の数に従って並べ替えます (最大から最小へ)。不足している変更がないサーバーは一覧から削除されます。

必要なすべての変更が 1 つのサーバー上にない場合、Exchange は並べ替えられた一覧の次のサーバーを選択し、そのサーバーにもバックフィル要求を送信します。すべての変更が要求されるまで、この手順が繰り返されます。

選択したサーバーがバックフィル要求に応答しない場合、データベースはそのサーバーを使用不可とマークし、選択処理を繰り返します。使用不可とマークされたサーバーは一覧の最後に移動されます。

状態要求と状態メッセージ

各レプリケーション メッセージの状態情報に加え、Exchange は状態要求と状態メッセージを使用して、パブリック フォルダからバックフィル要求を発行する必要があるかどうかを判断します。

パブリック フォルダ データベースは、以下の状況で状態要求を送信します。

  • データベースが、フォルダのレプリカを保持するデータベースの一覧に対する変更を通知された。たとえば、一覧にデータベースを追加したり、一覧からデータベースを削除すると、Exchange は階層の更新メッセージを使用してこの変更をレプリケートします。この場合、データベースは状態要求を送信して、フォルダのレプリカがあるすべてのデータベースに応答するよう要求します。
  • 新しいデータベースが初めて起動された。この場合、データベースはパブリック フォルダの階層の状態を要求します。データベースは状態要求を送信して、パブリック フォルダ ツリーをサポートするすべてのデータベースに応答するよう要求します。
  • Microsoft Windows バックアップ ツールを使用して復元されたデータベースが、復元完了後に初めて起動された。この場合データベースは、パブリック フォルダの階層と、データベースに内容のレプリカが含まれるすべてのフォルダの状態を要求します。この状態要求には、必要な応答側として、2 つまたは 3 つのデータベースが指定されます。必要な応答側は、この階層をサポートしているデータベースであり、内部の選択処理に従ってフォルダの内容を確実に取得できると判断されたソースです。

送信側データベースの特定のフォルダに関する現在の状態を示すため、パブリック フォルダ データベースは以下の状況で別のデータベースに状態メッセージを送信します。

  • 別のデータベースによって送信された状態要求への応答として。状態メッセージは以下に該当する場合のみ、要求しているデータベースにのみ送信されます。
    • 状態要求を受信したデータベースが、その要求の必要な応答側の一覧に指定されている。
    • レプリケーション状態テーブルが、状態要求を受信したデータベースに、要求を送信したデータベースに足りない更新があることを示している。
  • 後続の更新が存在しない場合に、フォルダに対する最新の更新を受信してから 24 時間後。データベースが特定のフォルダの更新を受信するたびに、タイマは 24 時間にリセットされます。この状態メッセージは、更新されたフォルダのレプリカを格納している別のパブリック フォルダ データベースに送信されます。

パブリック フォルダ データベースが受信した状態メッセージで、送信側データベースにはフォルダに関するより新しい情報があることが示されている場合、受信側データベースはバックフィル要求を作成します。変更番号が同じである (または受信側サーバーの変更番号の方が新しい) ことが示されている場合、処理は行われません。たとえば、新しいパブリック フォルダ データベースが初めて起動されると、データベースはパブリック フォルダの階層をサポートする各データベースに状態要求メッセージを送信します。各データベースは、そのデータベースで追跡していた階層の状態に関する情報を使って応答します。新しいデータベースは、この情報を使用して、保持する必要があるレプリカがあればそれを識別します。これで新しいデータベースは、必要に応じてバックフィル要求を送信し、レプリカの内容を格納することができます。

レプリケーション周期の例

次の図は、簡略化した 2 台のサーバーによるシナリオで、パブリック フォルダ データベースに内容のレプリカを追加したときに開始されるイベントの順序を示しています。この操作によって、パブリック フォルダ データベースがフォルダのレプリカ一覧に追加されます。各手順の順序は、レプリケーション間隔のタイミングやルーティング トポロジなどの要因に左右されることに注意してください。

階層へのパブリック フォルダーのレプリカの追加

この処理の詳細は、以下のとおりです。

  1. ExServ01 で作業している管理者が、ExServ01 をフォルダのレプリカ一覧に追加します。
  2. ExServ01 は階層メッセージを送信します。
  3. ExServ02 は、フォルダのレプリカ一覧のローカル コピーに ExServ01 を追加します。
  4. ExServ01 は、状態要求を ExServ02 に送信します。
  5. ExServ02 は、フォルダの完全な CNSet が含まれる状態メッセージを ExServ01 に送信します。
  6. ExServ01 は、すべてのフォルダの内容がないことを特定し、バックフィル配列に適切なエントリを記録します。
  7. バックフィルのタイムアウトが経過しても内容が不足している場合、ExServ01 はバックフィル要求を作成し、ExServ02 に送信します。
  8. ExServ02 は内容のメッセージをまとめて、ExServ01 に送信します。
  9. ExServ01 は、受信した内容のメッセージを使用して、フォルダの内容および関連する追跡情報を更新します。
  10. 変更番号がまだ不足しているようであれば、ExServ01 は 24 時間待機してから、更新したバックフィル要求を送信します。ExServ02 以外のサーバーを使用できる場合、ExServ01 はそのサーバーに要求を送信することがあります。

次の図は、簡略化した 2 台のサーバーによるシナリオで、パブリック フォルダ データベースからレプリカを削除したときに開始されるイベントの順序を示しています。この操作によって、フォルダのレプリカ一覧からパブリック フォルダ データベースが削除されます。各手順の順序は、トポロジ内のサーバー数などの要因に左右されることに注意してください。

パブリック フォルダー データベースからのレプリカの削除

この処理の詳細は、以下のとおりです。

  1. ExServ01 で作業している管理者が、ExServ01 をフォルダのレプリカ一覧から削除します。
  2. ExServ01 は、そのレプリカ (ExServ01 上のフォルダのコピー) を削除保留としてマークします。
    クライアントは、このデータベースを使用してフォルダにアクセスできなくなります。
  3. ExServ01 は階層メッセージを送信します。
  4. ExServ02 は、そのフォルダが ExServ01 で削除保留の状態にあることを示すため、フォルダのレプリカ一覧のコピーを更新します。
    ExServ02 は、このフォルダを探しているクライアントが ExServ01 を参照しないようにします。
  5. ExServ01 は、状態要求を ExServ02 に送信します。
  6. ExServ02 は、状態メッセージを ExServ01 に送信します。ExServ02 上のレプリカが最新のものではない場合、ExServ02 はバックフィル配列に適切なエントリを格納します。ExServ02 は 5 分以内に、対応するバックフィル要求を ExServ01 に送信します。
  7. ExServ01 は、ExServ02 上のフォルダ レプリカに、削除保留のレプリカに含まれるすべての情報が含まれていることを確認します。含まれていない場合、ExServ01 は適切な内容の更新を送信し、手順 5. に戻ります。含まれていた場合は手順 8. に進みます。
    この処理により、他のレプリカが存在する限り、1 つのレプリカを削除しても内容が失われないことが保証されます。
  8. ExServ01 は、そのレプリカを "すぐ削除" としてマークします。次の保守サイクルで、このレプリカは ExServ01 から削除されます。
  9. ExServ01 は階層メッセージを送信します。
  10. ExServ02 は、フォルダのレプリカ一覧のコピーから ExServ01 を削除します。

レプリケーションを実装するためのベスト プラクティス

Exchange のパブリック フォルダのレプリケーションは、大量のリソースが消費されることがある操作です。レプリケーションを実行するには、ネットワーク、CPU、およびディスクのリソースが必要です。パブリック フォルダをよく使用する組織では特に、効率的なパブリック フォルダのレプリケーションを可能にするソリューションを実装することで、Exchange 組織のネットワーク、CPU、およびディスクの負荷が大幅に軽減される可能性があります。

一般的には、組織をまたぐレプリケーションを最小限に抑えることをお勧めします。レプリケーションを最小限にすることで、ネットワーク上を移動するデータの量を最小限に抑えます。さらに、レプリケーションを最小限にすることで、複数のユーザーが複数のレプリカ上にある異なるバージョンのデータにアクセスする可能性を減らす助けになります。ただし、レプリケーションを最小限にすると、パブリック フォルダ データベースで障害が発生した場合にクライアントが使用できるフォルダのレプリカの数が少なくなるため、パブリック フォルダのデータの可用性が低下します。特定のパブリック フォルダにあるデータについては高い可用性が必要であれば、より多くのレプリケーションが必要な場合もあります。

パブリック フォルダのレプリケーションと連続レプリケーション

連続レプリケーションとパブリック フォルダのレプリケーションは、Exchange に組み込まれている 2 つの大きく異なる形式のレプリケーションです。連続レプリケーションとパブリック フォルダ レプリケーションの相互運用性の制限により、パブリック フォルダのレプリケーションと連続レプリケーションとの組み合わせについては特定のガイダンスがあります。このガイダンスを確認するには、「クラスタ連続レプリケーションの計画」、「ローカル連続レプリケーションの計画」、および「スタンバイ連続レプリケーション」を参照してください。

詳細情報

パブリック フォルダの詳細については、「パブリック フォルダについて」を参照してください。

パブリック フォルダの管理方法の詳細については、「パブリック フォルダの管理」を参照してください。

パブリック フォルダ データベースの管理方法の詳細については、「パブリック フォルダ データベースの管理」を参照してください。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。