The DFSR service stops replication with error Event ID 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 clean up 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.
When a DFSR database 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 Active Directory replication when members in different Active Directory sites and use DFSRDIAG POLLAD /MEM:<MEMBER> to update the DFSR service after each change in the configuration.
- Enable the folder on the designated primary member first and wait for Event ID 4112 indicating that "This member is the designated primary member for this replicated folder."
- Enable other member(s) for the replicated folder and wait for Event ID 4104 indicating that "The DFS Replication service successfully finished initial replication on the replicated folder..."
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.