I'll try to keep this short and sweet.  Been maintaining monthly full backups and daily incremental backups for a home-built PC.  The system drive is a 1TB SSD with a GPT.  Computer recently suffered a short and the mobo wouldn't boot.

Built a new machine and used redeploy to populate a new SSD with my old computer's system drive.  System didn't boot at first (error finding an attached device).  Used the Fix Booting Problems in Macrium (defaults).  System boots, but there's multiple issues:

1. Restored drive is now MBR.  Shouldn't this have been GPT?
2. The EFI partition is now mounted with a letter (this is easily resolved by removing the drive letter and a registry key, if needed).
3. Although there is a recovery partition, Windows doesn't see it.  That is, if I act like there's a problem with the computer and try to boot recovery mode, the moment I press F1 to enter recovery, it just reboots the computer and goes right back to a standard load up of the OS.
4. Tried using mb42gpt.exe to convert, but can't find the OS partition.  Marked the partition as active, still didn't work.  Forums also mentioned using REAgentC.exe to confirm the recovery partition is mapped correctly.  Ran REAgentC.exe to confirm recovery partition can be found. Not found.  No way I can find to rebuild it or remap it.

Long and short is a lot of time was wasted trying to get the drive over to GPT, when I believe this should've been redeployed as GPT in the first place.  I eventually gave up and did a fresh install of Windows 10 (at least I still had my files backed up).  I'm hoping I just missed something stupid, but I didn't see any choices or options about how to redeploy the drive.  Perhaps its because I was dumb enough to set it as a dynamic disk on the original PC?

