Macrium Support Forum

Rescue media from Win10 Home OK for use restoring Win10 Professional on another computer. And, how best to defer Dual Boot Decisions?

By g2021 - 19 October 2021 4:36 AM

Rescue Media
I have two Win10 (1 pro, 1 home) computers and rescue media (DVD) from January 2010. 
   The Win10 Pro computer was dual boot Win10 with Win7 and MOBO has recently died.
   The Win10 Home Computer was a straight upgrade from Win7 to Win10 Home, and (other than dual boot and Win10 Pro version) the two PCs are fairly similar builds.
Question 1, would it be advantageous to create/use a new (recent) rescue media (USB) on the Win10 Home PC for use to redeploy the Win10 Pro machine to a new MOBO (including change in boot drive C: from SATA SSD to m.2 SSD)?
Put another way, does rescue media care if the OS is Home or Pro? I gather the USB would be advantageous for speed assuming Win10 version doesn't matter.

Dual Boot
For the Win10 Pro redeployment it appears, based on my limited review, that creation of a viBoot might be a good option for occasional use of Win7 use instead of a dual boot setup.
If I redeploy only the Win10 Pro drive, how is dual boot set-up retained, or does the boot manager forget about the Win7 drive?
If I want to preserve the dual boot on the rebuilt (new MOBO) redeployed PC, how is that done - or, do I need to redeploy both OS drives and then set up boot manager independent of the redeploy?
By jphughan - 19 October 2021 5:29 AM

Wow, quite a bit to unpack on this one....

