To prepare DFS replication, we used robocopy /DATSOU... to copy the contents of a shared folder (~170G) to another server.
After that, a DFS replication group was configured with the two folders.
Now after some hour we get tons of 4412 errors telling that a file was changed on multiple servers. This is definitely not the case. Filetimes etc. are all the same (except access time), which I can verify when comparing the "winning" files with the deleted ones in DfsrPrivate\ConflictAndDeleted.
What is happening here?
Best Answer
Just to add to the response from syneticon-dj, depending on how you did the robocopy, it is likely that the permissions on the source and destination differed. If this were the case, the filehash would differ and cause 4412 events. It should still use RDC to minimize what it pulls down from source.
http://blogs.technet.com/b/askds/archive/2008/02/12/get-out-and-push-getting-the-most-out-of-dfsr-pre-staging.aspx discusses this issue. Note you'll find it strikes out the robocopy based details to point to http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx . This is the definitive link on pre-seeding DFSR.