Join our community. Excellent content, great people! Like what you see? Join us for free
Several months after a successful migration from SBS2008 to Server 2016 Std we are now getting an error 4012 on the Domain Controller. There is another Server 2012 that is part of the domain which is not a backup domain controller.
The error states:
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
Replication Group Name: Domain System Volume
After doing some research I found this article: https://support.microsoft.com/en-us/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-fo
As I have no experience with this error I'm looking for guidance on the right thing(s) to do.
Thanks in advance!
The error you see is the DFSR equivalent of the same situation you see a lot on older SBS 2003/2008/2011 with Journal Wrap issues. Those are fixed by using the Burflag setting D2/D4 either on the authoritative server which is the server that actually holds a valid SYSVOL. In most cases that is the SBS.
Some questions before we continue this:
Yes - Have done the Burflag fix in several SBS boxes over the years.
Yes the old SBS was demoted and removed.
Yes we migrated FRS to DFSR as per your migration guide.
Yes there is only one domain controller.
Looking in AD Sites and Services I do see under Sites\Default-First-Site-Name\Servers both the older server name and also the new server name. There is nothing under the old server name. Under the new server name is "NTDS Settings"
I hope this helps!
OK, remove the old server from AD Sites and Services. Also, check all DNS records for possible leftovers and restart DFRS. Check logs again after 24 hours and see if that cleared it. If not, we need to further investigate.
(1) Deleted old server from AD Sites and Services under Sites\Default-First-Site-Name\Servers
(2) Doubled checked every node in DNS and confirmed old server is none existent
(3) Restarted the DFS Replication service
Will check the logs > 24 hours from now and update you on the results.
I believe you may have helped to discover the issue within AD Sites and Services. :)
Thanks and take care,
We are still getting the 4012 Events.
It was about 3:30 ET yesterday that we did the last steps.
Since then the logs for this event took place:
Not sure what the next step(s) should be so will await your response.
Look at https://support.microsoft.com/en-us/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-fo.I followed the section “How to perform an authoritative synchronization of DFSR-replicated SYSVOL (like "D4" for FRS)”. And as I don’t have another DC I stopped at step 10. Then, of course, I found another page which was a bit more through. http://kpytko.pl/active-directory-domain-services/authoritative-sysvol-restore-dfs-r/
I marked this as an answer but I am wondering if you don't check for FRS issues before you start the migration. It is easier to set Burflag to D4 on just the SBS and start FRS. After you migrate to DFRS and introduce more DC's you complicate things.
It was not an issue prior to the migration but had it been, yes - the old way was simplier to address.
I reviewed your second link which did clarify some items in the first link so I proceeded with the steps on the only domain controller (authoritative restore) and everything appears to have ran properly and the error 4012 has stopped.
Thank you for the information which appears to have resolved the issue!