Hello,

We're using DFS replication for backing up a file share from branch office server to datacenter. 

We have a DFS replication group set with two members - server on our branch office (Branch-Srv1) and a server in our datacenter (Hub-Srv1). Both servers are running Windows Server 2008 R2.

Source path on Branch-Srv1 is D:\Fileshare 

Target path on Hub-Srv1 is E:\Backup\Branch-Srv1

Everything has worked smoothly until now when E drive is running out of disk space on the hub server. Our server administrator has kindly created a new (2 TeraBytes) volume on Hub-Srv1 and assigned it a drive letter F.

So I must re-configure DFS replication to drive F on Hub-Srv1.

Total amount of data on replicated folder is about 200GB. Bandwidth between hub and branch is ~ 1Mbit/s so it would take eons to finish replication if it's started from scratch. I've read Ned's blog about preseeding a replicated contents, but I don't see any of those scenarios fit mine http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx

Could someone advise what is the correct method to change target drive letter + path on hub server while minimizing time for replication (preseeding) ?

• Edited by weedee Monday, July 27, 2015 2:47 PM

Hi,

As data is already on Drive E, you do not need to wait DFSR to do the initial replication. 

You can use Robocopy or Xcopy to copy files from E:\Backup\Branch-Srv1 to G:\Branch-Srv1 with NTFS permission settings.

Then you can delete Hub-Srv1 from the DFS Replication group. For an AD replication and add Hub-Srv1 back with the new path.

An initial replication will be performed still but as data are already there, it should be finished more quickly.

Hi Shaon,

Meanwhile I bumped to this article (this applies to 2008 R2 aswell). Does this mean that if I first delete and add same member server to the same replication group until 60 days has passed, I'm facing a risk to lose files on branch office server?

After you re-add a member server to a DFS replication group in Windows Server 2003 R2, initial replication does not occur on the member server, and changes in the replicated folder are replicated unexpectedly to other replication partners

https://support.microsoft.com/fi-fi/kb/961655

• Edited by weedee 21 hours 55 minutes ago

Hi,

It is a little different as your current situation:

After event ID 4010 is logged in the DFS Replication log on the member server, you change the content in the replicated folder on the member server. Then, you add the member server back to the DFS replication group by using the same replicated folder.

The root cause of this issue in KB961655 is that some files are edited after removing the server from the replication group. Which means "the server you added back host the most updated files". As DFSR uses "last-write-win" policy to do the replication, the changes will be replicated to other member servers.

In your case all files are the same or older than those member servers which are still in DFS replication group. So it will not be an issue.

As a backup plan you can create a backup or a snapshot of existing data incase anything goes wrong.