The WinPE and WinRE "mini OS" environments that Rescue Media is built on do not have different "editions" such as Home and Pro like the "full" Windows versions do.  So that by itself wouldn't be a reason to build separate Rescue Media.  However, if your Rescue Media is over a decade old, that absolutely WOULD be a good reason to rebuild Rescue Media, since there have been a LOT of fixes and enhancements since then, including some that apply to specifically Rescue Media rather than just Reflect running in Windows, and in fact some that apply specifically to the ReDeploy feature.  And as a general note, while it's not essential to update Rescue Media every single time you update Reflect, you really should update with some sort of regularity.  I don't even know what release of Reflect or Windows PE a 2010-era Rescue Media build would be using, but given that it would predate technologies like UEFI Secure Boot, NVMe SSDs, and I think even native support for USB 3.0, it's unlikely to provide a great experience when used on a new PC.  (You mentioned you're using an M.2 SSD, but there are M.2 SATA and M.2 NVMe SSDs.)  This might also be a good time to switch to using a Rescue Media flash drive, which will boot a whole lot faster than an optical disc and will be much easier to update going forward.

viBoot isn't really meant for maintaining a separate long-term environment.  It's meant for booting Reflect backups as VMs, either for spot testing or for temporarily running a backed up system as a VM on another system if the original system's hardware has died, e.g. due to hardware failure, and it may be a while before that hardware can be replaced/repaired.  But if you instead want a "persistent" Windows 7 environment for occasional use, you'd probably be better off just building and keeping a traditional VM, although that would require its own Windows license.

ReDeploy doesn't deal with dual booting.  Its sole purpose is to tweak the Windows environment so that it loads the necessary boot-critical drivers at startup in order to start properly on dissimilar hardware.  Fix Boot Problems can deal with other types of boot issues, but I don't know if it will deal with dual booting.  That said, under the circumstances I'd strongly encourage you to abandon the dual boot idea.  First, if you have brand new hardware, it might not even run properly on Windows 7.  Your motherboard would have to support UEFI-CSM or Legacy BIOS booting rather than only offering full UEFI booting, but even if that's available, using those capabilities would prevent you from running UEFI Secure Boot, which Windows 7 doesn't support but which is a nice security perk that could otherwise be used with Windows 10.  Your new hardware might also only have drivers for Windows 10, in which case some hardware might function improperly or not at all.  Microsoft itself never officially supported Windows 7 on anything newer than Intel Core 7th Gen CPUs, and unless you're a business paying a lot of money right now, they're not providing any support for Windows 7 at all at this point, not even security updates.  If XP's demise serves as any indication, browser vendors will soon stop providing updates for Windows 7 installations as well.  So Windows 7 is arguably already a bit of a security liability if you plan to connect it to the Internet, and before much longer it's likely to become a functional impediment as the browsers you can get on Win7 will lack support for modern Web standards.

And actually even if you keep only Windows 10, given that your new system would ideally use UEFI booting (and in fact may ONLY support UEFI booting), you'll need to take some manual steps to restore your old system's image such that it will boot in UEFI mode rather than in Legacy BIOS mode as it would have been set up to do on your old system.  Macrium has a KB article showing how to do this here.  The first step about booting into Windows PE means "Boot into Rescue Media".  And then you'd run ReDeploy at the end of all that.  Don't miss the final step of running Fix Boot Problems either.

So, to sum up:
  • Create new Rescue Media built from the latest release of at least Reflect V7, if not V8.
  • Consider making USB flash drive Rescue Media.
  • Make sure your Rescue Media is built on WinPE 10.  If you use WinRE on a dual boot system, you might end up with WinRE 3.1 (Win7 kernel), which won't be ideal when dealing with new hardware.
  • Perform the custom restore steps in the KB article to handle switching from BIOS to UEFI booting.
  • Consider dropping Windows 7 out of the mix and replacing it with a regular VM, not a viBoot setup.

By g2021 - 19 October 2021 6:15 PM

Thank you for a very enlightening and thorough response. I have to admit my huge error in setting down the original rescue media date as ~2010, my sincere apologies for this.

The rescue media I have is from January 2020 (small decade typo not), and it consists of two DVD created on both the 1st PC (RIP) and 2nd PC (built respectively in November 2013, and late in 2014).
From your comments, I can see that the Win10 version (Pro, vs Home) is not material to the Rescue Media creation (either will work properly).
Both PCs were running MR-7 when I created the Rescue Media DVDs in early January 2020.

The 2nd PC (originally Win-7 license, with update to Win-10) is largely a clone of the 1st PC but with no dual boot.
(I'm a former satellite engineer in my mentality - so, having redundancy and alternate units on the assembly line are great tools for diagnostics & corrective actions.)
From the 2nd PC BIOS setup menu, I can see that Win-10 on both PCs would have the set-up of UEFI with a GPT boot disk.
The boot disk on both machines was/is a SATA SSD.
On the 2nd PC I am now upgraded to MR-8, and I have created a Rescue Media Flash Drive for use on the rebuilt 1st PC (or, this 2nd PC if I am very unlucky).

I did a quick review of the KB and will spend more time this afternoon to try to fully understand the instructions. Need to do more homework!
Mindful of the timezone difference GMT to PST, I'm hoping this interim reporting gets through.
I'd like to think that the configuration of both PCs (UEFI, GPT boot disk) means that the Rescue Media defaults to Win PE10 (if that is still necessary) or an alternative to overcome the difficulties/complications the original dual boot would inject into recovery/redeploy.

Very much appreciate the comments on the security deficiencies of Win-7.
Now I recall reading about this and having some concerns.
My original plans were at some point:
1. migrate the original PC Win-19 to a new build, and
2. leave the Win-7 on the old machine, and run the old machine only as a dedicated, air-gap isolated from network connections.
I still want to study about setting up a VM, or alternatively to pick up parts to resurrect the old Win-7 PC.
Either way, I will take your advice to drop Win-7 entirely from this rescue/recovery scenario.

Can you confirm that the Rescue Media (Flash drive) I've created on this 2nd PC (Win-10, UEFI GPT boot disk, MR-8) will avoid problems with injecting the prior dual boot config into the new PC recovery?
Sorry if this seems an impertinent question (RTFM), but I'm juggling errands.

I'm also wondering if a worse-case alternative is to do a clean install of Win-10 with an m.2 SSD as the boot drive. Then, work with MR to restore data files.
By jphughan - 19 October 2021 7:04 PM

Ok, well having Rescue Media from 2020 and being willing to drop Win7 improves the picture rather dramatically! Smile

In that case, you may still want to build new Rescue Media from your currently working system to help ReDeploy the old one that needed a motherboard replacement.  The reason I say this is because Reflect 7.2.4942, which was released in May 2020, contained a fix for ReDeploy.  That fix may or may not matter for your use case, but if it does, then your current Rescue Media that was created somewhere in 2020 may or may not use that release or newer.  If you want to check, you can boot the Rescue Media you originally created from the dead PC where you'll be replacing the motherboard and check the title bar running across the top of the interface, which will contain the Reflect version and the WinPE/RE version you're using.  If it's using an older release, then Rescue Media built on a "foreign" system often works on other systems just fine as long as they don't have hardware that requires drivers that aren't built into the WinPE/RE driver library, so creating current Rescue Media on your working system should work just fine on the system you're resurrecting.  If you find that it doesn't but the older Rescue Media actually built from that dead system works, despite the motherboard replacement, then you may be able to carry the driver packages from that Rescue Media to your newly minted Rescue Media.  But we can get into that more if actually necessary.

But assuming you can get your motherboard-swapped PC booted into a Rescue Media environment that's running Reflect 7.2.4942 or newer AND can see the disk that contains the Windows environment you want to ReDeploy, then this should be fairly straightforward.  Just open the ReDeploy wizard, choose your Windows 10 installation, and let it run.  Then see if Windows boots, possibly even with your dual boot menu intact.  If not, then go back to Rescue Media and run Fix Boot Problems, choosing to target the Windows 10 installation.  Doing that might wipe out your dual boot configuration, but it should at least get Windows 10 working properly.

Good luck!
By g2021 - 22 October 2021 9:41 PM

Back again. Hoping you can help before COB today (and not leave me stranded over the weekend).

I am likely near to having completed a redeploy, but not there yet.
Last we left this I could: (A) try to work with my old version MR7 with MR 7.2 possibly functional (may not matter), or (B) use operating PC to create bootable MR8 Rescue Media.
Untangling what I did may explain why I am now confused, or may find flaws in what I have done preventing a full deploy.

PC1 = old original, now decease with bad MOBO. Good MR Image backups available. All MR work in MR7 (MR7.0).
PC2 = similar (almost clone) of same PC, now operational, upgraded to MR8 from MR7.
PC3 = Reconstituted PC1 with new MOBO, and 1TB m.2 SSD, Can see: back up HDD drive, old boot drive 500GB SATA, CD-Drive, and presently USB.

I couldn't get the USB version using MR8 on PC2 to boot on my New MOBO PC3.
This morning I figured out from other posts here that anti-Virus could be a problem: it was!

But, before we go there, I was able last night to boot PC3 on the MR7.2 CD.
From there, Redeploy was not functional (as you predicted as likely).
I did however note that a drive restore was available, and I restored my 500GB boot drive to the new m.2 1T SSD, with IIRC, default partition settings as set for the older 500GB boot drive.
The reason I mention this is that I chose only the Full backup image for the restore (I now know I should have picked the last incremental instead for most recent file recovery).
I would like to restore/redeploy all the way from the most recent incremental back to the latest full backup.
At the close of last night (late), I think I had a image restored to the new m.2 SSD, but I am not certain.

This morning, I read up on recent new posts such as
"Recovery disk lacks a critical Ethernet driver" which was one of my problems on PC2 trying to create rescue disk, and
another post that you pointing out the problems with antivirus software.
This morning, I was able to create a bootable USB drive with MR8, with my Norton AV turned off.
At first the set up with defaults (maybe left over from yesterday setting) did not function.
I then set the application to use WinRE specifically with other defaults (but I'm not sure if defaults revert to a original MR default if I've been twiddling settings.), and this is now bootable.
So, at this stage, it would appear that I have a partial restore of my W10 OS on the m.2 drive, but PC3 does not boot.
When I go into the Redeploy procedure to overwrite last night's MR7 restore to have a restore including most recent incrementals things get confusing.
Following the user guide on page363/485 I get the exact same image of two OS listing:
Windows 10 Pro, and
Windows 10 Pro (1).
For me, I have been expecting that there would some menu selection for me to Select the target (new) OS drive (the m.2 SSD in my case).
How does MR Redeploy know to which restored OS file (what drive) to recover? Does it assume that last OS that was recovered?
And, what does the above listing with and without "(1)" appended mean? How do I know which to select?
I also played with the restore functionality in MR8, and to try an set up for a fresh restore I used the delete feature in the restore menus for the m.2 drive, and is seems the deletion is prevented.

By jphughan - 23 October 2021 1:03 AM

I don’t know exactly what you’re referring to in some areas of your post above, but if you can boot Rescue Media created on a recent version of Reflect, then use that to perform a restore from the backup you actually want to restore — even if an Incremental, without needing to restore the Full first — and THEN run ReDeploy. If your restore didn’t succeed or you restored a backup you don’t actually want to run with, then solve that problem first by performing a new restore. You don’t have to manually delete anything first, although I don’t know what you mean by “I used the delete feature in the restore menus for the m.2 drive, and is seems the deletion is prevented.” Maybe a screenshot would help there. There’s a camera icon in the Rescue taskbar for that purpose. Store the screenshots on a flash drive or something. And while you’re making screenshots, maybe capture one of the partition layout of the backup you’re restoring and the partition layout of your target disk after the restore completes. But if that goes correctly, after a successful restore of the backup you wanted to restore, go to the ReDeploy wizard. You should then be prompted to choose the Windows environment you want to modify, although unless you have a multi-boot setup, there should really only be one.

And get rid of Norton. Between Windows Defender having improved third-party AV getting more and more bloated in the quest to justify its existence with more “features”, third-party AV causes far more problems than it prevents that Defender wouldn’t have anyway, IMHO.
By g2021 - 23 October 2021 5:07 AM

So close, but no joy yet. Really appreciate your sticking with me on this.

I've got a good bootable MR-8 USB based version of Rescue Media. I have figured out how to restore my PC1 boot C: image to my new PC3 m.2 SSD, (although the m.2 drive letter and title don't seem to make sense, more on this below).

The erase disk question comes up from my days when it made sense (IIRC) to wipe a drive clean, then repartition, and then restore to the clean drive. You can see the Erase in this screen shot

> then solve that problem first by performing a new restore.
I figured out that I can just overwrite the destination disk, and I did this with a new image I created today of the PC1 boot drive (the Evo860 c:\). I did a restore to the PC3 m.2 970Evo you see in the screen shot destination above.

The OS selection question is answered in part by clicking through the "next" menu for each item. Here's the menu:

By clicking next I see that the 1st item "Windows 10 Pro" is the original PC1 C:\ boot drive, the 850EVO SSD, and
the "Windows 10 Pro (1)" item is the restored image on what is listed in the click through menu as the "E:\" drive.
I take it the answer is to select the "Windows 10 Pro" because I want to deploy FROM this drive, TO a destination drive.
This is where I don't get how MR knows which is the destination drive - does it somehow know the new image on what it says is "E" ?

From the next screen shot it looks as if MR redeploy is operating on (note: error symbol) the full backup on G: which was my source image.
This really has me concerned that the process has corrupted my original C:\ EVO860 boot SSD drive - will check after this post.

I also get this odd confirmation log. Includes RAID drivers. I may have installed RAID/IRST vestigial drivers for future setting up RAID on my original build, but I never implemented a RAID.

That said, when I reboot, I get a request to provide Ethernet drivers which I am able to provide from the MOBO vendor DVD and I get a dialog that shows the E drive as the old EVO 860 title (as if the name/title of the drive is part of the restore).

 Here's the Ethernet driver dialog I keep seeing:

I seem to satisfy the dialog request, but it says the file is "removed from the list" -- maybe this was the list of files that MR was missing.

After doing the redeploy I can see the PC3 target 970 Evo m.2 has the image, and the drive is labeled "E" which was the oddity I mentioned at the start of this post -- in one place E is titled the 860 Evo, and here it is the 970 Evo.

When I try to use the Fix Boot Menu should I be changing the Evo 970 path to C:\ to make it a boot drive and eliminate the "(1)" in the title? Pls see next screenshot

I also browsed some earlier the forum post on redeploy and I wonder if my changing MOBO is a license issue. I assumed that somewhere in the MR Redeploy process, or after the new W10 OS was operating and on-line, that I would have to confirm a change in my retail license from the now dead MOBO PC1 to the reconstituted PC3 with new MOBO. I do not at all relish the idea of a full clean install, but if a bare bones minimal clean install to the new m.2 (no other drives attached) would be helpful to simplify this process I would do so. However, how would MR merge the new install and the old image?

Agree on the AV. Irony, I'd like to move to Macrium's Image Guardian, if I can just get back to an operational PC.

Much appreciate your help - sorry to be ragged and writing roughly (little sleep).
Thank you,
By g2021 - 23 October 2021 5:27 AM

Further reflection on your comments:
> prompted to choose the Windows environment you want to modify, although unless you have a multi-boot setup,

So, I think I tried this once and it didn't work (can't be sure now); that is why I went with selecting the 1st Win10 which likely meant I was overwriting my image of the original PC1 boot SSD (or its image). Next, I will check to see if the original SSD can be imaged again, regardless I can use another backup image from a day earlier.

