DC Authoritative (D4) Restore for DFSR

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

An authoritative (D4) restore is sometimes also reffered to as an authoritative (D2) synchronization. This procedure is for performing an authoritative restore with a multiple domain controller environment.

IN A SINGLE DOMAIN CONTROLLER ENVIRONMENT, DO NOT PERFORM THIS PROCEDURE.

There are 2 type of restore modes for Microsoft Windows Domain Controllers:

Authoritative Restore - A Domain Controller authoritative restore is a process used to fix a big problem in the Active Directory. The Active Directory is like a big phone book that stores information about all the users and computers in a network. When you do an authoritative restore, you're taking a previous version of the phone book from a backup (or source) and using it to completely overwrite the current phone book. So, for example, if the current phone book was lost or became corrupt, you could use the previous version (or existing source) to restore the entire phone book to its previous state. The restored phone book is then sent to the other Domain Controllers in the network to keep them all in sync. This is why it's called an "authoritative" restore – you're making the restored phone book the official and correct version, and all other versions are updated to match it.

Non-Authoritative Restore - A non-authoritative restore of a Domain Controller (DC) is a process used to fix a small problem in the Active Directory. Think of the Active Directory as a big phone book that stores information about all the users and computers in a network. When you do a non-authoritative restore, you're taking a previous version of the phone book from a backup (or source) and using it to fix a specific part of the current phone book. So, for example, if someone's name was misspelled or a phone number was accidentally deleted, you could use the previous version of the phone book to fix just that one problem. The rest of the phone book (Active Directory) stays the same, and the fixed information gets sent to the other Domain Controllers in the network to keep them all in sync. This is why it's called a "non-authoritative" restore – you're not changing the entire phone book, just fixing a small part of it.

It's important to note that you should only perform a non-authoritative restore on a secondary (non-authoritative) domain controller, as making changes to the primary domain controller (PDC) can have unintended consequences. Additionally, it's recommended to test the restore process in a non-production environment before performing it in a production environment

Requirements

Domain Controller environment is using DFSR.

Instructions

On the Primary Domain Controller (PDC), which is generally considered having the most up-to-date Sysvol copy, launch ADSIEDIT.MSC tool and connect to Default Naming Context.
Browse to DC=<domain>,DC=local ⮞ OU=Domain Controllers ⮞ CN=<PDC NAME> ⮞ CN=DFSR-LocalSettings ⮞ Domain System Volume ⮞ SYSVOL Subscription.

msDFSR-Enabled FALSE

msDFSR-options 1

Setting attribute msDFSR-Options to 1 sets the server to authoritative for the DFSR SYSVOL replicated folder (Primary Copy).
On all other (non-authoritative) domain controllers, set the attribute value:

msDFSR-Enabled FALSE
On all the Domain Controllers, force Active Directory replication throughout the domain:
```
repadmin /syncall
```
On all Domain Controllers, starting with the Primary Domain Controller, run the following command from an elevated command prompt:
```
DFSRDIAG POLLAD
```
This command will poll configuration changes in AD immediately for that DC with reference to DFSR.
On all domain controllers, stop (and disable) the DFSR service.

This step is required so that DC will stop communicating with DFSR Sysvol database and cannot make changes or modifications to DFSR configuration. This step is not given in original MS KB article.
On the Primary Domain Controller (PDC), start (and enable) the DFSR service.

On the same server, You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on the PDC.
On Primary Domain Controller (PDC), change the attribute value for msDFSR-Enabled back to TRUE (step 2).

msDFSR-Enabled TRUE

This will ensure that this PDC server is the primary member for DFSR replicated folder. This will also resume DFSR replication on the PDC server only; DFSR replication on other DCs is still disabled.

This step also resets msDFSR-options to 0 from 1 automatically (we set it to 1 in Step 1) which means DFSR Sysvol authoritative restore is attempted on this DC (PDC).

Note that while you will have enabled DFSR replication on this DC (PDC) authoritatively, you must ensure that the DFSR service has been stopped on other DCs and that DFSR replication is in the disabled state. Otherwise, it leads to DFSR database conflicts and issues.
On all Domain Controllers, force Active Directory replication throughout the domain:
```
repadmin /syncall
```
On the Primary Domain Controller (PDC), run the following command from an elevated command prompt:
```
DFSRDIAG POLLAD
```
Command Output should show Sysvol and Netlogon shares (Active Directory logon shares), it means Sysvol is fully initialized and designated as primary member for Sysvol replication.

This command will poll the configuration changes in AD immediately for that DC with reference to DFSR. On the same server, you will see Event ID 4602 in the DFSR event log indicating SYSVOL has been initialized. That domain controller (PDC) has now done a “D4” of SYSVOL successfully. Open command prompt and type:
Net Share
Start (and enable) the DFSR service on the other non-authoritative DC servers one-by-one. On these servers, verify Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on each of them. Starting the DFSR service will enable these DCs to start accessing DFSR configuration database; however, DFSR replication is still not enabled.
On all other (non-authoritative) Domain Controllers, one-by-one, set the attribute value for msDFSR-Enabled back to TRUE (step 2):

msDFSR-Enabled TRUE

This step will enable DFSR replication across the domain controllers and they will start non-authoritatively restoring DFSR Sysvol
On all Domain Controllers, force Active Directory replication throughout the domain:
```
repadmin /syncall
```
On all other (non-authoritative) Domain Controllers, one-by-one, run the following command from an elevated command prompt:
```
DFSRDIAG POLLAD
```
On the non-authoritative DC servers, you will see Event ID 4604 in the DFSR event log indicating SYSVOL is now initialized and replicating correctly on each of them. These domain controllers have now done a “D2” of SYSVOL successfully.

Open command prompt and run:
```
Net Share
```
Command Output should show SYSVOL and Netlogon shares (Active Directory logon shares), it means SYSVOL is fully initialized and synchronized with a primary replication partner.

DC Authoritative (D4) Restore for DFSR

Introduction

Requirements

Instructions

Sources

KB Change/Issue Log

yyyy/mm/dd - Title

Issue

Solution

KB Meta

msDFSR-Enabled	FALSE
msDFSR-options	1