Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
add comment

2 Answers

up vote 2 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.

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.

share|improve this answer
add comment

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
add comment

Your Answer

 
discard

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.