DFSR Conflict Issue

This topic contains 5 replies, has 3 voices, and was last updated by Blood Blood 8 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • Avatar
    Deland01
    Participant
    #615136

    Can anyone help me with this issue I have, we run multiple remote sites with file servers running DFSR, each remote file server replicates with its own DFSR partner in a Datacenter. Here’s the setup:

    Site 1 – Remote site with file Server running DFSR
    Site 2 – Datacenter with file server running DFSR acting as DR failover server for Site 1

    • DFSR is in a read-write between server on site 1 & site 2
    • All users are located on Site 1 and only access files on the Site 1 local file server

    I keep seeing Event ID 4412 for conflict resolution errors on the Site 2 DFSR file server. I would expect to see this on Site 1 as this is where multiple users are accessing files but there are no users accessing files on the Site 2 file server.

    I’ve checked “Open Files” & “netstat -ano” for traffic on the Site 2 file server and there is nothing open.

    Does anyone know what could be causing these issues

    • This topic was modified 8 months, 2 weeks ago by Avatar Deland01.
    JeremyW
    JeremyW
    Moderator
    #615150

    That error is specific to DFSR. So multiple users accessing a file on Site1 server wouldn’t generate that issue. The error is there because something modified the file on Site2 server and something else modified it on the site1 server.

    These modifications don’t have to be users accessing the data and changing things. It could be something as simple as the archive bit being cleared by the backups running on the site2 server.

    Here’s a blog post on troubleshooting a change storm but it should give you details to dig into the logs to see what is being changed. https://blogs.technet.microsoft.com/askds/2012/06/01/whats-causing-that-dfsr-change-storm/

    What ever processes you have running on the Site2 server, make sure they are not modifying any of the data or metadata of the DFSR files.

    Avatar
    Deland01
    Participant
    #615493

    I looked at this a while back but I’m still none the wise unfortunately. It doesn’t actually tell you anywhere what user or process updated the file so you can see the update tile and the server location and the fact it was replicated but that’s about it in terms of auditing.

     

     

    Blood
    Blood
    Moderator
    #615494

    If you have auditing enabled for the site 2 server you may be able to search the Windows Security Event Log for the file name and track down access.

    Avatar
    Deland01
    Participant
    #615495

    Yeh I will be doing this shortly but we have a lot of sites with many servers so Im just assessing the impact before I do this. I have also been looking at Netwrix File Server auditing which needs security logging enabled to work. I’m really impressed with the information you can get out of this but this obviously has a licensing fee.

    https://www.netwrix.com/file_server_auditing.html

    Blood
    Blood
    Moderator
    #615496

    Yes, it is good, but you need a lot of free space on the system drive to accommodate the size of the event logs that Netwrix configures. If space is at a premium you can follow the Netwrix support links to override the size of the log files and then choose the option to archive them, clearing off archived logs to separate storage as required.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.