I don't have a multiboot set up -- but, originally I did and I have to wonder if that being in the MBR-type look up tables is causing problems now -- as in, it is buried in the original source Win-10 image(s).
By jphughan - 23 October 2021 5:29 AM

Ok, hopefully I can clear up some confusion here.

First, don't worry about drive letters as shown in Rescue.  They're arbitrary, and the fact that a Windows partition is assigned E in the Rescue Media environment has absolutely nothing to do with what will happen when you boot from that partition.  There's nothing within the data of a partition itself that says, "I should be assigned a certain drive letter".  That's handled by the Windows or WinPE/RE OS, and different instances of Windows and WinPE/RE will operate independently of each other in that regard. 

As for ReDeploy, you don't deploy "from" somewhere "to" somewhere else.  The purpose of ReDeploy is to analyze a Windows environment that exists on some storage device that Rescue can see, then analyze your PC's hardware, and then modify that Windows installation appropriately to be able to boot properly on that hardware, if that Windows environment was originally captured from some other hardware.  It's not moving data from a source to a destination.  It's just making offline modifications to a Windows partition.  That's why you have to perform the image restore first, and THEN start the ReDeploy wizard and tell it to modify the Windows partition that you just restored onto whatever device you restored it onto.  And that's why there's no "destination" you have to choose.  Does that help at all?

