Share via

DFSR - Database Corrupt

Question

Tuesday, March 9, 2010 12:15 PM

Hi,

We recently ran into a problem where our File Server ran out of space and DFSR was abruptly stopped. Our DFSR configuration is a hub and spoke configuration and the problem server is our hub server. THe Server is constantly circling through three errors as below:

Source: DFSR
Event ID:2212
Error: The DFS Replication service has detected an unexpected shutdown on volume D:. This can occur if the service terminated abnormally (due to a power loss, for example) or an error occurred on the volume. The service has automatically initiated a recovery process. The service will rebuild the database if it determines it cannot reliably recover. No user action is required.

Source: DFSR
Event ID: 2104
Error: The DFS Replication service failed to recover from an internal database error on volume D:. Replication has been stopped for all replicated folders on this volume.

Additional Information:
Error: 9214 (Internal database error (-1605))
Volume: 7DA06443-AD3C-11DE-8C05-806E6F6E6963
Database: D:\System Volume Information\DFSR

Source: DFSR
Event ID: 2106
Error: The DFS Replication service successfully recovered from an internal database error on volume D:. Replication has resumed on replicated folders on this volume. 

Additional Information:
Volume: 7DA06443-AD3C-11DE-8C05-806E6F6E6963
Database: D:\System Volume Information\DFSR

And then the circle starts again with the first event indicationg that DFSR has shutdown uncleanly. It's looking like a DFSR rebuild, but I'd love to know if I can repair the DB without resorting to this. Any suggestions on how to resolve the corruption?
CJS

All replies (5)

Thursday, February 17, 2011 7:09 PM

Did you ever get this resolved? I am running into the exact same thing with Windows Server 2008 R2. I've been working on this for a few weeks with no luck.

 

Chad

Friday, June 10, 2011 1:45 PM | 4 votes

Hi,

I just came across the same issue and was able to find a solution.

Issues was due to corruption of DFSR database due to which WMI repository was not able to connect to DFSR. 
The DFSR WMI provider defines classes for configuring and monitoring the DFSR service as a result the WMI errors were misleading in our case.

Issue occurred as a result of

1.       Disk failure

2.       Resulting in data corruption.

3.       Data was recovered by Chkdsk.

4.       Chkdsk was not able to recover the DFSR data base leading to DFSR database corruption.

 We were lucky in this case as this server was  the secondary (Not primary) Replication partner, hence DFSR database recreation was easy.

Resolution ==>

  1. Grant Full Control permissions to the System account for the system volume information folder and for all its sub folders. Then, restart the Windows Server 2003 R2-based server.
  2. Stop DFSr service.
  3. 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.
  4. Start the DFSR service.

If this happens with an Primary Repication member following needs to be done --

In case of a Primary member 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

http://support.microsoft.com/kb/961879

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Friday, July 26, 2013 8:03 AM

Hi V-2ashud

I would just like to say a big thank you. 

I ran into this issue yesterday on our primary member. 

I followed your instructions and now everything is backup and running.

Thanks

Hod

Saturday, February 27, 2016 1:31 AM

Awesome - after 40 hours fighting this lead me to the resolution. 

Monday, March 12, 2018 12:00 PM

Hi, I recently had this same issue. This thread is one of the top results in search engines so I thought I should add a little more information for what I have learnt.

If you take control over <Volume>:\System Volume Information\ to rename or delete DFSR  then make you grant the SYSTEM   account FULL CONTROL over it again. (Or this will cause Event 2104 with Access Denied and the DFS will never appear in WMIC.).

To check the DFS membership , run the following from an elevated command prompt:

Wmic /namespace:\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,state

You should see your DFS group with State 4 next to it once it's working.

When you re-initialise the database the contents of the Primary member will replace the files on all other members when they become enabled. This is the case for New or updated files on the other member servers. So make sure you have backups before you start.

  • Last updated on