How to recover from a DFSR database crash on designated primary member

Article translations Article translations
Close Close
Article ID: 961879 - View products that this article applies to.
Expand all | Collapse all
Source: Microsoft Support

RAPID PUBLISHING

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.

Symptom



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.

 

 

More Information



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

 

DISCLAIMER

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE “MATERIALS”) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

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.

Properties

Article ID: 961879 - Last Review: January 8, 2009 - Revision: 1.0
APPLIES TO
  • Microsoft Windows Server 2003 R2 Datacenter Edition (32-Bit x86)
  • Microsoft Windows Server 2003 R2 Enterprise Edition (32-Bit x86)
  • Microsoft Windows Server 2003 R2 Standard Edition (32-bit x86)
Keywords: 
kbnomt kbrapidpub KB961879

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com