DFSR Error 4012 on Stand-Alone Domain Controller

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
Source:        DFSR
Date:          12/31/2018 1:00:33 PM
Event ID:      4012
Task Category: None
Level:         Error

Description:

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
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>
msDFSR-Enabled=FALSE
msDFSR-options=1

Click Apply to save your changes.

Here is where you will find that key:

DFSR Sync 1

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. (If you don’t see event 4114, make sure you clicked Apply in ADSIEDIT. Stop and start DFSR again.)

4. On the same DN from Step 2, set:
msDFSR-Enabled=TRUE
and click OK.

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:

dfsrdiag pollad

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. (If dfsrdiag polladfails, see the December 27, 2023 update below.)

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 updated the references above.

Update December 27, 2023

This procedure is still needed when migrating from Server 2016 to Server 2022. However in Server 2022, the DFS Management Tools are not installed by default, so dfsrdiag polladwill fail with “‘dfsrdiag’ is not recognized as an internal or external command, operable program or batch file.” Install the tools with PowerShell (run as Administrator):

Install-WindowsFeature RSAT-DFS-Mgmt-Con

or as a Server Manager feature under Remote Server Administration Tools > Role Administration Tools > File Services Tools > DFS Management Tools. No reboot is required. Thanks to this this post for the tips.

32 thoughts on “DFSR Error 4012 on Stand-Alone Domain Controller

  1. Marcin

    Many, many thanks for this tutorial. At last I have no 4012 DFS errors.

  2. Peter

    Thank you very much for this clear article. You solved my 4012 error!

  3. Simon

    finally, a solution for a standalone DC! I don’t have a clue what I just did, but it seemed to work. Much appreciated!

  4. Robert

    Thank you for a clear procedure that is a great help when in a disaster situation.

  5. Dan Vespa

    Thank you. This did exactly what I needed at a client site!!!!

  6. Bruce

    Well done! I was prepared for a long and lengthy DFS fix when I found my dc wasn’t replicating with an old DC that I removed.
    But I went from 2012 to 2016 server. so slightly different problem
    Thanks, This saved me some time.

  7. Kevin

    Thank you very much for this short and sweet to the point article! You Rock!

  8. Dave

    THANK YOU!!!
    Fixed a 2012 to 2019 migration

  9. Rob

    Man, you are the guy. Amazing article. I have no word to say to thank you so much. I had an old DC which was demoted and migrated to 2019 Server and the actual new DC was showing this event logs. Of course I have just one DC.

    My question is, I didn’t do this step like it is cited in the Blog Post you mentioned :

    Before you will start DFS Replication service, I would suggest to remove all content from those 2 folders

    %WINDIR%\SYSVOL\domain\Policies
    %WINDIR%\SYSVOL\domain\Scripts

    Because I got nervous, this could stop some Group Policy from working fine, this DC is not a LAB.
    Could I stop dfsr again and clean all those folders in Policies and Scripts and start DFSR again. Someone got some event log or any issue after do that step?

    Last question, on the step you told that you didn’t changed the value in msDFSROptions to the original value, I did that too. I left the value 1:

    Thank you for your reply, for the article… many many thanks man.

  10. Mark Berry Post author

    @Rob, I’m too far away from this task now to be clear on whether removing content from those folders would matter. I’m thinking maybe that’s for when you are rebuilding replication across many servers–you could delete the data on the secondary machines that will then rebuild it during replication. If that’s what he’s suggesting, it’s probably not necessary (or advisable) in a single-DC scenario.

    As for the msDFSR-options value, see my June 4, 2019 update at the end of the article. It looks like I was saying, BECAUSE it didn’t revert to 0 like it had the first time, I blanked it out so it would show Not Set. Seems like you would not want that to remain = 1.

  11. Rob

    @MARK BERRY Thank you for the reply, I could see it, the value came back to “0” I just clean the field and it was defined as Not Set.

    How about deleting folders, thank you for clarifying the information, because it’s just one DC.

  12. Brenden

    You are the best, I was running into this trying to add a second DC to a domain that has only ever had one DC. DFS is now replicating SYSVOL and both servers are happy :)

  13. malik

    All day I been dealing with this! This finally sorted me out. Thanks for pulling out the relevant info for a stand alone DC.

  14. TimB

    Mark – thanks much for concise information. You cleared out the undergrowth in the forest! BTW msDFSROptions did roll back to 0. Now a clean Dcdiag, so feel better about dcpromo of new DC.

  15. NoOneSpecial

    5 years later and still helping people. Thanks for the instructions!

  16. Sequoya

    Just used this on two of my standalone DCs previously replicated to older servers that are now offline. Still works great. Thank you!

  17. JP

    Hey Mark,

    This worked for me just now.

    Great job!

    Thanks a lot!

  18. Mark Berry Post author

    @Daniele, LOL! Thanks, that might be the nicest comment I’ve ever received :). Alas, like all mortals, I rely on Google, trial, error, and prayer, usually in that order, to keep the systems running…

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.