Replacing a system drive


Most of our infrastructure is in the ‘cloud’ (Amazon Web Services) but we maintain a couple of machines running Windows 2008 Server with Hyper-V activated so we are able to run and keep multiple test configurations available.

The machine’s drives are mirrored and yesterday morning one of the system drive pair of one machine gave up. The machine has been running for 3 years almost constantly so if one of the pair has failed, there’s a good chance the other will as well. So this was a good time to replace both of them.

We thought the process would be simple: remove the defective drive, get a pair of new drives, install one, boot the machine, break the existing mirror, re-create a mirror using new installed disk then, when it was mirrored, shut down, remove the old drive, install the second new drive, break the new mirror and, finally, create a new mirror between the two new drives. What could go wrong?

Well the first parts went OK (remove the defective drive, get the new drives, install one, boot and break the existing drive). Then things hit a wall. Windows complained that it was not possible to pair the old and new drives because of differences in sector size. What to do?

With hindsight, it’s easy: backup the system drive, restore it to a partition on the new drive, change boot manager so it recognizes the new drive and, voila. At the time, discovering this approach was made much more difficult than it should be because of the dire warning Windows pops up when doing things with drives. After all, we didn’t want to lose everything.

The first issue arises when attempting to back up the system drive. In our environment, the 100MB system drive (boot sector and boot manager) had been created as a partition on a 700GB data drive used to hold virtual machines. The windows backup program insists that the whole 700GB (also mirrored) should backed up if the recovered system is to be bootable. What!? Eventually, we ignored this nonsense and removed the 100MB and 700GB files from the list of partitions to backup. Then were able to move forward.

With the backup complete, we were able to restore the backup onto the new disk we’d installed. The next problem is how to boot from it? Should we use BCDBoot to make it a bootable drive? No. This is not necessary in our environment, the boot sectors and boot manager are on the 700GB partition. The only thing we needed to do to the new drive was make it active. We did it using the option in the disk manager but it can also be done using DISKPART.

The next roadblock is probably unique to our environment. The existing system drives were IDE. The new ones, the existing 700GB data drive and the DVD are SATA. We found out the hard way that although we have 4 SATA sockets on the motherboard, only 2 are active while IDE is active. Eventually we realized it was necessary to disable IDE in the BIOS manager to make all four SATA work.

With all the disks installed the last challenge was to make it possible to boot from the new drive. We couldn’t boot the machine because the one good, bootable drive is IDE and IDE is disabled. The trick here was to boot from the Windows 2008 Server installation DVD. This installs a ‘minwin’ copy of Windows and pauses the installation at the point it asks for locale information. At this point you can press shift-F10 to access a command prompt. This is not specific to Windows 2008. All Windows installers since Vista work this way.

To make the new drive bootable it was necessary to add a new boot record specific to the new drive. This is done using BCDEdit which is available from the minwin command prompt. In our case in minwin the 100MB partition was C:, the 700GB data drive E: (as it should be) and the new drive D:. Here are the commands to make the new drive bootable:

bcdedit /copy {default} /d "A description for this boot option"

This creates a new entry which has a unique id (GUID). This is referred to as {myguid} below:

bcdedit /set {myguid} device partition=d:
bcdedit /set {myguid} osdevice partition=d:

That’s nearly it. These commands tell the boot manager when the new boot record is selected at boot time that its the drive that is D: in the minwin session that should be booted and become C: That is, D: is a relative reference to the current setup, a way to specify a partition to use.

That left the task of creating a mirror between the new drives, removing the old boot loader records and setting a new default boot record:

bcdedit /delete {oldguid}
bcdedit /default {current}

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts

Reader Comments

Sorry, comments are closed.