What I learned while migrating DFSR

A recent task I inherited was migrating DFS and DFSR roles to a new storage server, during this I learned some of the more convoluted workings that had stumped a couple of the people who attempted it before me.

DFS (Distributed File System) Namespaces is a role service in Windows Server that enables you to group shared folders located on different servers into one or more logically structured namespaces. This makes it possible to give users a virtual view of shared folders, where a single path leads to files located on multiple servers.

Under the hood your sysvol which is replicated between your DCs is actually using DFS, which is a fun fact that may help you understand a common use for it. I would recommend reading the official docs to understand how to actually use and deploy DFS.

Directory Re-Use with DFSR

This was an issue for previous admins who attempted to migrate shares, despite the official documents saying you can pre-seed shares for DFSR migration I encountered nothing but issues. The largest issue is one that is hard to spot:

If a directory has previously been used for or preseeded from a DFSR share it will contain a DfsrPrivate directory. The existence of this directory will deem the new server MASTER no matter what. All other servers in the pool will be wiped and replicated from the new member.

The DsfrPrivate directory is HIDDEN and SYSTEM file. You must enable both view options to see it. It must be deleted prior to synching.

Pre-Seeding

When I pre-seeded I ended up getting many files "duped" during the syncing process with many many Event 4412's occuring. This could cause space issues, and is clearly a waste of some time. I do not recommend pre-seeding for this reason, I had very few issues during my syncs even when handling hundreds of GB.

Event 4412
The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.

Event 4206

This was the only error that concerned me during my migration. It will be popped continuously until resolved. In every case I saw it, it was resolved after several hours. This could relate to a user having a file lock active, but I am not positive.

The DFS Replication service failed to clean up old staging files for the replicated folder at local path D:\Data\Shared. The service might fail to replicate some large files and the replicated folder might get out of sync. The service will automatically retry staging space cleanup in 30 minutes. The service may start cleanup earlier if it detects some staging files have been unlocked.

Event ID List

I found this list handy while I was monitoring my migration: