Event ID: 4412

Discussion in 'File Systems' started by mtoadmin, Apr 20, 2006.

  1. mtoadmin

    mtoadmin Guest

    Hello everyone,

    I'm currently replicating user data from a Master server to a Slave server.
    The users can access the data only on the master throught a normal share
    (it's not a dfs share so far for the users)
    From time to time (Usually early in the morning) I get one or two eventi id
    4412. How can this happen if the users are not modifying anything on the
    slave server.
    Note: The slave server is a straight R2 and there is no antivirus.
    Currently, I have two connections, should I disable the one from the slave
    to the master ?

    (Some data have been removed below)
    Event Type: Information
    Event Source: DFSR
    Event Category: None
    Event ID: 4412
    Date: 2006-04-20
    Time: 03:43:22
    User: N/A
    Computer: SRV101
    Description:
    The DFS Replication service detected that a file was changed on multiple
    servers. A conflict resolution algorithm was used to determine the winning
    file. The losing file was moved to the Conflict and Deleted folder.

    Additional Information:
    Original File Path: *************************
    New Name in Conflict
    Folder:*******-{C40D429C-31E1-4082-8A6F-243CAD759C89}-v111
    Replicated Folder Root: D:\Documents
    File ID: {B36B8908-1E85-4C38-96B0-3BFF43CD3DA9}-v169461
    Replicated Folder Name: Donnees_Longueuil
    Replicated Folder ID: B0DB266E-1AF0-466A-BF21-AE16951AFD44
    Replication Group Name: ****************************
    Replication Group ID: 3293ECC3-B153-4E21-98F6-45EAB8497FEB
    Member ID: 6449A16B-0987-4AE8-8C94-63C3554B0848

    For more information, see Help and Support Center at
    http://go.microsoft.com/fwlink/events.asp.
     
    mtoadmin, Apr 20, 2006
    #1
    1. Advertisements

  2. In that scenario you would want to enable Object Access Auditing and audit
    some of the files experiencing this issue so that you can see what
    users/processes are accessing the files. Be careful in how you do this - if
    at all possible, do not audit the whole directory structure, just files that
    consistently have the issue; otherwise you will 1) wrap your security event
    log so fast you can't see the issue 2) unnecessarily cause CPU performance
    issues.

    KB310399 (it's for XP, but the steps are identical for 2000, XP, 2003, or
    Vista).

    If the events are only occuring on the slave that the users do not have
    access to... not sure what's going on. :) The auditing should tell us.

    Definitely do not remove the connection from the slave server - if you do
    that you will backlog forever and eventually cause all sorts of issues on
    the slave.

    Ned
     
    Ned Pyle \(MSFT\), Apr 20, 2006
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.