The Mirror Crack’d
This author figured that mirroring his e-mail drive was solid insurance against data loss. That theory was tested to the max when a drive failed.
I was just getting settled in to answer the overnight e-mail when I discovered a curious thing: The computer where I do 90 percent of my work was locked solid, not responding to the keyboard or the mouse. After a bit of futile pounding on the keyboard, I rebooted and then logged in to a system that seemed to be responding very slowly. A bit of poking around in the Event Viewer and Disk Management tools showed me the reason for the slowdown: The mirror set that includes my boot drive was busy re-synching. Worse, the System event log was showing such cheerful messages as, “dmio: Fail to reassign bad block(s) on disk Harddisk0: error 0xc0000010.”
OK, so this was a nuisance, but not a disaster. I congratulated myself on having the foresight and paranoia to keep my e-mail on a mirrored drive and went out to buy a replacement for the failing disk. A bit later I was home with a new 80GB drive and a simple plan: Break the mirror, add the new drive, rebuild and all would be well. I figured I’d be done in half an hour, tops.
My development machine is set up with its boot drive as e: and no c: drive (you’d be surprised how many software bugs this arrangement catches). So, knowing that drive 0 (zero) was failing, I wanted drive 1 to remain the e: drive after breaking the mirror set. Windows Server 2003 help says, “The volume copy you click to break the mirrored volume retains the drive letter or mount point, while the other volume is assigned the next available drive letter.” So I clicked on drive 1, told it to break the mirror…and was suddenly looking at drive 0 remaining e: while drive 1 became c:. Apparently things don’t work as documented, at least on the boot volume. And, of course, there’s no “undo” in Disk Management.
Not knowing what else to do, I shut down the computer, removed the failing drive, stuck in the new one and turned the power on. The computer happily informed me that there was no disk in drive a: and no boot device on the SCSI chain (I’m using IDE drives in this box). That wasn’t excessively helpful. After repeating the steps with the same result, I tried just booting with the original drive 1 in place and the new drive not attached. That, at least, got me to the Windows login screen.
It sure didn’t want to get me any further than the login screen, though. I could hit Ctrl-Alt-Del and type in my password, and the computer would repaint the screen and play the happy “Welcome to Windows!” sound. Then…it went right back to the login screen. This wasn’t encouraging.
Faced with a previously-unknown symptom, I did what any MCSE would do and searched the Knowledge Base. Somewhat to my amazement, this turned up article 249321, “Unable to Log on if the Boot Partition Drive Letter Has Changed,” which described the problem perfectly. For resolution, it led me to article 223188, “HOW TO: Restore the System/Boot Drive Letter in Windows,” which has a step-by-step procedure for using regedt32 and regedit (yes, you need both) over the network to fix the problem.
Fortunately, I’ve got a lot of other boxes on my test network, so I was able to get in to the Registry and change the drive letter back to e:. With that change, the machine booted, and I was able to log in. Of course, the problem remained: Now I had a non-mirrored drive and a new drive sitting on the desk. Why wouldn’t they both coexist happily?
It was about three reboots later that I finally did what should have
been obvious and checked the jumpers on the drives in question. Though
the new drive was set up for “cable select” (like just about any other
drive sold in recent memory), it turns out that the old one was actually
jumpered to “slave.” This proved to be an unworkable combination for identifying
a boot drive. I moved the old one to cable select as well, made sure it
was on the master position of the cable, and the box booted just fine.
Then, it was just a matter of waiting half an hour for the mirror set
to rebuild…two hours later than my original optimistic estimate.
About the Author
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.