Ask a question

Gerry Wieczerza

DFSR Error 4012

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. 
Additional Information: 
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:

As I have no experience with this error I'm looking for guidance on the right thing(s) to do.

Thanks in advance!


  • DFRS
  • Migration
asked08/05/2018 22:46
Add Comment
Mariette Knap

Hello Gerry,

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:

  • Is the old SBS properly demoted and removed?
  • Did you migrate FRS to DFSR before you started the migration to 2016?
The KB article you listed is the correct one to fix this issue. Is there only one DC? In AD Sites and Services do you see more than the active DC's in your setup?
Gerry Wieczerza


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!



replied 08/08/2018 19:27
Mariette Knap

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.

replied 08/08/2018 19:41
Gerry Wieczerza


(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,


replied 08/08/2018 19:54
Gerry Wieczerza


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:

8/8/18      9:02pm

8/8/18      9:09pm

8/8/18      9:33pm

8/8/18     11:05pm

8/9/18       3:05am

8/9/18      11:05am

8/9/18       7:05pm

Not sure what the next step(s) should be so will await your response.

Thanks in advance!


replied 08/09/2018 23:42
Last Activity 11/18/2018 20:44

1 Answer(s)

  • Don Thompson
    Add Comment
    Mariette Knap

    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.

    Gerry Wieczerza


    It was not an issue prior to the migration but had it been, yes - the old way was simplier to address.



    replied 11/18/2018 20:44

    replied 11/16/2018 08:12
    Gerry Wieczerza


    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!


    replied 08/19/2018 20:49
Add an Answer