Suggestion: A better way to image Windows system disks

Suggestion: A better way to image Windows system disks

Hi everyone. I've been using the most wonderful Paragon Hard Disk Manager (14 and 15) for a number of years now, and I noticed some time ago that it doesn't quite get disk imaging right on GPT-partitioned Windows drives. Almost, but not quite. The problem lies in the fact that it does not retain the original GPT data (i.e. disk and partition GUIDS, partition names), choosing instead to produce a GPT with new GUIDs, modifying the Windows BCD in the process to make Windows bootable. The problem with this approach is that HDM doesn't seek out and modify other instances of BCD data which could be present on the original disk, pointing to e.g. the Windows Recovery image and/or a manufacturer-specific boot image. As a result these other systems won't boot on the new disk. What's more, HDM will place a generic Windows name as a title for the copied Windows partition in the modified Windows BCD data, naming it simply e.g. Windows 10 whereas it was originally named Windows 10 Pro. It will bloat the original Windows BCD file, leaving the old and invalid BCD data behind. It's a messy (technically: inaccurate) way of restoring a system disk.

This is a somewhat unfortunate situation, as HDM does an excellent job of actually transferring the original partitions, particularly to a smaller disk - a very useful and mostly poorly implemented procedure on other disk imaging software. The automatic resizing option works quite intelligently for instance, producing very rational results. Even the original file system serial numbers are restored. Sweet.

I was able to circumvent the inevitable boot problems caused by the GPT/BCD issue when restoring my original HP Windows system disk by restoring all the BCD files modified by HDM from the original image to their respective partitions/directories and editing the original disk's GPT, including the GPT headers and partition arrays: I took the original GPT and changed only the LBA numbers to their new counterparts, recalculated the new header and partition array CRCs, and pasted these into the primary GPT header. This procedure also produced the secondary GPT header placed at the end of the disk (a copy of the new partition array). I then overwrote the MBR, GPT and secondary GPT header on the target disk with the ones I produced manually, using HDM's disk sector backup/restore function. I did this using a hex editor, a CRC-32 calculator (HashCalc), and about 15 minutes of patience. It's something HDM could perform in a millisecond. I was able to boot Windows, Windows Recovery, as well as the special HP recovery image which is started via Windows Recovery from the target disk after this operation. No need to modify any BCDs, no mess. Everything works as on the original disk (except much, much faster as the new disk is an M.2 SSD vs. the original 2.5" 5,400 rpm drive).

Note that HDM will automatically update the Windows BCD regardless of whether or not the option is selected under Settings when doing a disk restore operation (Settings->Copy and backup options). It does this to make Windows bootable, as it doesn't restore the original GPT data. BCD and GPT data have to match for various systems to boot.

Also note that HDM does not change the partition table in the protective MBR when restoring disk images, putting the end of the legacy partition beyond the disk boundary when restoring to a smaller disk than the original. It's a minor problem that does not affect the GPT boot procedure, and is easily fixed with sgdisk. Technically though this can be considered a bug and I thought I'd mention it here.

Happy disk imaging :)

A minor detail but I forgot to mention that I also copied the bootstrap code from the original MBR, just in case. This also gets changed by HDM for whatever reason.

Cheers :)

Quote:

---

Originally Posted by ParaFox

What's more, HDM will place a generic Windows name as a title for the copied Windows partition in the modified Windows BCD data, naming it simply e.g. Windows 10 whereas it was originally named Windows 10 Pro. It will bloat the original Windows BCD file, leaving the old and invalid BCD data behind.

---

Please disregard this erroneous statement I made in my first post. HDM actually does a fair job of updating the Windows BCD - I didn't notice bloating or an OS descriptor change. I confused HDM with the DOS "bootrec /rebuildbcd" command which does that. Still, HDM won't update all the possible boot entries in the various original BCD files, so that part still holds.

I wish HDM would restore disks the way I described above (i.e. without updating any BCD files). I welcome any thoughts about this.

Cheers :)

I should also clarify that I actually let gdisk build the secondary GPT header since it was easiest to do that. I just copied the new partition array to the end of the disk and left the header empty, and let gdisk take it from there (I meant gdisk in my first post, not sgdisk).

Cheers :)

My monologue continues: To make absolutely sure the target disk is true to the original one should also restore the Windows registry hive files to their original location (Windows\System32\config): HDM also changes some of these as part of the need it feels to reassign drive letters on the target disk. In my case the net effect was the same, but one can never be sure: The source disk could have a special configuration, which HDM would proceed to mess up.

Remember, in a disk restoration/cloning operation we're only trying to produce a copy of the original disk: Any configuration files on the original disk should remain exactly the same. The original system should be transferred as-is, along with any misconfigurations it might have. HDM shouldn't be trying to "fix" the original system by changing configuration files. It should only modify the GPT to acommodate the locations of the new partitions.

Those other operations (i.e. modifying config files) can be optionally done on partition copy/restore operations, where we're actually modifying the configuration state of any systems on the target disk by e.g. adding/removing partitions.

I hope this provides some insight to this subject. I welcome any comments.

Cheers :)

BTW I used the most excellent XXcopy with the /clone switch to identify and restore only those files/folders that were modified by HDM. Just a tip for anyone attempting to do this.

Happy imaging everyone :)