Any assistance on this would be appreciated.  My new PC has backups running, but it's gonna suck hard if ReDeploy doesn't work.  I basically had to install from scratch to get Windows with a GPT (you can't upgrade with an MBR drive running it).

If the original disk was GPT, then after the restore operation before you do anything else, the destination disk should have been GPT, even if the destination was MBR prior to you restoring onto it.  Neither ReDeploy nor Fix Boot Problems would have converted back to MBR, so if after the restore operation your destination disk's partition layout scheme and/or partition layout didn't match the source you restored from, then the focus should have been on fixing that right away rather than accepting that disparity and then trying to find a way to manually convert it back to what you had in the first place.  But fyi whenever you run Fix Boot Problems, it's important to boot the Rescue Media itself the same way that you would boot the OS you're trying to fix. Since you've got a GPT disk (or should), your OS is booting in UEFI mode, which means that you should make sure to boot your Rescue Media in UEFI mode, not Legacy BIOS mode.  You can check how your Rescue Media was booted by looking at the Reflect application title bar along the very top of the Rescue interface.  If it says "[UEFI]" at the end, it was booted in UEFI mode.  If it doesn't, it was booted in Legacy mode.  The way Rescue was booted will determine the types of fixes that the Fix Boot Problems routine attempts, and you don't want to attempt Legacy BIOS fixes on a disk that's meant to be booted in UEFI mode, or vice versa

If you've already gone through a clean install, I'm not sure you'd want to keep troubleshooting this, but if you do, it would probably help to post screenshots of what happens in Rescue Media.  With Reflect 7.2 Rescue Media you can do that by pressing PrintScreen in the Rescue environment, which will pop up a dialog box asking where to save the screenshot file.  If you have a flash drive or external hard drive, that's usually easiest.  The very latest release of 7.2 adds a button to capture a screenshot into the taskbar for convenience, but the keyboard shortcut still works.

EDIT: Just saw your note that your source disk was a dynamic disk.  That indeed might have been a complication.  I've never worked with dynamic disks, but I believe that even in that case, you could have used something like diskpart within the Rescue Media Command Prompt environment to manually set up your target disk as GPT with the desired partition layout and then restored each partition from the source disk into the "shell" partitions you manually created on the destination.

+x

 

jphughan - 30 September 2019 3:46 PM

If the original disk was GPT and you're just restoring to a new disk in the same system, you shouldn't even be using ReDeploy.  You should just be running a standard restore of the entire source disk/image onto the new destination disk.  After that operation, the destination disk should be GPT even if it was MBR prior to that operation (assuming again that the source image/disk was GPT) and Windows should have no trouble seeing your Recovery partition.  If after the restore operation your destination disk's partition layout scheme and/or partition layout doesn't match the source you restored from, then you should be working on fixing that, not looking for a way to convert it back after the fact.

It might help to post screenshots too.  With Reflect 7.2 Rescue Media you can do that by pressing PrintScreen in the Resuce environment, which will pop up a dialog box asking where to save the screenshot file.  If you have a flash drive or external hard drive, that's usually easiest.  The very latest release of 7.2 adds a button to capture a screenshot into the taskbar for convenience, but the keyboard shortcut still works.

EDIT: Just saw your note that your source disk was a dynamic disk.  That indeed might have been a complication.  I've never worked with dynamic disks, but I believe that even in that case, you could have used something like diskpart within the Rescue Media Command Prompt environment to manually set up your target disk as GPT with the desired partition layout and then restored each partition from the source disk into the "shell" partitions you manually created on the destination.

Yup, I'm thinking that it was a dynamic disk had something to do with it.  Also this was to a brand new computer, so redeploy was necessary (shorted the 6+ year-old mobo on the original build).

I'll have to grab a spare SSD and give it a fresh go for screenshots.  I should've saved them, but at the time I just wrote down a few error codes and GTS to try and get the disk to convert.  Hopefully someone from Macrium can confirm/deny that using Dymanic disks is a bad idea.

EDIT: Also I never thought to look at the title bar to see how the system booted from the rescue media (the BIOS will typically state if its UEFI or legacy, and I didn't see either one there).  Good to know that Macrium can tell me which way it booted.  That might explain a lot if it booted wrong.  I can easily try that and see which method shows up.

+x

 

xavierm - 30 September 2019 3:53 PM

Yup, I'm thinking that it was a dymanic disk had something to do with it.  Also this was to a brand new computer, so redeploy was necessary (shorted the 6+ year-old mobo on the original build).

I'll have to grab a spare SSD and give it a fresh go for screenshots.  I should've saved them, but at the time I just wrote down a few error codes and GTS to try and get the disk to convert.  Hopefully someone from Macrium can confirm/deny that using Dymanic disks is a bad idea.

Sorry about the early version of my post that you quoted.  I reread your post and realized that I had misunderstood it, so I've now edited that original post rather extensively.  But fyi Macrium has a KB article specifically about dynamic disks here, including a section for how to restore a dynamic disk to a brand new disk

+x

 

jphughan - 30 September 2019 3:56 PM

+x

 

xavierm - 30 September 2019 3:53 PM

Yup, I'm thinking that it was a dymanic disk had something to do with it.  Also this was to a brand new computer, so redeploy was necessary (shorted the 6+ year-old mobo on the original build).

I'll have to grab a spare SSD and give it a fresh go for screenshots.  I should've saved them, but at the time I just wrote down a few error codes and GTS to try and get the disk to convert.  Hopefully someone from Macrium can confirm/deny that using Dymanic disks is a bad idea.

Sorry about the early version of my post that you quoted.  I reread your post and realized that I had misunderstood it, so I've now edited that original post rather extensively.  But fyi Macrium has a KB article specifically about dynamic disks here, including a section for how to restore a dynamic disk to a brand new disk

Thank you for that!  I'm starting to think more and more that this is due to me potentially booting the CD as legacy (though the BIOS is UEFI).  I'll have to double-check everything.

I'm thinking this had more to do with this being a dynamic disk.  I checked and confirmed last night that the rescue media did in fact boot in UEFI mode, yet it had restored as an MBR.

Looking at the link you'd listed for dynamic disks, I do remember dragging individual partitions over to the target disk (in order of course).  I wasn't really as concerned with restoring as a dynamic disk, just making sure it was set with GPT.   I may have to run through the whole process with a spare drive to list the exact steps.  Thus far though, it doesn't make sense why it would be restored as an MBR.  I had even checked the drive layout and status in the Rescue environment after restore (but before using Fix boot problems), so I don't think the Fix Boot Problems had anything to do with it..

If you drag and drop individual partitions, then if the target disk was MBR or uninitialized beforehand, I believe it will be MBR afterward.  If you decide to do it again, try manually setting up the disk as GPT using the diskpart application you can run inside Command Prompt.  After running the "clean" command to mark the entire disk as empty, run "convert gpt" so that you have a clean GPT disk rather than a clean MBR disk, which is the default.  Then in Reflect, click the "Refresh" link at the top of the "Create a backup" tab view before proceeding so that Reflect rescans your disks.  When you restore to that disk now using a drag and drop method, it should stay GPT.