Rescue media from Win10 Home OK for use restoring Win10 Professional on another computer. And, how...


Rescue media from Win10 Home OK for use restoring Win10 Professional...
Author
Message
g2021
g2021
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 8, Visits: 42
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?

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)
Group: Forum Members
Posts: 12K, Visits: 72K
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.


Edited 19 October 2021 5:32 AM by jphughan
g2021
g2021
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 8, Visits: 42
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.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)
Group: Forum Members
Posts: 12K, Visits: 72K
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!

Edited 19 October 2021 7:06 PM by jphughan
g2021
g2021
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 8, Visits: 42
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.



jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)
Group: Forum Members
Posts: 12K, Visits: 72K
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.
Edited 23 October 2021 1:05 AM by jphughan
g2021
g2021
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 8, Visits: 42
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,
g

g2021
g2021
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 8, Visits: 42
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).

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)
Group: Forum Members
Posts: 12K, Visits: 72K
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.
Edited 23 October 2021 5:32 AM by jphughan
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)Macrium Evangelist (18K reputation)
Group: Forum Members
Posts: 12K, Visits: 72K
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.

Edited 23 October 2021 5:43 AM by jphughan
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search