I'm still not sure why you're seeing two Windows 10 options in the ReDeploy wizard.  Maybe your restored Windows environment has two BCD entries?  Did you have a secondary BCD entry for something like booting with the Hyper-V hypervisor disabled when needed, or perhaps for the Reflect Rescue boot menu recovery option?  In any case, you would NEVER end up modifying the contents of the backup itself.  Reflect backups are read-only, with the exception of being able to edit the comments starting with Reflect V8.
By jphughan - 23 October 2021 5:42 AM

Ok, I'm noticing another problem here.  You've got a GPT disk there, but you don't have an EFI System Partition.  You've got the MSR partition, which is the small unformatted partition at the beginning, and then you've got the Windows partition and then the Windows Recovery partition at the end.  But you're supposed to have an EFI System Partition directly before the MSR partition.  And that's a rather important partition, because on GPT disks set up for UEFI booting, the EFI partition stores the Windows bootloader.  That's probably why you can't boot, and not having that partition would also prevent Fix Boot Problems from doing all of its work.  It can rebuild a broken or missing BCD, but the BCD lives on the EFI partition, so if you don't have one, then it can't do that.  Given that your image itself shows a GPT disk that lacks an EFI partition, based on the screenshot of the wizard you posted, I'm not even sure how you ever booted that disk.  But in any case you're supposed to have one.

