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:
- Open Regedit
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
- Locate the key “Dsa Not Writable”=dword:00000004
- Delete the entire key
- Enable replication by running repadmin /options servername -DISABLE_OUTBOUND_REPL and repadmin /options servername -DISABLE_INBOUND_REPL
- 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.
June 5th, 2008 at 2:27 am
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!!
June 5th, 2008 at 5:38 am
Hi Qazi, take a look at this http://www.capslockassassin.com/2007/06/02/event-id-2095-and-the-usn-rollback-adventure/ and make sure you’ve followed the procedure to remove the demoted domain controller from the directory with NTDSUtil etc. Once you’ve done that, if your sole remaining DC still thinks it is in USN rollback then I would proceed with deleting the registry key above, but only after taking a full backup of the server.
July 9th, 2008 at 8:07 pm
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.