4

I had an existing 2-way DFS-R replication topology set up, consisting of two servers, one was Windows 2003 R2 and the other Windows 2008 R2. This was working fine.

Last week I upgraded the Win 2003 server to Windows 2008 R2. It was a VM, so the upgrade process just involved creating a new Win 2008 R2 OS C: drive and attaching the data disks (vmdk files) from the old VM. I then renamed the old Win 2003 VM to server-old and renamed the new Win 2008 VM to the original old name, like so:

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)

The problem now is that DFS-R is broken and not replicating, because it is still referencing the old computer name, server-old. There are some Active Directory attributes related to DFS-R still attached to the old computer account.

Am I able to fix DFS-R by associating the old computer account with the new server but keep the original name (server1)? I think this would work as it would fool DFS-R into thinking nothing had changed, and the DfsrPrivate folder still exists. I don't want to have to recreate the replication group as that would mean an initial resync.

PowerApp101
  • 2,624
  • 1
  • 20
  • 28

1 Answers1

3

Not supported. Ned Pyle's blog here outlines the process for a 'Disk Swap' DFSR member server replacement as follows:

  1. Set up new server and transfer disks across
  2. Delete DFSR Config database from swapped disks
  3. Add new server to replication group and allow initial sync to complete.

The resync shouldn't take long at all as the actual files should be 100% preseeded anyway, it'll be more CPU intensive than network. Plus you could run it at a quiet time, over a weekend etc.

BlueCompute
  • 2,954
  • 2
  • 19
  • 28
  • Thanks for that. The problem is that both ends of the replication group have modified files. Is there any chance data will be lost from either end in the initial sync in step 3? – PowerApp101 Jun 03 '14 at 11:53
  • Ok I've read the critical note in step 9 of the article - "if this server is the originating copy of user data – such as the branch server where all data is created or modified– delete the entire existing replication group and recreate it with this new server specified as the PRIMARY. Failure to follow this step may lead to data loss, as the server being added to an existing RG is always non-authoritative for any data and will lose any conflicts". Does this mean that a new file on the server being added will get deleted if it doesn't exist on the authoritative server? – PowerApp101 Jun 03 '14 at 12:05
  • You shouldn't have modified files at both ends - the server you've bought up with the old disks shouldn't have any modifications before it (re)joins the RG. – BlueCompute Jun 03 '14 at 13:33
  • Unfortunately the new server does have modifications because it's been live for a few days despite DFS-R not working. I guess I could first robocopy any new files to the destination authoritative server, and then add the new server back into the RG. That way at least the files should be in sync before the replication starts. – PowerApp101 Jun 03 '14 at 15:14
  • OK. I recommend you review all of Ned's DFSR blogposts, I've found them very useful source of detailed info on DFSR operations. eg: http://blogs.technet.com/b/askds/archive/2008/02/12/get-out-and-push-getting-the-most-out-of-dfsr-pre-staging.aspx http://blogs.technet.com/b/filecab/archive/2013/02/08/the-case-of-the-mysterious-preseeding-conflicts.aspx – BlueCompute Jun 03 '14 at 16:08