We've just deployed a new DFS replication system between two Windows 2012 R2 servers. We cloned the DFSr database using MS's recommendations (http://blogs.technet.com/b/filecab/archive/2013/08/21/dfs-replication-initial-sync-in-windows-server-2012-r2-attack-of-the-clones.aspx) and replication / sync was working 99% perfectly (a few files stuck in backlog, but otherwise great).
Upon reboot of the non-primary member server, it complained in the event log about an unclean shutdown / journal wrap (shutdown was by the book), and said it would have to rebuild the database if it could not reliably recover (event 2212). It then threw log 2218, stating it was in the second step of replication database consistency checks.
Almost immediately thereafter, both servers started to throw massive numbers of 4412 (file changed on multiple servers, moving the "losing" file to DFSrPrivate\ConflictsandDeleted) logs on both primary and secondary servers. However, when I run PS Get-DFSrFileHash against both the "winning" file and that moved into ConflictsandDeleted, they match up perfectly.
The DFSr setup has 19M files, and replacing every file even though they are equal is going to take weeks; given it seems replication is stopped until this process is complete, I'd like to get DFS to 'realize' the files are actually the same. Has anyone seen something like this before?
Best Answer
When I have had a similar issue in the past I removed all the descendant members of the pool (so you only have the primary). Waited about 15 mins then added one descendent at a time waiting about 15 mins at a time. There was one server that the error came back on. This server I synchronised the file permissions with a working server (usually the principal), rinse and repeat until all your descendants are added.