The Distributed File System Replication (DFSR) database may fail on a DFSR Replication member.

The DFSR service stops replication with error 2104. Since clients still use this member as change target you do not want to lose the changes and need a solution without restoring content from a backup. When you manually rebuild the DFSR Database by deleting the database from <Volume>:\System Volume Information\DFSR and restarting DFSR service, DFSR performs initial replication from any other still enabled member as non-master and moves conflicting files to the ConflictAndDeleted folder or new files to PreExisting. This may cause unnecessary manual cleanup and recovery.

The idea to avoid this condition is to reinitialize the affected replicated folder in an order that ensures that the affected member becomes the designated primary member of the corresponding replicated folders.

To workaround this issue:

When DB crash affected member needs to become primary master of a replicated folder:

• Check that all members are set to "disabled" for the folder, check for event 4008 on all of them when you need to change the setting.
   
• Force AD replication when members in different AD Sites and use DFSRDIAG POLLAD /MEM:<MEMBER> to update the DFSR Svc after every change in the configuration
   
• On designated primary enable folder first, wait for event 4112, "This member is the designated primary member for this replicated folder“
   
• Enable also other member(s) for the replicated folder, wait for event 4002 that folder is finally initialized