Fortunately it's not difficult to create manually.
  • Open Command Prompt in Rescue from the taskbar and run Diskpart
  • Select the disk you're trying to restore onto, then run the "clean" command to wipe it.
  • Create a new empty EFI partition by running "create partition efi size=100" and then "format fs=fat32 quick"
  • Back in Reflect, go to the "Create Backups" tab and click Refresh.  Confirm that the target disk now shows a small empty FAT32 partition upfront.
  • Now choose to restore the desired image.  Except this time in order to preserve that FAT32 partition during the restore, drag and drop the partitions from the Source disk (i.e. the one contained in the image) down onto the Destination.  So bring down the unformatted MSR partition directly after that EFI partition, then the Windows partition (upsizing it if desired) and finally the Windows Recovery partition.
  • Run the restore.
  • Afterward, go to the Create Backups tab and refresh your view again.  Hopefully you've still got that FAT32 partition, along with the MSR partition, Windows partition, and Windows Recovery partition.
  • If so, run ReDeploy, then run Fix Boot Problems, the latter of which should now succeed.
  • Finally, make sure your new motherboard is actually enabled for UEFI booting.  You can also enable UEFI Secure Boot.
By jphughan - 23 October 2021 5:44 AM

Regarding Ethernet drivers, if you don't need network connectivity in Rescue because you're not trying to back up to or restore from a network location, then you can ignore that prompt.  Reflect by default will tell you if it's missing drivers for any devices you MIGHT need to use in the Rescue environment, but if you don't ACTUALLY need them, then don't worry about it.
By g2021 - 23 October 2021 5:04 PM

Thrilled to have you assisting, esp. with such a thorough and immediate reply.
Got some sleep. Some feedback before I dive in.

