Thursday, March 14, 2013

Domain Controller rebooting into DSRM and no password?

I recently ran into a client whose Domain Controller (was Windows SBS 2011) somehow got stuck in a state where after a reboot it would only go into Directory Services Restore Mode (DSRM).  Normally, I would just log in with the DSRM password, run MSConfig and uncheck the safeboot option responsible for this and reboot.  However, in this case, we did not have the correct DSRM password documented so I could not get to MSConfig or a command prompt.

I vaguely recall being able to use a boot ISO to reset the password for DSRM (which is essentially just a hidden local Administrator on a Domain Controller) but for whatever reason I could not get that to work this time.  Maybe I just didn't try hard enough, or maybe my memory isn't what it used to be and it is just not possible, but I gave up on this and tried something else.

My next thought was, since this was a VM, to open the VMDK with another virtual machine and just edit the BOOT.INI file.  Showing my age here, but BOOT.INI files are old school.  I had totally forgotten about the Boot Configuration Data Store replacing BOOT.INI in 2008 and up.  Wasn't even sure if this would work to begin with but it was now clear it wasn't even an option.

Realizing BCD was in play, however, led me to bcdedit, which I remembered was available from the Windows 2008 R2 installation media's repair console.  In the past I had used it to repair servers that would not boot at all for various reasons, but this time I would use it to clear the safeboot parameter.  So I loaded the ISO into the virtual DVD drive, booted into the repair console, and ran:

bcdedit /deletevalue {default} safeboot

Made sure the command was successful and rebooted.  Viola!  The server came up in normal mode and we immediately reset the DSRM password to what we had documented.

Hopefully this saves someone somewhere some time.

UPDATE:  I just had the same server reboot into the DSRM loop again.  This time, we actually had the password so fixing it with MSConfig was possible.  While in that utility I noticed an option to make the changes permanent so I checked that, applied the setting and confirmed I wanted to make the change.  Hopefully this will make sure the loop does not happen again.