Windows 2008 P2V Problem and the Active Partition

I was performing a late night p2v of a Windows 2008 server the other night and I ran into an issue that I figured I’d share. This server was initially installed with the help of Dell’s server utility, and as such the first partition on the drive was one of those small utility partitions.

Standard practice during a p2v is to leave those partitions behind. Since the server’s not on Dell hardware any more, Dell’s utilities aren’t going to serve a purpose. Most of my experience with p2v is with Server 2000 and Server 2003 (and in fact, I’ve done more NT than 2008 at this point), and with 2003 I’ve seen those partitions cause more harm than good.

We moved forward with the cookie cutter p2v of the server and the first anomaly was the fact that the utility partition was the Active partition (as opposed to the C: partition with Windows installed). Given that Converter doesn’t give you the option to leave behind an active partition any more (and I do miss that option), we decided to forge ahead with both partitions imaged. The process moved forward, but eventually was unable to reconfigure the VM (most likely because Converter wasn’t able to determine the OS type with which it was working). This left us with an unbootable VM, as you’d expect.

As far as p2v problems go, this one is fairly common. Converter uses the system’s boot mechanism (usually boot.ini on older OSes) in order to determine what OS it is working with and what volume it needs to reconfigure. This particular system seemed to not have a boot mechanism that Converter understood. In hindsight, and perhaps if we weren’t performing 5 p2v’s concurrently I would have realized this at the time, I should have futzed with the non-reconfigured VM until we got it into a state that Converter would recognize.

Instead, figuring that the problem was caused by that Dell utility partition, we decided to reimage it (it was a small box that only took about 20 minutes to image), sans said partition. Well, remember what I said earlier about Converter no longer giving you the option to exclude an active partition? That’s still true. Of course, changing the active partition in Windows Disk Management is a simple Right Click option. When you do it, it even warns you that this may cause the system to fail to boot…

Well, after we changed the active partition to the second partition (the C: partition) on the drive, we started up converter again. Converter failed to even get started. I’ve seen this before with converter – if you have a conversion that didn’t end correctly, it can get messed up and an easy fix is to just reboot the source machine. So, that’s exactly what we did… forgetting, in our multi-tasking glory, that we had an ‘invalid’ active partition.

Needless to say, that warning message is there for a reason and every pixelated word on it is true. After the server finished its memory checks and started up all of its hardware, we were left with a black screen with the simple message: NTLDR is missing. The thing was not going to boot; I’d just helped to brick a customer’s production server.

We tried a lot of things to repair this misstep. We booted off of a 2008 Server CD and entered the recovery console, which has a limited command line (notably lacking fdisk). We followed several articles and procedures from forums. I explored the fixmbr command. I explored the bcdedit command. Since our issue was of the disk’s unfortunate inactivite state, these commands did us no good. Finally, we pulled out an old partition magic disc and were able to activate the first partition once more. Once it was activated, the system booted just fine and we moved on with the p2v.

Fortunately, my attempts with bcdedit had a positive effect on the project – it created a C:\boot folder with appropriate boot files. With this folder present, Converter was able to detect the OS correctly on our next imaging attempt. With the OS detected and reconfigured, it was a simple 15 minute cleanup process to get it running again as a VM.

The lesson learned? Pay attention when doing something that might render a server unbootable. Preferably (and this is a well-established best practice), don’t change the source machine at all. We really should have experimented with making our initial captured VM bootable and then initiated the reconfiguration manually, rather than focusing on transferring a valid image from the source machine.