> Did you have a secondary BCD entry for something like booting with the Hyper-V hypervisor disabled when needed, or perhaps for the Reflect Rescue boot menu recovery option? In any case, you would NEVER end up modifying the contents of the backup itself. Reflect backups are read-only
I'd prefer to look at data to confirm (best to be skeptical, not guess based upon recollections), but I'm guessing the 2nd BCD entry is (at least) a Reflect Rescue boot menu recovery option.
I would not give up on dual boot being in the mix because I KNOW I had functional (tested, operational) boot options menu with Win10, Win7, and recall that I had a Reflect Rescue boot option (3rd boot option, not tested - I assumed it was functional).
This brings up another interesting point (rather points): I recall thinking I had better update my Rescue CD, but hey this is great to see that MR allows the creation of a recovery boot start up option so let's not bother with another CD/DVD burn.
IIRC, I also thought (not sure if I implemented) to put the recovery boot information on my backup HDD (not on the boot SSD) to have an independent recovery from the boot SSD failure.
At this stage, I'm not sure if such a redirection of the MR Rescue boot file to be independent of boot C: SSD is possible (maybe I just went with a default save to CSmile, but this scenario is why I was so astonished to find myself working with only an insufficient for recovery MR 7.2 DVD (not MR 7.24942 recovery option ).
I mention this because it may be possible to find that MR Rescue boot information on my operational backup HDD, but at this stage I have your instructions to proceed on a more obvious path.

Also, small point: the "clean" command to set up new partition(s) was what I was trying to effect (within MR) when I wanted to delete the m.2 SSD partitions -- to make certain (and clear to me)  that I was restoring a known good image to the m.2 SSD.

Thank you for the very clear discussion of my situation and the very clear instructions on how to proceed.
By jphughan - 23 October 2021 5:09 PM

Happy to help!  If you're not sure what that second option is -- and you definitely don't have a completely unrelated disk installed in that system that ALSO has a Windows installation on it? -- then I'd have ReDeploy tackle the first boot option, since that is overwhelmingly likely to be the default boot entry on the restored image.  And of course worst case you can always restore the image again if ReDeploy and/or Fix Boot Problems send things sideways, and in that case if you do NOT clean the disk first, it wouldn't even take very long because Rapid Delta Restore would kick in and essentially just undo the ReDeploy/Fix Boot Problems changes rather than having to restore all the data.  But if you'll have that manually created EFI partition, you'll need to restore using the "drag and drop" method I described above in order to preserve that partition, otherwise the MSR partition from the image will be restored to the very beginning of the disk, which will blow that EFI partition away.

But I think once you create that EFI partition, run a new restore such that the EFI partition survives, and then run both ReDeploy and Fix Boot Problems, you should be good to go.  Good luck! Smile
By jphughan - 23 October 2021 5:13 PM

Ok, I just took a closer look at your ReDeploy screenshot showing two Windows options.  They're shown on different disks, one on Disk 1 and one on Disk 3.  So that would NOT be a secondary BCD entry for booting from the same disk.  If you want to see what Disk 1 and Disk 3 are, click over to the Create Backups tab.  The disks are numbered there, and the model of each disk is identified.  Hopefully that will help clarify why you've got two options there.  You do need to make sure you run ReDeploy and Fix Boot Problems against the Windows installation on the correct disk.
By DanDanz - 23 October 2021 6:41 PM

g2021 - 23 October 2021 5:04 PM

This brings up another interesting point (rather points): I recall thinking I had better update my Rescue CD, but hey this is great to see that MR allows the creation of a recovery boot start up option so let's not bother with another CD/DVD burn.

I'm reacting ONLY to the quoted comment from @g2021.   The option to boot RESCUE MEDIA from the windows boot menu MUST NOT BE YOUR ONLY WAY TO ACCESS RESCUE MEDIA. It is for convenience only, and is not available when you must restore the very disk that contains the boot menu version.   You have to have a CD/DVD or a USB stick with rescue media installed on it.  Sorry, but you'll have to be bothered. 
By g2021 - 23 October 2021 11:09 PM


Point taken. I previously used to write MR to CD/DVDs, then saw the convenient menu option and lost track.
Thankfully, I have the redundant PC with MR also, and the good advice and help from the forum, so I was able to fabricate a current version rescue USB.

By dbminter - 23 October 2021 11:36 PM

