Skip to main content

DC Non-Authoritative (D2) Restore for FRS

DISCLAIMER: The information in this guide is provided "as is" without any guarantee of completeness, accuracy, timeliness, or of the results obtained from the use of this information. The author assumes no responsibility for any errors or omissions in the content. It is meant for general information purposes only and should not be used as a substitute for professional advice. The author is not responsible for any damages caused by the use of this information. By using this guide, you agree to hold the author harmless from any and all claims, damages, or expenses that may arise from your use of the information.

Introduction

This section is an excerpts by Microsoft:

Non-authoritative restores are the most common way to reinitialize individual members of FRS replica sets that are having difficulty. These difficulties may include:

  • Assertions in the FRS service
  • Corruption of the local jet database
  • Journal wrap errors
  • FRS replication failures

FRS is a multi-threaded, multi-master replication engine that Windows Server domain controllers use to replicate system policies and logon scripts. You can also use FRS to replicate content between Windows Servers that host the same fault-tolerant Distributed File System (DFS) roots or child node replicas. In Windows Server 2008 R2 and newer, FRS can only be used to replicate the Domain SYSVOL replica set.

When you deploy Windows-based domain controllers or member servers that use FRS to replicate files in SYSVOL or DFS shares, you may have to restore or reinitialize individual members of a replica set if replication has stopped or is inconsistent. In some scenarios, you may have to rebuild the whole replica set from scratch.

System state backups of Windows member servers and domain controllers do not include the FRS database that maintains a mapping of files that are held in local FRS trees and a master list of FRS files.

The global BurFlags registry key contains REG_DWORD values, and is located in the following location in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

The most common values for the BurFlags registry key are:

  • D2, also known as a nonauthoritative mode restore.
  • D4, also known as an authoritative mode restore.

You can also perform BurFlags restores at the same time as you restore data from backup or from any other known good source, and then restart the service.

Requirements

  • Domain Controller environment is using FRS.

Instructions

To perform a nonauthoritative restore, stop the FRS service, configure the BurFlags registry key, and then restart the FRS service. Follow these steps:

  1. Select Start, and then select Run.

  2. In the Open box, type cmd and then press ENTER.

  3. In the Command box, type net stop ntfrs.

  4. Select Start, and then select Run.

  5. In the Open box, type regedit and then press ENTER.

  6. Locate the following subkey in the registry:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

  7. In the right pane, double-click BurFlags.

  8. In the Edit DWORD Value dialog box, type D2 and then select OK.

  9. Quit Registry Editor, and then switch to the Command box.

  10. In the Command box, type net start ntfrs.

  11. Quit the Command box.

When the FRS service restarts, the following actions occur:

  • The value for BurFlags registry key returns to 0.
  • Files in the reinitialized FRS folders are moved to a Pre-existing folder.
  • An event 13565 is logged to signal that a nonauthoritative restore is started.
  • The FRS database is rebuilt.
  • The member performs an initial join of the replica set from an upstream partner or from the computer that is specified in the Replica Set Parent registry key if a parent has been specified for SYSVOL replica sets.
  • The reinitialized computer runs a full replication of the affected replica sets when the relevant replication schedule begins.
  • When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.

The placement of files in the Pre-existing folder on reinitialized members is a safeguard in FRS designed to prevent accidental data loss. Any files destined for the replica that exist only in the local Pre-existing folder and did not replicate in after the initial replication may then be copied to the appropriate folder. When outbound replication has occurred, delete files in the Pre-existing folder to free up additional drive space.

Sources

 

KB Change/Issue Log

yyyy/mm/dd - Title

Issue

N/A

Solution

N/A

KB Meta

Page Includes @9#bkmrk-callout-danger-NoResponsibilityDisclaimer-5wod5ufe
Back to top