Some time ago I wrote about my experience recovering a customer’s Active Directory from a USN Rollback condition that had been caused by some virtualisation work.  There has been some discussion in the comments in that post about what to do when you have a single domain controller that thinks it is in a USN Rollback condition (eg has disabled outbound replication and paused the NetLogon service).

Logic would suggest that once a DC knows it is the only DC in the Forest that it would shake off the USN Rollback blues and start humming away normally again.  Not the case unfortunately.

Rob P recently spent some time and effort with Microsoft support and came up with a solution that can be applied.

!!!Warning!!! !!!Warning!!! !!!Warning!!!

I’m not 100% sure why I’m warning you, but I’ll take Rob’s word on the matter.  Apparently this fix is quite dangerous and not for the faint of heart.  My heart is not the least bit faint, particularly when it comes to my VMWare test environment, so I didn’t mind testing this out.  At the very least you should make sure you have a backup of the server you can go back to if this doesn’t work.

To get a single domain controller out of USN Rollback:

  1. Open Regedit
  2. Navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters
  3. Locate the key “Dsa Not Writable”=dword:00000004
  4. Delete the entire key
  5. Enable replication by running repadmin /options servername -DISABLE_OUTBOUND_REPL and repadmin /options servername -DISABLE_INBOUND_REPL
  6. Reboot

Once your domain controller has rebooted you should find that NetLogon is running again and repadmin /options no longer shows replication as being disabled.

I performed this test on a Windows Server 2003 R2 domain controller and I imagine it works fine on Small Business Server 2003 as well.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Hugo Nabais

    I have recovered single DC from backups many times, without having any isues.
    I really don’t understand why you found replication problems, since you don’t even have any replication going on!

  2. Paul

    Delete bit 4 worked for me in a 2 DC environment. Happened on a restore from a Datto.

    1. Jonathan

      I had the EXACT same scenario in June….Restore from Datto on a 2008 R2 DC….

      This solved the issue.

      Jonathan

  3. Carl

    Worked great for me. I had 1 of my 4 2008R2 domain controllers stuck. I followed your procedure, way easier then doing to full demote option, and it worked. I got it back up and running then restarted the other 3 to be safe and then verified everything was working again. Thanks for posting this.

  4. Andrei

    For 2008R2 works perfect Thank You Paul ! 5+ STARS ☆☆☆☆☆ 🙂

  5. Greg

    amazing sir, you saved some branches of our company <3

  6. kirtan

    working for me thanks…

  7. Jonathan

    Thank you so much! For us it worked fine even with two domain controllers one SBS 2011 and one 2012R2. As you said its not for the faint of heart and we did it first with VM clones and then in the production. At the end of the day the replication works again and we didn’t have to go through the procedure of changing FSMO’s and the rest.

  8. Rudi

    Thank you very much from indonesia!! berhasil, berhasil!!

  9. Danny Quevillon

    Not working for me it seems the dc wont let me log back in after the procedure…

  10. flow

    Worked for me. Updated the PDC to 2008R2, the second DC hiccuped, this fixed it. thank you

  11. phyoe

    Hi Paul,
    That registry key is not found on server 2012 R2, & so what can i do for an alternative ??

  12. Syed Mazhar

    Just fixed server 2008 R2, i was going round and round in circles until you saved me.

    ManyThanks

  13. Dmitry Barsky

    Thank you so much, you are a genius!

    I had this exact problem after restoring a DC in my lab from a Veeam Backup. I went thru this process and after rebooting my main DC and the secondary DC everything worked perfectly.

  14. JelleK

    I also had this problem, snapshot revert on DC. Result : no recplication.

    Followed instructions, worked!

  15. Chrisg

    THANK YOU!! this saved my a$$

    Just in case anyone else runs across this article as I did…
    I restored an SBS2011 server from a Vmware snapshot after a failed batch of updates which left the server unable to log in and so ended up in the “USN – rollback” state.

    I followed your instructions and things are back to normal!

    Thanks so much!

  16. Chris

    We just tried this on a 2008r2 DC with Exchange 2010 (we inherited it this way) and it worked great. Now we’re in the process of moving Exchange off the DC as this is best practice.

  17. Rupe

    Many, many thanks for posting this fix. Been scratching around for days trying to unpick a Win2k3 VM DC snapshot restore and this was final piece in the jigsaw!
    Why oh why do M$ make this sort of thing so difficult?

  18. Gianfranco Cini

    Great solution, it worked perfect on my w2003 domain controller
    THANKS

  19. Ken Rudd

    Worked like a charm on a 2008 DC. Note that, while this was the only DC in the domain, it was a child domain in a forest with a root domain and one other child.

    This was the result of a Virtualization re-home

    Woot, thanks again!

  20. Justin

    So after performing this procedure, your DC replicates again. However, you now have a DC in a state where is potentially has many objects or attributes missing from it. (and they won’t be replicated back because other DCs think this one is up-to-date) Some bad advice here… The quarantine put into place was meant to prevent the DC from replicating again for a reason.

    1. Paul Cunningham

      Justin, the title of this article is “Recovering a Single Domain Controller from a USN Rollback”.

      There are no other DC’s in this scenario.

  21. Mirco

    Thank Thank Thank You
    This Workaround saved my entire weekend…
    My Family thanks.

  22. Tarek

    Thank you ,Fixed my problems

  23. Happy GoLucky

    You are a life saver! Fixed my problems and I’m back in business.

  24. Michel Bitton

    Thank you for this fix. I am dancing for joy since my DC running exchange 2003 server got messed up (twice actually) first by a hard drive failure and using a partition restore and a month later trying to migrate the physical machine to an ESX VMware server and I was greatly concerned by how to handle this.

    May the schwarz be with you!!!!!

    Michel.

  25. Dan

    Have similar issue based on a dc snapshot restore on VMWare. See the key, however this is a Server 2008 Standard …anyone know if same applies…

    1. Paul Cunningham

      Hi Dan, haven’t hit this problem with Server 2008 in the field yet so not sure how different it is, it at all. If you find anything out please let us know!

  26. Ryan

    Had this problem after restoring from snapshot an AD DC on VMWare.

    Did all steps as stated and it worked. At first there was some replication errors but they got sorted out automatically.

    Thanks!

  27. Qazi

    Hi,

    Just to let everyone know that I tried the above solution and it did work for us in a live environment! I would however suggest that anyone attempting this should backup the server and AD and the registry before attempting anything. Good luck.

  28. Qazi

    Hi,

    I recently had this issue on our site where we had two domain controllers, one on a physical machine and the other a virtual machine (running on ESX). We were in a situation where the AD would not allow anyone to logon because of replication and USN errors. I followed Microsofts solution and forced one DC down but was unable to get it to become a DC again as the USN rollback error starting causing issues (atleast users are able to login). So at the moment we have one DC that has the USN error and I am unable to create a second DC on the domain. I ran the repadmin /showutdvec command and it returned two lines. The first line shows the one DC and the USN number. The second line has a long name (seems like random alphanumeric characters) with a different USN number. Now I am not sure if the second line is the USN of the second DC that we killed. I am not an expert on USN so I am not sure if I should delete this or keep it as it is and try your solution. Any ideas?

    Also, thanks for posting these!! I have been looking for a solution for a week now!!

Leave a Reply