We have two Windows Server 2016 setup as file servers with DFSN and DFSR. One of the file shares has been setup and has been replicating happiy for the last week. The seocnd server as of yet isnt added to the namespace. This morning all of the files on one server dissapeared. I restored these from backup. On further investigation of the event logs I found that for every missing file an event stating: The DFS Replication service detected 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
Any ideas as to what would cause this for every file / what can be done to ensure that it dosnt't happen again.
Cheers,
Paul
Windows OSWindows 10AzureWindows Server 2016
Last Comment
arnold
8/22/2022 - Mon
arnold
Files should not disappear, they should reflect the winning file.
what type of files?
check the DFSR connection tab, does each member of the replication group have an outgoing connection to each member of the group? This would be if you have a MESH topology, or you have a hub topology one server has outgoing connections to all members of the group while all other members have a single connection to the central server?
if a server is not published in the name space, the share if present will have to be used directly through a server based share.
DFSR as you noted has a conflict resolution process when a node sees an event from its peer of a change while at the same time sees a change of a file for a user.
This is the issue of a DFS with multiple hosts when the same file is altered at the "same time"
scheduling/bandwidth allocated for the replication..
Paul Walsh
ASKER
Hi,
All of the files dissapeared. I had an event logged for each file. What has got be a little confused is why it decided that every file on server one was in contention with server two and serv onw lost. There where no direct connection to the sahres in use on server 2 (winning) nor was it in the namepsace yet. The only thing setup was replication.
The topology was a mesh. I did when setting up have to re delete and recreate the partenrship between the two servers. I have read somewhere that even though the partnership was deleted, that the database in the background will still be present for 30 days. Could this have caused the issue?
what type of files?
check the DFSR connection tab, does each member of the replication group have an outgoing connection to each member of the group? This would be if you have a MESH topology, or you have a hub topology one server has outgoing connections to all members of the group while all other members have a single connection to the central server?
if a server is not published in the name space, the share if present will have to be used directly through a server based share.
DFSR as you noted has a conflict resolution process when a node sees an event from its peer of a change while at the same time sees a change of a file for a user.
This is the issue of a DFS with multiple hosts when the same file is altered at the "same time"
scheduling/bandwidth allocated for the replication..