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.
Not supported. Ned Pyle's blog here outlines the process for a 'Disk Swap' DFSR member server replacement as follows:
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.