I upgraded the TNS lab this past week from Windows 2008 to Windows 2008 R2, including replacing the 4 Domain Controllers (rather than upgrading). It gave me a chance to review the procedure for moving a Certificate Server to a new system, which I hadn’t done since 2005. For those who haven’t tried, the procedure for moving a Certificate Server is reasonably well documented at the Microsoft Support site here: http://support.microsoft.com/kb/555012. The part of this that’s especially tricky, especially in our lab, is the renaming of the DC.
In our lab we have an empty forest root, as per the old (Windows 2000-era) Microsoft recommendations, to match several large customer environments. Because it’s a lab, and no clients connect to it, we only have a single DC. I snapshotted it as a backup, and went through the procedure to rename a domain controller, also well documented by Microsoft, this time at TechNet.
For review, the procedure we planned to run was:
netdom computername dc04 /add:dc01.lwtest.corp
netdom computername dc04 /makeprimary:dc01.lwtest.corp
shutdown -r -t 0
netdom computername dc01 /enum
netdom computername dc01 /verify
netdom computername dc01 /rem:dc04.lwtest.corp
I’m still not sure what caused it, but in this case, this command failed:
netdom computername dc04 /makeprimary:dc01.tns.lab
At this point, I couldn’t make the old name primary again (I would get an “Access Denied” error), so I rebooted to see which name had taken. And that’s where things went bad.
When the DC came up, we were getting this error: 
. Source: NETLOGON, EventID: 5602, Data: “An internal error occurred while accessing the computer’s local or network security database.”
Because the DC rename hadn’t completed successfully, the computer couldn’t actually log into itself to load AD. Very bad for the root of the forest. I wasn’t able to find anything helpful in my searches, so thought I’d let you know the fix:
Name it back to the old name and try again:
Reboot into Safe Mode.
netdom computername localhost /makeprimary:dc04.lwtest.corp
shutdown -r -t 0
Boot normally
netdom computername localhost /makeprimary:dc04.lwtest.corp
netdom computername dc01 /enum
netdom computername dc01 /verify
shutdown -r -t 0
After *that* reboot, make sure, with the verify command, that the old name took, and that you can log in, and just try the rename again.
I couldn’t get the “rename back” to take untill after the attempt in safe mode. Strange, but it’s working great now! Hopefully this will help someone.
2012-06-06 at 03:32
Thank you very much for this! This really helped me out with resolving a failed server migration – shame I couldn’t fix this remotely though! The only thing I could do remotely was shutdown /i on another computer so I could remove the troubled server from the equation.
When I ran the command in safe mode it came up with an error (but didn’t say what it was), but after this when I rebooted back into the normal environment I was able to rename the server okay.
Thanks!
2012-07-05 at 15:08
Thanks so much for this fix, had exactly the same today after renaming a new DC. Although when re-naming in safe mode I got an error about the RPC server not being available, once rebooted it was fine. Netlogon service was running and AD was flying again…..Thanks again.
2013-01-05 at 01:25
You are a life saver. I was doing a new server migration and decided to make things easier by renaming the new DC with the old DC’s name. After troubleshooting that failed attempt for 4 hours I came across your article and it led me in the correct direction. I wasn’t able to do the steps in safe mode as it kept giving me a “network path not found†error. Rebooted in normal mode and it gave me the same error. Modified my DNS server from 127.0.0.1 to the actual server IP on the NIC and it erred once more but didn’t give a description. Rebooted and it came back up normally. I think I’ll leave it alone from here. Thanks again!!!
2016-03-01 at 16:45
Thank you so much. In my case I couldnt login using RDP as well. If you have access to a computer or server in the same domain, you *can* fix this remotely 🙂
Open task scheduler on a different system and connect to the troublesome server.
Schedule one task to set the safe mode boot flag. Do not run it yet!
Create a bat file:
bcdedit /set {current} safeboot minimal
shutdown -r -t 1
Create a second task. You have to time this carefuly. I would advise to schedule this task 5-10 minutes ahead of the reboot.
Bat file 2:
netdom computername localhost /makeprimary:sbs2zus.zus.local > C:\output.txt
bcdedit /deletevalue {current} safeboot
shutdown -r -t 1
Now run the first task. Output will be at C:\output.txt
Using this method I managed to solve this issue remotely 🙂
2016-08-30 at 08:04
Thank you man, you really saved me