Be sure to test booting the Rescue Media USB and, after Reflect loads, make sure it recognizes all internal and external storage and any networked drives.  Last thing you need is a case where you need Rescue Media, but it doesn't recognize the hardware you need to restore to.
By g2021 - 24 October 2021 12:20 AM


Big revelation thanks to your explanations to educate me. I wasn't holding out (hiding information), but I left out a significant piece of the puzzle because of my recently amplified fear about Win7, and having that previously as a dual boot option.
That is the key point, and a picture tells the story that has been confusing you and me, and I CAUSED the confusion.

Recall, the history of this PC1 as originally a Win7 machine (full retail pro license), to which I added a second machine (full retail pro license) as a dual boot with the W10 being the primary/default boot option.
However (the big fat however), the BCD table resided on the Win7 drive denoted as an EVO850.
For all of our diagnostics, I had never plugged in this Win7 drive for fear of installing drivers etc. and being open and exposed with a network connection to viruses or other malicious actors, so we were not able to see the critical FAT32 partition which was on that drive.

In following your recommendation (Post 23)  to investigate the two drives offered for Redeploy and find out their manufacture/origin etc. via the restore menu; I thought, why not look at all the drives relevant drives? Even the Win7 drive.
Upon plugging in the Evo850 Win7 drive and rebooting, I was back to my standard (3) boot options menu: Win10, Win7, Rescue Media.

My sincere apologies for not thinking through (too cautious about Win7 is my excuse).
The obvious gaping hole (mistaken information) was my stating/thinking the W10 boot SSD was in fact a full-up valid W10 installation -- without the BCD FAT32 partition it isn't/wasn't.

I also went far enough in my investigations with the the Win7 drive active to see that I was running MR v7.3.5925.
So, if I had had the presence of mind to create an external Rescue Key on USB/CD/DVD I would have been in better shape at the start of this MOBO failure recovery campaign.

The only obvious problems with running my dual boot system as it stands now are: the vulnerability of Win7, and the network drivers for the new MOBO are not installed.
I do have some old software that is operable on the Win7 machine, and I likely need it too be able to look into some extensive archiving of business etc. that I did over the years.
You've got me convinced to drop the dual boot on my main Win10 PC -- and put the Win7 on another air-gapped PC build (use scraps of old PC, buy a used MOBO, cobble pieces together).
I could always go back to my dual boot backups as long as I preserve the files as archives somewhere (say independent of my new PC3 backups)
I say this, because there may been some usefulness to have retained the backup images of the dual boot Evo850 drive for the fab of the Win7 only machine.

That leads me to next steps for the Win10 machine we have been trying to recover.
If I've understood your recommendations correctly I can redeploy to the EVO970 m.2 drive which is drive 3 in the prior redeploy menu, or GPT disk 4 in the image above.
Correct me if I am wrong, Redeploy is smart enough to fill in the FAT 32 BCD on the EVO970 m.e on its own, it does not need BCD info off the EVO850 Win7 Dual Boot drive BCD.
So, I should:
       unplug the EVO850 Win drive,
      in the Redeploy menu select the SECOND item listed as Windows Pro (1) for the redeploy and start the redeploy
                (Note: do NOT select the 1st item which was the previous Win10 EVO 860 SSD install without the FAT32 BCD).
      Chose drivers (especially for the LAN from the MOBO CD (alternatively, may have to use this PC2 to get valid current drivers later).
      Run Fix Boot Problems if/as applicable with Fix Boot Menu
      Check UEFI settings. Suspect the EVO870 m.2 will still show NVME (not SATA). Not sure I want to fiddle with secure boot 'til I get myself backed up, updated MR v7 to v8 including Rescue Media.
      If/as required, deal with my MSFT account for my Retail Win10.

I'm taking a break (off to put some netting over our persimmon tree suffering from squirrel predations) before tackling this further.
Meanwhile, I'd be honored to have your advice on the above, but I do realize it is now off-hours on the weekend.

Thank you,

By jphughan - 24 October 2021 12:32 AM

That does clarify things. I’m a dual boot scenario involving dual disks, there will only be one total EFI partition. But if you want the secondary disk to be independently bootable, it will need that EFI partition. If you create it as described, then Fix Boot Problems (not ReDeploy) will populate its contents as needed to support a single boot scenario of the Windows partition residing on the same disk. And ReDeploy should take care of any driver issues. They serve different purposes, and in your scenario you’ll need both. Good luck!