I recently migrated a Windows Server Essentials 2012 R2 install to Server 2016 with the Essentials role. Part of the migration was to migrate all FSMO roles, demote the old server, and uninstall Active Directory on the old server. All that worked successfully. However, after 60 days, I started getting this error on the new server:
Log Name: DFS Replication
Date: 12/31/2018 1:00:33 PM
Event ID: 4012
Task Category: None
The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for 69 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.
To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.
Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: D4AE3BB1-99D5-4486-9B2A-1AF6EC43BDD5
Replication Group Name: Domain System Volume
Replication Group ID: D68D4AD7-7B35-47EE-B62B-3A01E482D74A
Member ID: 1983E86A-36B2-4D15-AD9E-13372CC44EB5
This Spiceworks thread discusses the same issue. The solution is to do an authoritative (“D4”) DFSR sync as described in KB2218556. Unfortunately, that article is a bit high-level. This blog post [now from archive.org] has more detail. But both are written with the assumption that you have multiple domain controllers. Since we have only one DC, much of it does not apply. Here is an abbreviated set of instructions for a single-DC authoritative (like “D4”) DFSR sync (use at your own risk!):
1. Stop the DFS Replication Service:
net stop DFSR.
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 contents):
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
Here is where you will find that key:
3. Start the DFS Replication service:
net start DFSR. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.
4. On the same DN from Step 2, set:
5. Force Active Directory replication throughout the domain and validate its success on all DCs. Probably not necessary, since there are no other DCs, but I ran this command from the blog post:
repadmin /syncall /AdP
6. Run the following command from an elevated command prompt on the same server that you set as authoritative:
You will see Event ID 4602 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done a “D4” of SYSVOL.
The KB article doesn’t say whether you should leave msDFSR-options=1. I didn’t change it back from 1, but it seems it changed itself back to 0 somewhere during the above process.
Update June 4, 2019
Needed this procedure again on a migrated server. Today, the original value of msDFSR-options was “not set” and after the procedure, it was still set to “1”. I manually cleared it at the end so it once again shows “not set”.
Update March 17, 2021
The blog post I cited is no longer on kyytko.pl, but I found a January 7, 2019 snapshot (probably what I used when I wrote this) on archive.org: https://web.archive.org/web/20190107104909/http://kpytko.pl/active-directory-domain-services/authoritative-sysvol-restore-dfs-r/. I’ve update the references above.