関連するアーキテクチャおよび手順をよく理解していない場合は、Microsoft DFS を使用した更新はお勧めしません。

DFS は、複数の物理的な場所を同じ論理ホストとして表示できるファイル ストレージ アーキテクチャであるため、ファイルの可用性が向上し (複数の場所があることは冗長性の向上を意味します)、ユーザーがこのデータにアクセスするために移動する必要があるネットワークの距離が最小化されます。

各 DFS 共有からのデータは、ファイルとそのコンテンツの一貫性があり正確なコレクションを維持するために、Microsoft 分散ファイル システム レプリケーション (DFSR) サービスを使用して、その他の DFS 共有間で自動的に複製されます。

リストされている McAfee 製品では、次のシナリオで DFS 共有の使用をサポートしています。

ただし、DFS には制限があるため、クライアントが更新する必要がある場合に分散リポジトリの一貫した更新ファイル セットを常に見つけることができるように次の点を確認してください。

DFS で管理されるすべての共有は、同時にオフラインになります。
ePO は、独自のメカニズムを使用して通常の分散リポジトリに複製する場合に、複数のリポジトリを同時に並行して複製します。 複製時に、これらのリポジトリは SiteStat.xml で無効とマークされます。 これらのリポジトリは、複製が完了すると SiteStat.xml で有効になり、分散リポジトリの別のバッチの複製が開始されます。 したがって、一度に少数の分散リポジトリのみがオフラインになります。

無効なリポジトリから更新しようとするエージェントは接続に失敗し (SiteStat.xml の disabled フラグのため)、Sitelist.xml から次に使用可能なリポジトリを選択します (これは、Ping 時間、サブネット マスク、またはユーザー定義リストによってリポジトリを選択する、エージェント ポリシーのユーザー構成によって異なります)。

DFS は、ファイル レプリケーション サービス (FRS) を使用して、DFS で管理される各仮想共有に、ePO の複製タスクによって変更された各ファイルを複製します。 変更される最初のファイルは、SiteStat.xml ファイルです。 ステータス フラグが disabled に設定されている場合、この変更は、DFS が管理するすべての共有に複製されます。 この時点では、更新する共通フレームワークを使用する製品はこの共有を使用することはできません。これにより、エージェントが複製の途中の不整合なファイルを取得することを防ぎます。

つまり、FRS で複製されるすべての DFS 共有がほぼ同時に使用不可 (disabled) になり、複製が完了するまで再度有効になりません (これは、並行して複製されるリポジトリの数が「CPUs x 6 の数」である ePO 複製とは異なります)。

作成された共有の可用性、その地理的な場所を考慮し、実際に複製する必要がある数を最小限に抑える

DFS 更新共有に必要なユーザー アクセスの考慮
共有には、常に、最小限のアクセスの原則が適用されます。 クライアントには、DFS 共有から更新への読み取りアクセスのみが必要ですが、ePO サーバーには、複製先の共有へのフル アクセスが必要です。 この原則は、DFS の使用時に、リポジトリ共有のコンテンツに加えられた変更がその他すべての DFS 共有に複製される場合、さらに重要になります。

共有のコンテンツの整合性
DFS では、ファイルの変更をモニタリングして、複製されるファイルが決定されます。整合性検査は実行されません。 ePO では、変更されていないことを確認するために、複製された各ファイルのチェックサムを確認します。 DFS がファイルのコンテンツを確認していないため、共有へのアクセスのセキュリティは非常に重要です。 DFS 共有に対する唯一の書き込みアクセスを持つ専用 ePO 複製アカウントの作成を検討してください。