# DFS
# Clear DFS Problems
1. Script
2. Purge Temp Archive Bit
3. Restart service and Check bandwidth
4. Check DFS Checker event logs
Replication State codes are as follow:
0: Uninitialized
1: Initialized
2: Initial Sync
3: Auto Recovery
4: Normal
5: In Error
# DFS Backlog Check
| READONLY
| 0x1
|
| HIDDEN
| 0x2
|
| SYSTEM
| 0x4
|
| DIRECTORY
| 0x10
|
| ARCHIVE
| 0x20
|
| DEVICE
| 0x40
|
| NORMAL
| 0x80
|
| TEMPORARY
| 0x100
|
| SPARSE\_FILE
| 0x200
|
| REPARSE\_POINT
| 0x400
|
| COMPRESSED
| 0x800
|
| OFFLINE
| 0x1000
|
| NOT\_CONTENT\_INDEXED
| 0x2000
|
| ENCRYPTED
| 0x4000
|
1. Start, Run, Calc.
2. Change to Hex and paste in the File Attributes value from the Fsutil command. Say for example, 4925.
3. Hit the And button, then type 100.
4. Hit equals and if it returns 100, then the temporary attribute is set. If it returns 0, the temporary attribute is not set.
Checking for Temporary Files in the Debug Logs with Findstr
Another way to check if files are not replicating because they have the temporary attribute set is to use [Findstr](http://technet.microsoft.com/en-us/library/bb490907.aspx) (included in Windows) to look for the FILE\_ATTRIBUTE\_TEMPORARY text string in the DFSR debug logs.
First you need to extract out all of the debug logs, because all except the active log will be compressed, as indicated by a .GZ extension. The DFSR debug logs (Dfsr\*.log and Dfsr\*.log.gz) reside by default under %windir%\\debug. All the popular compression tools such as Winzip and Winrar can handle .GZ compression.
Let’s say you extracted the debug logs to C:\\Logs. You can then run the following Findstr command to look for temporary files.
Findstr FILE\_ATTRIBUTE\_TEMPORARY c:\\logs\\dfsr\*.log
That will output the entire line for every line in the debug log that contains a match to that string. If it doesn't find any matches, it will return to a prompt and not show anything.
Sample output from a matching entry:
C:\\WINDOWS\\debug\\Dfsr00018.log:20080903 16:14:29.390 1808 USNC 1204 UsnConsumer::ProcessUsnRecord Skipping USN\_RECORD with FILE\_ATTRIBUTE\_TEMPORARY flag:
If it does find any matches, you can then open the specified log file, search on the string FILE\_ATTRIBUTE\_TEMPORARY (Ctrl+F or Edit | Find in Notepad) and then you will see the actual file name for the file that was skipped because the temporary attribute is set on it.
Removing the Temporary Attribute from Multiple Files with Powershell
So you figured out that DFSR is not replicating some files because they have the temporary attribute set. There is no way to change this behavior in DFSR, so the only option is to live with it, or remove the temporary attribute from the files you want to replicate. An application in your environment has created these temporary files, so just treating the symptom isn’t enough, you need to find the application that creates them and either change its behavior, or accept that those files will not be replicated.
Since Attrib is not aware of the temporary attribute, we need to go to greater lengths to remove it. First you need to have Powershell installed on the machine - [www.microsoft.com/powershell](http://www.microsoft.com/powershell)
Then bring up a Powershell prompt (Start, Run, Powershell or from the Programs menu) and run this command to remove the temporary attribute from all files in the specified directory, including subdirectories (in this example, D:\\Data):
Get-childitem D:\\Data -recurse | ForEach-Object -process {if (($\_.attributes -band 0x100) -eq 0x100) {$\_.attributes = ($\_.attributes -band 0xFEFF)}}
If you don’t want it to work against subdirectories just remove the -recurse parameter.
Pasted from <[http://blogs.technet.com/b/askds/archive/2008/11/11/dfsr-does-not-replicate-temporary-files.aspx](http://blogs.technet.com/b/askds/archive/2008/11/11/dfsr-does-not-replicate-temporary-files.aspx)>
# DFS Staging Size
(Get-ChildItem 'F:\\SQL\_DFS' -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
The above command is originally from Microsoft
It checked the DFS folder "F:\\SQL\_DFS" for the largest 32 files and gives the result in GB.
Once you have that number change the staging on the folder to that size (listed in MB).
DFS will stop and work on staging if it gets to 90% of that number. Therefore
Multiply it by 1.12 to get the size needed to keep that from happening.
$DFSSource='E:\\Shared'
(Get-ChildItem $DFSSource -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
$DFSSource2='E:\\Data1'
(Get-ChildItem $DFSSource2 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
$DFSSource3='E:\\Procedures'
$DFSSource4='E:\\Sales Information'
$DFSSource5='E:\\SCC Reband'
$DFSSource6='E:\\Shared'
$DFSSource7='E:\\SQL Backup'
$DFSSource8='E:\\Tech Information'
$DFSSource9='E:\\Williams Documents-Accounting'
$DFSSource0='E:\\Williams Mail List'
(Get-ChildItem $DFSSource3 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
(Get-ChildItem $DFSSource4 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
(Get-ChildItem $DFSSource5 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
(Get-ChildItem $DFSSource6 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
(Get-ChildItem $DFSSource7 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
(Get-ChildItem $DFSSource8 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
(Get-ChildItem $DFSSource9 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
(Get-ChildItem $DFSSource0 -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
# DFSR Won't re-enable
There are times when DFS was used prior and it just won't work anymore. This has been seen in AD replication.
The DB that DFS refers to is in
C:\\System Volume Information\\DFSR
Within that folder is the DFS information. If that information is bad you have to purge it.
Remove the server from all DFSR
Update settings to allow you to see hidden system files
Take ownership of "System Volume Information"
Grant full access to folder and subfolders to yourself
CMD Elevated: rmdir "C:\\System Volume Information\\DFSR" /s
At this point all the DFSR information is gone but you messed with vital security permissions
I am using: DISM.exe /Online /Cleanup-image /Restorehealth
To hopefully get it back in-line
# WMI-DFS Staging Size
From command prompt, run these commands:
Connection Test
%systemroot%\\System32\\wbem\\WMIC.exe /namespace:\\\\root\\microsoftdfs path dfsrconnectioninfo where "LastSyncTime<>'99990101000000.000000-000' and state='3'" get membername, partnername, ReplicationGroupName, state
Replication Test
%systemroot%\\System32\\wbem\\WMIC.exe /namespace:\\\\root\\microsoftdfs path dfsrreplicatedfolderinfo where "state='5'" get membername, ReplicationGroupName, state
If the result is:
No Instances(s) Available.
Then all is good.
Without limitations, these commands will give the current connections and their states:
Connection Test
%systemroot%\\System32\\wbem\\WMIC.exe /namespace:\\\\root\\microsoftdfs path dfsrconnectioninfo get membername, partnername, ReplicationGroupName, state, LastSyncTime
Replication Test
%systemroot%\\System32\\wbem\\WMIC.exe /namespace:\\\\root\\microsoftdfs path dfsrreplicatedfolderinfo get membername, ReplicationGroupName, state
# How to troubleshoot missing SYSVOL and Netlogon shares
[https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-missing-sysvol-and-netlogon-shares](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-missing-sysvol-and-netlogon-shares)
This article provides the steps to troubleshoot the missing `SYSVOL` and `Netlogon` shares in Windows Server 2012 R2.
*Original KB number:* 2958414
## Symptoms
`SYSVOL` and `Netlogon` shares aren't shared on a domain controller. The following symptoms or conditions may also occur:
- The `sysvol` folder is empty.
- The affected domain controller was recently promoted.
- The environment contains domain controllers running versions of Windows earlier than Windows Server 2012 R2.
- DFS Replication is used to replicate the `SYSVOL` Share replicated folder.
- An upstream domain controller's DFS Replication service is in an error state.
## Cause
Domain controllers without `SYSVOL` shared can't replicate inbound because of upstream (source) domain controllers being in an error state. Frequently (but not limited to), the upstream servers have stopped replication because of a dirty shutdown (event ID 2213).
## Resolution
This section contains recommended methods for troubleshooting and resolving missing `SYSVOL` and `Netlogon` shares on domain controllers that replicate by using the DFS Replication service.
The process reinitializes DFS Replication if `SYSVOL` isn't shared on domain controllers according to [How to force an authoritative, or non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)](https://support.microsoft.com/help/2218556). It's unnecessary in most cases, and it may cause data loss if done incorrectly. In addition, it prevents determining the cause of the issue and averting future occurrences of the issue.
What follows are general steps to investigate the missing shares. Determine if the problem is caused by a one-time occurrence, or if the upstream domain controller(s) can't support replication by using DFS Replication.
Deleting the DFS Replication database from the volume shouldn't be required and is discouraged. It causes DFS Replication to consider all local data on the server to be nonauthoritative. By letting DFS Replication recover the database gracefully (as instructed in the 2213 event), the last writer will still win any conflicting versions of `SYSVOL` data.
### Step 1 - Evaluate the state of DFS Replication on all domain controllers
Evaluate how many domain controllers aren't sharing `SYSVOL`, have recently logged an Error event, and how many domain controllers are in an error state. Follow these steps.
- Check for the `SYSVOL` share
You may manually check whether `SYSVOL` is shared or you can inspect each domain controller by using the net view command:
```
For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo
```
- Check DFS Replication state
To check DFS Replication's state on domain controllers, you may query WMI. You can query all domain controllers in the domain for the `SYSVOL` Share replicated folder by using WMI as follows:
```
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
```
The `state` values can be any of:
0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error
Note
Depending on a domain controller's condition, it may fail to report a state value and indicate no instance(s) available.
- Check Event logs for recent errors or warnings
If any domain controllers don't report the `SYSVOL` Share replicated folder as being in a state 4 (normal), check the event log of those domain controller(s) to evaluate their condition. Review each domain controller for recent errors or warnings in the DFS Replication event log, such as the warning event ID 2213 that indicates that DFS Replication is currently paused.
- Check the Content Freshness configuration
Determine whether DFS Replication triggered content freshness protection on the affected domain controllers. Content Freshness is enabled on Windows Server 2012 (and later versions) domain controllers by default. However, it may also be manually enabled on Windows Server 2008 R2 servers.
To evaluate if content freshness is enabled, the `MaxOfflineTimeInDays` setting will be set to **60**. If content freshness is disabled, `MaxOfflineTimeInDays` will be set to 0. To check `MaxOfflineTimeInDays`, run the following command:
```
wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
```
To query all domain controllers in the domain, run the following command:
```
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
```
For each domain controller enabled for content freshness, evaluate if DFS Replication has logged an event ID 4012 that indicates replication of the folder has stopped because replication has failed for longer than the `MaxOfflineTimeInDays` parameter.
### Step 2 - Prepare the domain controllers that are in an error state
- Install appropriate updates
For any domain controllers running Windows Server 2008 R2, first install DFS Replication updates to prevent data loss and to fix known issues. It's a best practice to use the latest version of DFS Replication. See [List of currently available hotfixes for Distributed File System (DFS) technologies](https://support.microsoft.com/help/968429) for the latest version of DFS Replication.
- Back up `SYSVOL` data
Do a backup of `SYSVOL` data (if present) on each domain controller. Backups may be a file copy of the `SYSVOL` contents to a safe location or, it may be a backup that uses backup software.
Depending on the situation, policy files could be moved to **PreExisting** or **Conflict and Deleted**. **PreExisting** and **Conflict and Deleted** contents will be purged if initial synchronization is done multiple times on a server. Back up data in these locations to avoid data loss.
### Step 3 - Recover DFS Replication on the domain controllers in the error state
Based on the number of domain controllers in the domain, select the appropriate method to recover the DFS Replication service.
#### For environments that have two domain controllers
Determine whether a dirty shutdown was detected (event ID 2213) on either domain controller. You may find the second domain controller is waiting to complete initialization of `SYSVOL`. The reason is, after promotion, it will log a 4614 event that indicates that DFS Replication is waiting to do initial replication. In addition, it won't log a 4604 event signaling that DFS Replication has initialized `SYSVOL`.
- If content freshness is enabled on both domain controllers
If the second domain controller waits to do initial synchronization (event 4614 logged without the 4604 anti-event), follow the [How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)](https://support.microsoft.com/help/2218556) to set the first domain controller as authoritative. You don't have to configure the second domain controller as nonauthoritative, because it's already waiting to do initial synchronization.
Or, if the second domain controller is healthy and `SYSVOL` is shared, take the following steps:
1. Back up all `SYSVOL` contents of the first domain controller.
2. Evaluate if the second domain controller's `SYSVOL` data is up to date. If not, you may want to copy updated `SYSVOL` files to the second domain controller from the first domain controller. Otherwise, any existing data present on first domain controller not present on the second will go into the **PreExisting** and **Conflict and Deleted** folders.
3. Set the first domain controller as nonauthoritative by disabling the membership per [How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)](https://support.microsoft.com/help/2218556). Confirm that an event ID 4114 is logged to indicate the membership is disabled.
4. Enable the first domain controller's membership, and wait for the 4614 and 4604 events that report completion of the initial synchronization. If necessary, restore any updated files from PreExisting to the original location.
- If content freshness isn't enabled or triggered on both domain controllers
If the first domain controller is in the event ID 2213 state, and the second domain controller has never completed initialization after it was promoted, and content freshness hasn't been triggered. Take the following steps:
1. Run the `ResumeReplication` WMI method on the first domain controller as instructed in the 2213 event.
2. After replication resumes, it will log an event ID 4602 that indicates that DFS Replication initialized the `SYSVOL` replicated folder and specified it as the primary member.
3. Run the `dfsrdiag pollad` command on the second domain controller to trigger it to complete initial sync (event ID 4614). As soon as initial sync is finished, event ID 4604 is logged, signaling `SYSVOL` has completed initialization.
Or, if the first domain controller is in the 2213 state and the second domain controller is healthy (`SYSVOL` is shared), run the `ResumeReplication` WMI method on the first domain controller. It will log event ID 2214 at the completion of dirty shutdown recovery.
#### For environments that have three or more domain controllers
Determine whether a dirty shutdown was detected and whether DFS Replication is paused on any domain controllers (event ID 2213). You may find a domain controller is waiting to complete initialization of `SYSVOL` after promotion. It will log a 4614 event that indicates that DFS Replication is waiting to do initial replication. It also won't log a 4604 event signaling that DFS Replication has initialized `SYSVOL`.
- If content freshness is enabled, and there are three or more domain controllers in the domain.
Content freshness protection will log an event ID 4012 that indicates that replication has stopped because replication on the folder has failed for longer than the `MaxOfflineTimeInDays` parameter. To reinitialize DFS Replication on the affected domain controller(s), follow the instructions in [How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)](https://support.microsoft.com/help/2218556).
If all domain controllers have logged the 4012 event and their state is 5, follow the instructions in [How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)](https://support.microsoft.com/help/2218556) to completely initialize `SYSVOL`. It's the only situation to set a DFS Replication server as authoritative. Make sure that the domain controller configured as authoritative has the most up-to-date copy of all `SYSVOL` contents.
Or, if one or more domain controllers are blocking replication because of content freshness, they each must be non-authoritatively recovered. Follow these steps:
1. Back up all `SYSVOL` contents of the domain controller(s). Typically, policy edits are done on the PDC Emulator, but it isn't guaranteed. Any data present on the recovered domain controller(s) not matching the partners will go into the **PreExisting** or **Conflict and Deleted** folder, or both.
2. Set the domain controller(s) as nonauthoritative by disabling the membership, as described in [How to force an authoritative and non-authoritative synchronization for DFSR-replicated `SYSVOL` (like "D4/D2" for FRS)](https://support.microsoft.com/help/2218556). You must be aware of the replication topology, and you must fan out from a healthy domain controller by selecting direct partners of it, then recovering further downstream domain controllers, and so on. Event ID 4144 will be logged to confirm the membership is disabled. Make sure all domain controllers requiring recovery log the event. It may be necessary to force Active Directory replication and then run the `dfsrdiag pollad` command on each domain controller to detect the disabled membership quickly.
3. Enable the membership and wait for the 4614 and 4604 events to report completion of the initial synchronization. Restore any required files from backup or from **PreExisting** and **Conflict and Deleted** as necessary.
- If content freshness isn't enabled or triggered, and there are three or more domain controllers in the domain
If content freshness protection isn't triggered, run the `ResumeReplication` WMI method on the affected domain controllers. You must be aware of the replication topology, and you must fan out from a healthy domain controller by selecting direct partners of it, then recovering further downstream domain controllers, and so on. After replication is resumed, DFS Replication will log events 2212, 2218, and then 2214 (indicating that DFS Replication initialized the `SYSVOL` replicated folder).
### Preventing future occurrences of the issue
Check whether the Application and System event logs are frequently reporting ESENT database recovery operations, disk performance problems, or both. The event logs typically coincide with unexpected shutdowns of the system, with DFS Replication not stopping gracefully, or disk subsystem failures. Consider updating the system's drivers, installing appropriate updates to the disk subsystem, or contacting the system's hardware manufacturer to investigate further. You may also contact Microsoft Customer Support Services to help evaluate the system's health and DFS Replication behavior.
The Service Control Manager (SCM) uses the default time-out time of 20 seconds for stopping a service. In some complex DFS Replication implementations, this time-out value may be too short, and DFS Replication stops before the appropriate database is closed. At service restart, DFS Replication detects this condition, and then does the database recovery. WaitToKillServiceTimeout may be used to grant DFS Replication more time to commit changes to the database during shutdown. For more information, go to article [You receive DFSR event ID 2212 after you restart the DFSR service](https://support.microsoft.com/help/977518).
After you have restored DFS Replication of `SYSVOL`, DFS Replication health must be carefully monitored in the environment to prevent this scenario. Regular review of DFS Replication event logs, collecting of DFS Replication health reports, and collecting of replication state (by using the WMI query in the Check DFS Replication state section under [Step 1 - Evaluate the state of DFS Replication on all domain controllers](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-missing-sysvol-and-netlogon-shares#step-1---evaluate-the-state-of-dfs-replication-on-all-domain-controllers)) are recommended.
# How to force authoritative and non-authoritative synchronization for DFSR-replicated sysvol replication
[https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization#how-to-perform-an-authoritative-synchronization-of-dfsr-replicated-sysvol-replication-like-d4-for-frs](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization#how-to-perform-an-authoritative-synchronization-of-dfsr-replicated-sysvol-replication-like-d4-for-frs)
## Summary
Consider the following scenario:
You want to force the non-authoritative synchronization of sysvol replication on a domain controller (DC). In the File Replication Service (FRS), it was controlled through the **D2** and **D4** data values for the `Bur Flags` registry values, but these values don't exist for the Distributed File System Replication (DFSR) service. You can't use the DFS Management snap-in (Dfsmgmt.msc) or the Dfsradmin.exe command-line tool to achieve this. Unlike custom DFSR replicated folders, sysvol replication is intentionally protected from any editing through its management interfaces to prevent accidents.
## How to perform a non-authoritative synchronization of DFSR-replicated sysvol replication (like D2 for FRS)
1. In the ADSIEDIT.MSC tool, modify the following distinguished name (DN) value and attribute on each of the domain controllers (DCs) that you want to make non-authoritative:
```
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=
msDFSR-Enabled=FALSE
```
2. Force Active Directory replication throughout the domain.
3. Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
```
DFSRDIAG POLLAD
```
4. You'll see Event ID 4114 in the DFSR event log indicating sysvol replication is no longer being replicated.
5. On the same DN from Step 1, set **msDFSR-Enabled=TRUE**.
6. Force Active Directory replication throughout the domain.
7. Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
```
DFSRDIAG POLLAD
```
8. You'll see Event ID 4614 and 4604 in the DFSR event log indicating sysvol replication has been initialized. That domain controller has now done a **D2** of sysvol replication.
## How to perform an authoritative synchronization of DFSR-replicated sysvol replication (like D4 for FRS)
1. Set the DFS Replication service Startup Type to Manual, and stop the service on all domain controllers in the domain.
2. In the ADSIEDIT.MSC tool, modify the following DN and two attributes on the domain controller you want to make authoritative (preferably the PDC Emulator, which is usually the most up-to-date for sysvol replication contents):
```
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=
msDFSR-Enabled=FALSE
msDFSR-options=1
```
3. Modify the following DN and single attribute on **all** other domain controllers in that domain:
```
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=
msDFSR-Enabled=FALSE
```
4. Force Active Directory replication throughout the domain and validate its success on all DCs.
5. Start the DFSR service on the domain controller that was set as authoritative in Step 2.
6. You'll see Event ID 4114 in the DFSR event log indicating sysvol replication is no longer being replicated.
7. On the same DN from Step 2, set **msDFSR-Enabled=TRUE**.
8. Force Active Directory replication throughout the domain and validate its success on all DCs.
9. Run the following command from an elevated command prompt on the same server that you set as authoritative:
```
DFSRDIAG POLLAD
```
10. You'll see Event ID 4602 in the DFSR event log indicating sysvol replication has been initialized. That domain controller has now done a **D4** of sysvol replication.
11. Start the DFSR service on the other non-authoritative DCs. You'll see Event ID 4114 in the DFSR event log indicating sysvol replication is no longer being replicated on each of them.
12. Modify the following DN and single attribute on **all** other domain controllers in that domain:
```
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=
msDFSR-Enabled=TRUE
```
13. Run the following command from an elevated command prompt on all non-authoritative DCs (that is, all but the formerly authoritative one):
```
DFSRDIAG POLLAD
```
14. Return the DFSR service to its original Startup Type (Automatic) on all DCs.
## More information
If setting the authoritative flag on one DC, you must non-authoritatively synchronize all other DCs in the domain. Otherwise you'll see conflicts on DCs, originating from any DCs where you did not set auth/non-auth and restarted the DFSR service. For example, if all logon scripts were accidentally deleted and a manual copy of them was placed back on the PDC Emulator role holder, making that server authoritative and all other servers non-authoritative would guarantee success and prevent conflicts.
If making any DC authoritative, the PDC Emulator as authoritative is preferable, since its sysvol replication contents are most up to date.
The use of the authoritative flag is only necessary if you need to force synchronization of all DCs. If only repairing one DC, make it non-authoritative and don't touch other servers.
This article is designed with a 2-DC environment in mind, for simplicity of description. If you had more than one affected DC, expand the steps to include ALL of them as well. It also assumes you have the ability to restore data that was deleted, overwritten, damaged, and so on. previously if it's a disaster recovery scenario on all DCs in the domain.