To resolve the issue, boot into Windows RE (stands for Recovery Environment). When you reboot the server, you’ll get two options. One to “Start Windows Normally”, the other says “Launch Startup Repair (recommended)”. Choose Startup Repair. After entering the local Admin password (which on Domain Controllers is the AD restore PW), you’ll see a Window with a few options. Click Command Prompt to open a DOS prompt Window.

At the DOS prompt, DIR C:. You will probably see volume information that says System Reserved and no files. If you do see a Windows directory on the C: drive, then you probably do not have the problem described in this article.

At the DOS prompt, enter REGEDIT. This will open the Registry Editor. Browse to HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. Look for the values named \DosDevices\drive letter:. We need to find the boot partition’s drive letter. It will usually be assigned the first available drive letter after C: From the command prompt, perform a directory listing of each drive letter after C: until you find the drive with the \Windows and \Users directories. This is the real C: drive. Note its drive letter.

In Registry Editor, rename the value \DosDevices\C: to \DosDevices\J: (or any other available letter). Next rename the value representing the real C: drive to \DosDevices\C:.

Reboot your computer and you’re all set. We still attempting to determine what’s causing this, but following these steps will get a Windows server having this issue up and running promptly.

Bill Gross, Technical Services Director
MCSE: Security, RHCE, VCP4
IT Solutions Consulting, Inc.
http://www.itsolutions-inc.com

8/9/2011 Update:

We still have no idea what’s causing this issue, but it’s happened on a few more of the domain controllers we manage. Fortunately, using this method we’ve been able to get them up and running pretty quickly. That being said, I discussed this with a colleague, Mike Brehm, who pointed out that when I run regedit from the Recovery Environment, I’m actually editing the Recovery Environment’s registry, and not the Windows installation’s registry. (The Windows installation’s registry can be opened by running a reg add command). The server Mike was working on was not fixed by the Regedit trick, instead he booted into AD Restore Mode and reinistalled VMware tools. That resolved the issue in his instance. Other servers experiencing this problem have been fixed, at least temporarily, using the Regedit method, though sometimes the engineers implementing the solution had to try it a couple of times. I used the fix on two servers, it worked the first time on both, but the issue did recur on one.

So, we now have an intermittent problem of unknown cause, that can apparently be resolved by a trick that, based on our understanding of Windows, shouldn’t work.

All servers experiencing this problem have been Domain Controllers running Windows Server 2008 on ESX and ESXi 4.1. So, maybe it is does have something to do with a VMware driver, and reinstalling VMware tools is a true fix, and whatever happens with my registry fix is pure luck.

1. Windows Server 2008 R2, while an incremental OS upgrade, creates significant testing requirements for Exchange 2007.Because the Exchange 2007 SP2 engineering preceded the Windows Server 2008 R2 RTM, Exchange 2007 SP2 would have had to be delayed significantly to align testing schedules.

2. Because upgrading the server OS underneath an existing Exchange server is not supported, the feedback we have received is that the primary need is to support Windows Server 2008 R2 domain controllers in an existing Exchange 2007 deployment, which we have done.

Although these are semi-legit reasons, the very fact that the major players for hardware (Dell, HP, IBM ) are shipping with R2 by default presents and interesting dilemma. So you have four choices: Reinstall the non-R2 OS, only install Exchange Sp1, use a non-supported configuration, or use Gmail. The choice is yours.

MS Blog posting:

http://msexchangeteam.com/archive/2009/09/21/452567.aspx