By sleeper35 - 26 January 2020 6:38 PM
I am going to install a new motherboard, processor and memory on my computer. My C Drive is an m.2 SSD and almost all data is on other drives both internal and external. My first question is about this note in the help file. "Note: ReDeploy modifies an existing offline operating system to work with new hardware. Restore your system image to the PC being deployed before running ReDeploy. There is no need to reboot your PC after restoring an Image and before you run ReDeploy." My drives are all going to remain the same. I will be making backups before I start this process of course, but do I have to restore the backup to the C Drive as the first step in the ReDeploy process even though the data on the drive should be identical to the backup? DO I have to restore that drive just because it is in the sequence of steps leading to the Redeploy? I plan to disconnect all external drives before I start the ReDeploy. Should I leave the internal data drives connected or disconnected during this process?
Next, the help file describes the additional options, but do any need to be enabled except the disable reboot as shown in the image? .I am ReDeploying from an Asus Z97 board with a 4th generation I7 processor to a Gigabyte Z390 with a Core I7-9700K. I would really like this to go well. Do you think I should anticipate any problems?
|
By Drac144 - 26 January 2020 11:27 PM
Always anticipate problems. That will make it easier if you should actually encounter any.
Redeploy works by looking at your current processor/motherboad (so, your NEW one) and making sure the drivers needed to boot your computer are installed on the DISK so when the boot occurs it will LIKELY succeed. you do NOT have to restore to the disk. Change your hardware, boot into the recovery drive and run redeploy. They you will do a normal boot. Your system will probably NOT be working correctly - but it SHOULD boot. You may need to install drivers for graphic cards, USB, and other features located on the motherboard or other new hardware. You will probably have to deal with Windows telling you to register your new version and may have to get a new Key.
I am sure "others" will respond to your post as well and will provide more detailed info.
Good Luck.
|
By jphughan - 26 January 2020 11:41 PM
^ Drac144 is correct. ReDeploy just looks at and works with what’s on disk. It doesn’t care how it got there, and it’s available as a standalone tool in the Rescue environment, so no need to restore anything. And yes, expect to install more drivers within Windows. You MIGHT need to provide drivers to the ReDeploy wizard itself if none of the drivers built into Windows or already otherwise available on your disk will work for boot-critical components, but the newer your version of Windows (you didn’t mention what Windows version you're running), the less likely that will be an issue.
You will however need to make sure your new motherboard’s boot mode — Legacy BIOS or UEFI — matches your old system. ReDeploy does NOT deal with that, because Windows sets itself up on disk very differently depending on whether it will be booted in BIOS or UEFI mode. The former uses an MBR disk while the latter uses a GPT disk and different partition layout. If your old system used BIOS mode and your new system only allows UEFI (or you want to switch to it anyway, which honestly isn’t a bad idea), then Macrium does provide a KB article showing how to perform a custom restore of a Legacy BIOS/MBR environment backup onto a GPT disk such that the restored backup will be bootable in UEFI mode. It involves some prep work on the target disk and some custom partition restore measures. Microsoft also has an MBR2GPT in-place conversion tool, but that can be more finicky.
|
By Froggie - 27 January 2020 12:17 AM
...and if you want REFLECT to work (being properly licensed) on your new configuration, after you take your final image you should copy down your license code then use the "Help/Remove license" function to remove the license from the old System. When the new System is BOOTed up, you can re-register the "saved" REFLECT instalation for the new machine.
Otherwise, it's off to Macrium SUPPORT to work out the license issues...
|
By jphughan - 27 January 2020 12:38 AM
^ I admittedly haven’t tested this, but I don’t think Reflect falls out of activation if the underlying hardware changes. But I guess it can’t hurt to remove the license and add it back later, apart from the small bit of time that takes.
|
By Froggie - 27 January 2020 12:47 AM
JP, I don't know what their license/hardware algorithm is but if they didn't check it, that license would be usable on any machine that image was deployed to... I don't think that's the case.
...but I haven't tried it either 
|
By sleeper35 - 27 January 2020 2:09 AM
+xJP, I don't know what their license/hardware algorithm is but if they didn't check it, that license would be usable on any machine that image was deployed to... I don't think that's the case.
...but I haven't tried it either
I am running a fully upgraded version of Windows 10 Pro and have a digital license linked to my Microsoft account so according to Microsoft I should have no trouble reactivating windows. My old motherboard and my new one both have UEFI BIOS so no problem there. I have probably more than a hundred programs with activation keys but I have a database of all these codes that I have copied to my laptop so if I have to reactivate some of these it should only be an annoyance. Anyone have an opinion about my question of leaving my internal data drives attached or not attached during the ReDeploy?
|
By jphughan - 27 January 2020 3:52 AM
No worries about the additional drives. The first step of ReDeploy is identifying which Windows installation you want ReDeploy to work on, so you only have data on your other drives, there isn’t even any potential for accidentally selecting the wrong Windows installation.
A hundred apps that require activation?? No wonder you want to use ReDeploy!
|
By jphughan - 27 January 2020 5:55 AM
@Froggie, agreed. But if they DID perform a hardware check, then anyone who used ReDeploy to migrate to another system, possibly unexpectedly after a failure, would have to contact Support to deal with a license activation problem, even though using ReDeploy for that scenario is an explicitly supported (and promoted) use case. Not a great customer experience given that you’re using the product as intended. People who mass deploy an image that contains a paid Reflect installation would be violating their license unless they had Reflect licenses for all target systems. Even the System Deployment license that specifically allows mass deployment of Reflect images only allows using paid Reflect to lay down images on systems that don’t have Reflect licenses, not the ability to use Reflect for backups of those deployed systems, at least as I understand it.
So I guess the question is whether Macrium skewed toward clamping down on piracy at the risk of creating inconveniences for people using the product as intended, or toward staying out of the way of legitimate use cases at the risk of some piracy going unchecked. I personally think the cases of people mass deploying an image containing paid Reflect just to get a paid version of Reflect on multiple systems without actually having to pay for separate licenses is probably a pretty small number.
|
By sleeper35 - 31 January 2020 4:32 AM
when someone said prepare for problems they were certainly right. I finished upgrading my hardware and ran the rescue disk and ReDeploy. I did not get a select operating system since I only had the one Windows 10 pro and this operating system name appeared at the top of the ReDeploy screen. From this I imply that ReDeploy could see my windows installation, which was on a Plextor m.2 ssd which I thought was sharing a PCLe channel on my old installation, but the cutouts on the connectors look like a SATA. In any case ReDeploy added a couple of drivers and finished. I rebooted and the Gigabyte Z390 Pro could not find an OS and booted into the UEFI Bios. The BIOS did not recognize the m.2 ssd. I tried both m.2 slots with no luck. This leaves me with a few possibilities 1) the ssd was damaged in moving from one motherboard to another, (2)The ssd cannot be recognized by the new motherboard for whatever reason. In any case a simple ReDeploy is obviously not going to be possible. The old ssd is several years old and is not on the list of approved ssds for this mother board so I have chosen the source of the problem to be (2) and have ordered a new NVMe drive on the approved list (which was a bitch to find) from Amazon. Assuming the bios recognizes it after I install it, I will then run the rescue disk and restore the OS disk from backup. My only question is after the restore to I need to run ReDeploy again or not. Another question; How do I know if ReDeploy ran successfully the first time? Will it run if it doesn't see any operating system? If it did see my OS on my m.2 ssd (which it has been backing up from all along) how did it do it when that drive was on a motherboard that doesn't recognize that drive?
|
By jphughan - 31 January 2020 4:39 AM
If your motherboard doesn't even see the SSD, how did you restore your image onto it in the first place? Did you do that using another PC or external enclosure and then install the SSD? Even if you did that, does the Rescue Media see that disk at all if you check the Backup tab to view all of your disks? If Reflect can't see the disk at all, then ReDeploy definitely won't work. If Reflect DOES see the disk, then your motherboard hardware support isn't the issue. Did you try running Fix Boot Problems after running ReDeploy?
The fact that the motherboard isn't listing your SSD as a boot device doesn't necessarily mean it's not detecting the SSD itself. Some systems that boot in UEFI mode don't list boot options that reside on local storage until the specific bootloader file on that SSD has been registered into the firmware. UEFI systems do not work like Legacy BIOS systems where you just choose to boot from "a device". On UEFI you choose to boot from a specific bootloader file on a specific partition of a specific disk. Windows Setup handles that bootloader registration if you're installing from scratch, but an image restore won't, especially if you did it on a completely different system. But Fix Boot Problems can fix that.
On that subject, make sure your motherboard boot mode matches what's appropriate for your disk layout. If your SSD is set up using MBR, you'd need to boot in Legacy BIOS. If it's set up for GPT, then UEFI is the correct choice.
And on the subject of Fix Boot Problems, make sure you boot the Rescue Media itself in the correct mode for the OS you're trying to fix. If Rescue was booted in UEFI mode, you'll see "[UEFI]" at the end of the title bar at the very top of the display. The reason this matters is because if you boot Rescue Media in UEFI mode, it will attempt fixes appropriate for a GPT disk to boot in UEFI mode. If you boot it in BIOS mode, it will attempt Legacy BIOS fixes. And some motherboards support both BIOS and UEFI boot simultaneously, so it's possible to boot in either mode, which can cause problems.
|
By traver02 - 31 January 2020 9:21 AM
+x^ Drac144 is correct. ReDeploy just looks at and works with what’s on disk. It doesn’t care how it got there, and it’s available as a standalone tool in the Rescue environment, so no need to restore anything. And yes, expect to install more drivers within Windows. You MIGHT need to provide drivers to the ReDeploy wizard itself if none of the drivers built into Windows or already otherwise available on your disk will work for boot-critical components, but the newer your version of Windows (you didn’t mention what Windows version you're running), the less likely that will be an issue. You will however need to make sure your new motherboard’s boot mode — Legacy BIOS or UEFI — matches your old system. ReDeploy does NOT deal with that, because Windows sets itself up on disk very differently depending on whether it will be booted in BIOS or UEFI mode. The former uses an MBR disk while the latter uses a GPT disk and different partition layout. If your old system used BIOS mode and your new system only allows UEFI (or you want to switch to it anyway, which honestly isn’t a bad idea), then Macrium does provide a KB article showing how to perform a custom restore of a Legacy BIOS/MBR environment backup onto a GPT disk such that the restored backup will be bootable in UEFI mode. It involves some prep work on the target disk and some custom partition restore measures. Microsoft also has an MBR2GPT in-place conversion tool, but that can be more finicky.
Hi,
i have 1 image of my old ssd on Windows 10. MBR of course. no way to work with mbr2gpt! if i restore the image to my new SSD empty with GPT partition (same Samsung EVO but bigger, no other HW changes) Reflect convert my image to MBR again......it is crazy and useless. Microsoft does not update the OS anymore unless on GPT. my MB of course supports UEFI. any idea? am i doing something wrong?
|
By jphughan - 31 January 2020 1:44 PM
Have you checked whether the MBR2GPT utility is available inside Rescue? Open Command Prompt and type MBR2GPT to see if you get a response. If so, then you should be able to use it to perform a conversion if you supply the right parameters. Or better yet, follow this Macrium KB article that specifically addresses how to restore a backup of an MBR disk from a Legacy BIOS system onto a GPT disk in a way that will make it usable on a UEFI system.
|
By traver02 - 31 January 2020 3:24 PM
thank you!
i discovered the same kb earlier today.
followed carefully the instructions.
it is done!!!! not it is finally GPT
the only difference i formatted the drive as NTFS, not fat32 (for USB pen)
|
By jphughan - 31 January 2020 3:36 PM
Congrats! Although you really should use FAT32 because most UEFI systems won’t boot in UEFI mode from NTFS sources. The reason is that unlike BIOS booting where boot code is stored in a specified part of a partition and can include a file system driver, a UEFI system has to point to a specific bootloader file, which means it must natively understand the file system it’s booting from without loading any additional code. NTFS support is optional in the UEFI spec and not widely implemented, whereas FAT32 support is mandatory.
You can create a multi-partition flash drive with a small FAT32 partition for Rescue Media and a larger NTFS partition for general purposes storage, FYI.
Also, consider enabling Secure Boot now that you’re booting Windows in UEFI. It’s a nice anti-root measure.
|
By traver02 - 31 January 2020 6:39 PM
i didn't know this
my system is booting fine from NTFS ( MB Asus Z170 pro)
but i am still in time to throw everything away, clean the new ssd again and start from scratch with the FAT32 and the image
my BIOS really is saying Windows Boot Manager not UEFI.
do you think it is worth the effort?
Windows update is working now....no more MBR
|
By jphughan - 31 January 2020 7:11 PM
HOLD ON!!
I didn't mean to suggest that you reformat your Windows volume as FAT32, which you should absolutely not do. I don't think Windows even supports being installed on FAT32 partitions anymore. On disks containing full OS installations that are set up to boot in UEFI mode, there's a small hidden FAT32 partition called an ESP (EFI System Partition), and that contains the bootloader files that then turn around and load Windows. You can see that partition in Reflect itself.
My post was simply saying that you should consider formatting your Rescue Media flash drive as FAT32 for compatibility, because flash drives don't typically have the partition structure I just described above set up. But if you're able to boot from your Rescue Media while it's formatted NTFS in UEFI mode -- verify by looking for "[UEFI]" at the end of the title bar at the very top of the Rescue environment -- then I guess no worries. ASUS might have built a UEFI NTFS driver into their motherboard firmware. Just be aware that you might not be able to use that Rescue Media on other systems, including a system you might find yourself moving to unexpectedly after a failure of that one
|
By traver02 - 1 February 2020 10:49 AM
Hi again and thanks for the support
i guess something went wrong with my first disk Image using the new ssd,
i got I/O error inside Reflect!!!!!!
i had to boot from the Rescue Media and fix the Boot problem
i should submit a support ticket and upload the logs.
BUT from Paramount i am redirected to the Zoho portal where the only option is to login (no register option) , but my Macrium Forum password does not work
i am doing something wrong?
i attach a simple Disk Manager screenshot. 
|
By jphughan - 1 February 2020 2:56 PM
To my knowledge, the support portal and forum do not use a common user credential database, but I'm not sure since I haven't submitted a support ticket in a very long time. Sorry! You can always email support at macrium dot com, fyi.
|
By traver02 - 1 February 2020 3:17 PM
thanks
i wrote to them with Logs and msconfig file, and already received an acknowledge
i have just to wait
.
|
By DanDanz - 10 July 2022 7:25 PM
The support page login is different from the forum. Just create a new login.
|