4

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?

2 Answers 2

3

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.

3

You should use

dfsrdiag filehash /filepath:<yourfile>

on both servers for the same file to check if DFS-R would recognize the file as "same" as described in KB947726. I suspect, this would not be the case.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .