About to run out of space on the volume hosting a DFS folder target? I just about did, and had to take quick steps to move to a bigger volume. This page describes the process and commands used.
Note: This process will perform an initial replication within your replication group. As far as I’ve found, there is no way around it, so make sure you’re scheduling enough time for this to complete.
Note #2: A lot of this information was provided by Ned Pyle with Microsoft, through correspondence and the Ask DS blog. See this blog post for more information: http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx#comments
One of our replication groups is approaching 800 GB and almost 1 million files, and growing; and we were down to 2 GB free space remaining on the volume. Our environment at the time was fully Server 2008 x64.
After creating a larger volume for the files to move to, you will begin with Pre-Seeding your data. As recommended in the Ask DS post above, this should be a one-time operation. It was difficult for us to schedule this copy along with a time window for the initial sync, but we managed.
If you can, disable the folder targets so changes aren’t made during your file copy:
dfsutil property state offline \\domain.ca\files\jobs \\server\jobs$
The last two values of that command is the DFS path, and the folder target. Do this for each folder target.
Our pre-seed command was:
Robocopy.exe d:\jobs e:\jobs /b /e /copyall /r:6 /NFL /NDL /MT /xd dfsrprivate /log:robo.log /tee
It is VERY important that your destination folder does not exist before you pre-seed. Let the robocopy command create it for you. You can also use other pre-seed options mentioned in the Ask DS post above.
After the pre-seed, you’ll want to confirm DFSR recognizes the files as identical. If you don’t do this, you will get a ridiculous amount of conflicts in the event log during the inital sync. Trust me, I know this through experience.
To check the files you’ll need Server 2008 R2 or Windows 7 RSAT, and this command:
dfsrdiag.exe filehash /FilePath:"\\server\f$\Jobs\file1.txt" dfsrdiag.exe filehash /FilePath:"\\server\e$\Jobs\file1.txt"
The same CRC value should be returned for each command. If not, then you’ve got a problem somewhere in your pre-seeding.
Change Share Path
Now you need to change the share target, so that the folder target will still be \\server\jobs$ (or whatever you’re using).
Open Regedit and navigate to: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Shares
Find the REG_MULTI_SZ entry that corresponds to the DFS share and modify only the “Path” line to refer to the new path.
In my case, I changed Jobs$ share from F:\ to E:\. A restart is required before this takes effect, but we waited until after the next command.
Transfer DFSR Membership Settings
Now you need to tell DFSR that the location has changed. This is the command that starts the initial replication. Make sure this command is all one line.
dfsradmin membership set /rgname:domain.ca\files\jobs /rfname:Jobs /memname:domain\sw3010 /localpath:E:\Jobs /membershipenabled:true /stagingpath:E:\Jobs\DfsrPrivate\Staging /stagingsize:24000 /cdsize:660 /membershipdfsfolder:\\server\jobs$ /isprimary:false /force
Now restart the server. Once Windows comes back up, it will begin initial replication. You can check the progress by checking the backlog:
dfsrdiag Backlog /receivingmember:server1 /sendingmember:server2 /rgname:domain.ca\files\jobs /rfname:Jobs
In my environment, initial replication of ~800 GB and 1 million files takes approximately 8 hours.
Once initial replication is complete, make sure you re-enable the folder targets:
dfsutil property state online \\domain.ca\files\jobs \\server\jobs$
Now you’re done! Do a full backup after this is complete, and then delete the original source folder.
2 thoughts to “Change Folder Target of DFSR Member”
A quick question. For the share change, is there a reason that the change must be made in the registry? Why not use NET SHARE to remove and recreate the share? This avoids a reboot.
To be honest, there’s no specific reason that I know of; I’ve never tried it with NET SHARE. However I’d be hesitant to actually delete the share and re-create it rather than simply move the path through the registry, knowing how sensitive DFSR is to changes.