web-dev-qa-db-ja.com

アップグレードされたメンバーサーバーの名前が変更された後、DFS-Rが壊れた

2つのサーバーで構成される既存の双方向DFS-Rレプリケーショントポロジをセットアップしました。1つはWindows2003 R2で、もう1つはWindows 2008R2でした。これは正常に機能していました。

先週、Win2003サーバーをWindows2008R2にアップグレードしました。これはVMであったため、アップグレードプロセスでは、新しいWin 2008 R2 OS C：ドライブを作成し、古いVMからデータディスク（vmdkファイル）を接続するだけでした。次に、古いWin 2003 VMをserver-oldに名前を変更し、新しいWin 2008 VMを元の古い名前に名前を変更しました。

Before (DFS-R between server1 and server2 working ok)
=====================================================
server1 - Win 2003 R2
server2 - Win 2008 R2

After (DFS-R trying to use server1-old and server2)
=====================================================
server1-old - Win 2003 R2 (original server)
server1     - Win 2008 R2 (upgraded new VM)
server2     - Win 2008 R2 (no change)

現在の問題は、DFS-Rが壊れており、複製されていないことです。これは、古いコンピューター名server-oldをまだ参照しているためです。古いコンピュータアカウントにまだ接続されているDFS-Rに関連するいくつかのActiveDirectory属性があります。

古いコンピューターアカウントを新しいサーバーに関連付けてDFS-Rを修正できますが、元の名前（server1）は保持しますか？ I thinkこれは、DFS-Rをだまして何も変更されていないと思い込ませ、DfsrPrivateフォルダーがまだ存在するので機能します。最初の再同期を意味するため、レプリケーショングループを再作成する必要はありません。

windowsreplicationdfs-r
3
PowerApp101

サポートされていません。 Ned Pyleのブログ ここ 「ディスクスワップ」DFSRメンバーサーバーの交換プロセスの概要は次のとおりです。

  1. 新しいサーバーをセットアップし、ディスクを転送します
  2. スワップされたディスクからDFSRConfigデータベースを削除します
  3. 新しいサーバーをレプリケーショングループに追加し、初期同期が完了するようにします。

とにかく実際のファイルは100％事前にシードされている必要があるため、再同期にそれほど時間はかからないはずです。ネットワークよりもCPUに負荷がかかります。さらに、週末など、静かな時間に実行することもできます。

2
BlueCompute