Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 3 down vote accepted

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. discusses this issue. Note you'll find it strikes out the robocopy based details to point to . This is the definitive link on pre-seeding DFSR.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.