1

Both servers in a 2 server cluster are reporting event 4412 20,000 times per day. If I sit in the conflictAndDetected folder I can observe files appearing and disappearing. Users report that their files saved by peers at the same location are overriding each other.

The configuration began with a single server, then DFS-R was set up using the 2008 R2 wizard that set up the share on the second server. DFSN was set up independently. Windows users have drives mapped using domain based namespace (\domain.com\share). Mac users are pointed directly to the new server share created by DFS-R. It is PC users indicating most of the lost files, but there has been 2 reports by Mac users about files reverting.

I've implemented DFS-R before and the event 4412 only occurred when users simultaneously opened files and made changes, or during the initial replication. Here the two servers are in sync (backlogs are empty). Why is DFS-R detecting that the file was updated on multiple servers and why are the valid conflictAndDeleted files being replaced by non-conflictAndDeleted files?

Improve this question
6
  • And your question would be...?
    – HopelessN00b
    Aug 30, 2012 at 3:49
  • Good point, but if you can't tell that having files overridden by peers at the same location is a problem I wouldn't expect asking a question would help.
    – Andrew Gauger
    Aug 30, 2012 at 18:36
  • Still not a question, but at least we've clearly identified the problem. So, now that we've done that, what's your specific question regarding your issue with DFS replication conflicts?
    – HopelessN00b
    Aug 30, 2012 at 18:56
  • I've implemented DFS-R before and the event 4412 only occurred when users simultaneously opened files and made changes, or during the initial replication. Here the two servers are in sync (backlogs are empty). Why is DFS-R detecting that the file was updated on multiple servers and why are the valid conflictAndDeleted files being replaced by non-conflictAndDeleted files?
    – Andrew Gauger
    Aug 30, 2012 at 21:55
  • This smells like a networking problem to me, are you using the same kind of switching gear as in your previous cluster?
    – SpacemanSpiff
    Aug 30, 2012 at 22:08

1 Answer 1

Reset to default
0

Just for clarification, are you seeing conflicts for files that you're 100% sure aren't being modified by a server? I would assume based on the 22,000 conflicts per day.

Is this only happening for one replication group, and how big is the folder target for that group? If the folder target isn't that large, you may be best off just re-creating the replication group.

Here are a few things I would do to get more information about what might be happening:

  • Run a DFSR diagnostic report for your replication group, and look at the "information" section of each replicating server. Do any of them say that initial replication is still occurring?
  • Run: "dfsradmin membership list /rgname:replicationgroupname /attr:memname,rfname,isprimary,objstate" and make sure all members report Normal and that no member is primary

Take a look at the DFSR debug log on one of the member servers (%windir%\debug\Dfsr00100.log by default), and do a search for the word "Error" and see if anything comes up.

Improve this answer
1
  • Do any of them say that initial replication is still occurring? No. make sure all members report Normal and that no member is primary => ObjState = Normal IsPrimary = No (times two). Error seems normal for a lock => [Error:170(0xaa) InitializeFileTransferAsyncState::ProcessIoCompletion servertransport.cpp:2235 436 W The requested resource is in use.] completion:0 ptr:06D96398 I do think that MozyPro, a backup software is causing DFS-R to think the files have been changed. Still need to reboot the server to make sure but letting it make a backup first.
    – Andrew Gauger
    Sep 7, 2012 at 14:30

You must log in to answer this question.

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