Booting clones on a different computer?


Author
Message
vze26m98
vze26m98
New Member
New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)
Group: Forum Members
Posts: 6, Visits: 331
Greetings-

For my work in audio recording, I moved back to Windows 10 PCs after a long time using Apple computers for these tasks. One thing that was very easy in Apple's world was the ability to do a "clean install" of a specific release of OSX onto an external drive, insert the drive into a different Apple computer, boot, and then have OSX figure out how to configure itself for whatever machine it found itself running on.

I currently have a desktop and laptop PC that are pretty close together in age and configuration, and would love to be able to clone the C: drive of one, install it in the other and boot, thereby mirroring the setup of one PC on the other. In other words, maintain a single software configuration that can become the system drive for both machines through a recent clone of the other machine.

Is this at all feasible, and if so, to what extent? Could someone point me to a reliable discussion of the process that I could read and study?

Thanks! Charles
dbminter
dbminter
Macrium Hero
Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)Macrium Hero (2.3K reputation)
Group: Forum Members
Posts: 1.7K, Visits: 18K
It might work but initially might not be bootable.  You may need to use the Redeploy feature to get it booting again.  However, you could encounter driver problems.  For instance, you may have drivers loaded for a specific system's hardware that isn't in that new target machine.  Conversely, there may be new hardware that Windows detects but there aren't the proper drivers for it.


The way I see it, what you desire is theoretically possible.  As I said, you may need Redeploy to get it booting.  If the restored clone boots on the new machine, then, there's no need for Redeploy, I don't think.  I've never actually tried the feature out so I couldn't say beyond theoretical.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
Windows is nowhere near as nice about this as OS X is, unfortunately.  First, Windows doesn't allow itself to be booted from a hard drive connected via USB, so that will already make it less convenient.  Second, when Windows is first installed, it notes the boot-critical hardware on the PC and then configures itself to just assume that it will always be there rather than enumerating it all at every boot.  This saves time on boots, and of course in most cases that assumption is fine, but it means that if you CHANGE certain hardware, Windows will no longer boot because its assumptions will be wrong and therefore it will be loading insufficient or incorrect drivers for the hardware that's actually present.  ReDeploy is designed to address this, but if the driver library of the Windows environment you're ReDeploying doesn't already drivers for the new system's hardware, you'll be prompted to provide them.  And even after that, your Windows OS itself might fall out of activation when it sees that it's running on different hardware.  That's a Microsoft licensing policy, so there's nothing Reflect can do about that.

I wouldn't count on your vision being feasible in the Windows world, sadly. Sad

vze26m98
vze26m98
New Member
New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)
Group: Forum Members
Posts: 6, Visits: 331
Many thanks to both of you for your kind and thoughtful replies. I should apologize as well, for I'd been snagged with reviving my login credentials, and didn't really explore what's already been documented here on the forum. Clearly, there's much archived that is just the kind of detailed and authoritative information I'm seeking.

Windows' behavior is unsurprising, and actually likely the only sane decision to be made in a world where there's no guarantee of what could comprise its processing environment.

I'll continue to explore the method of redeployment, but as the real trouble with keeping the two computers in roughly parallel configuration is the many audio "plugins" that I use--each with their individual installer--perhaps I should be looking at what Windows offers to automate that task.

All the best! Charles Turner



Rootman
Rootman
Talented Member
Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)
Group: Forum Members
Posts: 82, Visits: 1.1K
Sorry to jump in late.  I' in IT and we have laptops and desktops that we replace regularly.  I apply an image of a generic Windows 10 to them so we can give them away and they never fail to boot and find the hardware and supply at least usable drivers.

In Windows 7 I used to have a laptop image and a desktop image.  Prior to that I had to have images for each model of computer.  With Windows 10 I can use the same image for a wide variety of computers.  It might not be quite as good as Apples experience but it has worked well for me. I've even restored an image from a Dell to an HP with success. As long as the boot method is the same (EFI or MBR) I have had very good luck using the same image on a wide variety of computers.I have done this to some really really old PCs all the way up to fairly new ones.

I do a complete disk image and restore it to the PC I am imaging.  As long as they are a common SATA driven computer I usually have no issues.  Throw in a different disk controller type then it will have issues. 

One note, I recently did this to a computer of mine.  I have a media server that needed to be replaced and I was not looking forward to recreating it and setting up all the stuff that was on it.  I backed up the old unit's complete disk and applied it to the new units SSD.  The only issue I had was with Macrium itself.  The old PC still used MBR booting. The disk from the new one had been previously use with a GPT / EFI disk layout.  Macrium failed to mark the OS partition a active, something necessary with MBR but not with GPT / EFI.  I managed to fix it in minutes manually, I could have probably fixed it with Macrium's Fix Boot Problems tool, but I forgot about it. 



jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
@Rootman If you were using the proper method of deploying images, namely sysprepping them first, then it would be expected that an image made on one system would be bootable on another one, because the sysprep "generalize" phase means that the next time Windows boots (in this case, the first time it's booted on a new system), it will perform a full hardware enumeration.  That avoids the scenario I described above, but that is not a typical boot scenario, and sysprepping your system every time you want to move a given Windows installation back and forth between systems on a regular basis isn't practical.  If you weren't sysprepping, then your deployment method wasn't consistent with Microsoft's best practices (or even its supported methods), but you may have gotten lucky not having problems that are still somewhat common.

In addition, if you're working in a corporate IT environment, then there's a good chance you're using volume licensing, i.e. KMS or MAK keys, in which case you'd be able to avoid the Windows activation issues that would normally result from "transplanting" a Windows installation from one PC to another.

(And fyi, there are two boot types, namely BIOS and [U]EFI, and two partition layout schemes, namely MBR and GPT.  MBR is not a boot method, and "GPT / EFI" isn't a disk layout.)

Edited 11 July 2020 8:17 PM by jphughan
Rootman
Rootman
Talented Member
Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)
Group: Forum Members
Posts: 82, Visits: 1.1K
Actually neither is true.  And I am not actually using Macrium in our corporate environment, just at home. At work I use a Macrium competitor that does the same thing, simply backs up the disk and restores it.   Sysprep is actually not needed and is considered by in large depreciated.  We use Windows 10 Enterprise at work, so the key for Windows on the machines label or embedded in the ROM was never used. I install Windows 10 Pro when reimaging them.

I create a generic Windows 10 image on one PC and do not apply a MS license to it, I update it and make a few changes then use our corporate imaging system to back it up.  I then apply the image to each unit being rolled off the inventory.  It takes at least one reboot to get the drivers in order, a very few machines require additional drivers that I have to update.  I then use the WIndows license that is on a label on the machine or use a utility name OEMKey for embedded licenses. None of them are OEM keys, just regular keys.   All of the computers we buy have a Windows license for them, however none are used as we use WIndows 10 Enterprise for corporate machines, this means the license on the machines has never been activated.  Regardless since it is the SAME machine that the license could have been used for and should activate when applied to a new Windows 10 installation on that same machine.  I activate Windows manually using the CHANGE PRODUCT KEY link in the system properties.  In the hundreds of computers I have activated I have only had 1 failure.  I suspect someone at my site stole the Windows activation key and used it on another machine or two.  I just tossed the PC instead of fussing with it. 

It has worked very well for me in hundreds of computers. I have been pleasantly surprised on how well.  It has made by life easier as I can rip these older machines out in minutes now.   In one case I used the same Dell image on an oddball machine of another brand . I figured what the heck, what's the harm in trying?  I stuck the image on it and it booted.  I had to find a few drivers but it was quite function as it was.  This was a very pleasant surprise. I've done this on dozens of different Dell models, desktops and laptops, even tablets, and even used the same Dell image on an HP and a generic machine.  It keeps the machines from ending up in a landfill. I then run a give-away and hand them out to employees. It is also much faster than doing individual Windows installations. 

Recently I used Macrium to migrate my Windows 10 OS from an 9 year old engineering PC I use at home for a home server.  I use it for media streaming and file storage.  We rolled out of inventory a 4 year old engineering PC that had specs that were considerably better.  Since the old machine was MBR boot being that it was a WIndows 10 machine prior to a Windows 10 update.  The newer machine was still able to MBR boot so  I moved the OS over by backing up the old PC and moving it to the new SSD.  The only issue I ran across was Macriums failure to mark the partition active.  Afterward I updated the Windows activation key using the new machines key.  I tried to convert to GPT to EFI with Windows MBR2GPT but it was a miserable failure.  I used Minitool Partition Wizard to do it and it worked flawlessly.I converted to EFI in anticipation that the the next computer I update to will not do MBR boot. 
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
Sysprep is absolutely not deprecated. The idea that it's crucial to change computer SIDs when using other image capture utilities has been deprecated, and it is indeed sometimes possible to get by without sysprep.  I did that myself back in the Windows XP days with Norton Ghost.  But sysprep is still the only Microsoft-supported method for capturing an image for deployment, which is why Microsoft’s own DISM tool won’t capture a Windows image that hasn’t been sysprepped. If you still believe otherwise, please show me any Microsoft documentation indicating that sysprep is deprecated.  The fact that your method is working for you is great -- it works well for others too -- but it does not make it an officially supported method or one that can necessarily be expected to work in other scenarios. I work for Dell on the team that among other things is responsible for building and maintaining all Windows Server gold images used for all Windows-based VMs and physical servers deployed within the organization globally.  We have pretty regular discussions with Microsoft. I think we would know if sysprep was deprecated. Smile

Using embedded/OEM licenses is fine if all systems involved in you’re deploying to (or cloning between, in the case of the original topic) actually have a license for the same edition of Windows. But Win10 Enterprise is licensed exclusively via volume licensing, using either KMS activation or MAK keys. That avoids activation issues, but neither of those licensing methods would be used by individual users.

I’m not sure what distinction you’re drawing between an embedded license printed on the system vs. an OEM license. Are you referring to the OEM System Builder licenses that can be bought at retail?

Even if you reimage your systems before ever booting the OS environment that was pre-installed on them, their included Windows 10 license would have been activated at the factory.
Edited 12 July 2020 4:15 AM by jphughan
Rootman
Rootman
Talented Member
Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)
Group: Forum Members
Posts: 82, Visits: 1.1K
Sorry for upsetting you jphughan but most of the people I am in contact with don't bother with sysprep any more, me included.  It just doesn't do much of anything that is needed any longer..  I know what I'm doing is not 'supported', but it works and since I'm deploying it to out of date unsupported hardware I don't really care. Microsoft doesn't support a lot of things that are done all the time.   I imagine Macrium Reflect is not officially  'supported' by Microsoft either, but that's why we're all here. 

For me I am taking old systems that had an Enterprise OS, WIn 7 or Win 10 on them and reimaging them with Windows 10 PRO using the license Windows 7 license that's printed on the MS label (for Windows 7 era hardware) or the Win 8 or 10 license that's embedded in ROM.  It has never failed to activate for me when deploying from a common image to other hardware - with the one exception I cited earlier. 

Heck, on at least 12 occasions I've taken an image of a physical system and and used it to build a virtual one under Virtualbox.  I just dug up an unused key and applied it. Some of these are Enterprise OSs so they just activated with our MAK server, other's I had to activate with a key  Whatever type of license it is like OEM license or not I don't know, it does not contain the letters OEM in it.  I also don't know if it was activated at the factory or not.  It is irrelevant for what I'm doing since I am applying a MS OS to the same hardware that THAT license was activated on and it again will activate, it's the equivalent of doing a fresh install on the same hardware.  Perhaps it won't always work, but it sure works better with Windows 10 then it did with prior Windows versions. I've been doing this for a decade or more and no longer have to have as many images as I did with prior Windows versions.  Win 10 just seems to be able to handle the hardware change a lot better than previous OS's and I use the SAME version on all the hardware, laptop, desktop or other.  Being that you are setting up gold images for Dell then you certainly must do so in a supported way according to Microsoft, for the average user we don't need to. 

Be that as it may, for the original posters question, yes you can redeploy images of Windows 10 OS's to new hardware. You will have to have a valid Windows activation license to activate it.  I've had nearly 100% luck changing the key to the one assigned to the hardware after restoring an OS from another machine. You can run sysprep if you want to, I find it does not provide anything useful and just wastes time.  As long as it uses the same boot method or disk controller type there is a very good chance it will just work.  

An besides, what has he got to lose?  Give it a try, it's worked great for me - and the 8 guys I supervise and a LOT of other people I converse with on other forums.  Windows 10 has a boatload of issues but redeplying a copy of the OS to other hardware is not one of them. 
Edited 12 July 2020 12:05 PM by Rootman
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
You're not upsetting me.  I just object to false claims, such as sysprep being deprecated.  Saying that you personally have found that it's unnecessary is an entirely different and completely fair statement.  But even you correctly pointed out that even something as benign as changing the storage interface between SATA, NVMe, or RAID vs. non-RAID will trip up even Windows 10.  Macrium offers ReDeploy to resolve that problem post-deployment if you're willing to do that reactively on every affected system (and have licensing with Macrium to do so).  Sysprep resolves that problem proactively by ensuring that Windows will boot even after such a change, obviating the need to muck with each deployed system, and it's free.  I believe changing between Intel and AMD CPUs is still similarly problematic, but I haven't had an occasion to test that recently.  Sysprep really isn't difficult to use if you only want the "hardware generalization" portion of it, but it's actually quite powerful in terms of what it CAN do -- although I grant that for individual users those capabilities would be overkill.  I believe those additional capabilities may have value even for many smaller organizations, but they would be in that range where it's one of those things that might make their lives easier overall if they learned it, but since it might not be a HUGE benefit and they have a workable alternative, they just say they never have the time and just keep soldering on with whatever they're doing -- which in fairness does work, even if it's not the most efficient, flexible, and/or capable method.

But hey, if your environment is sufficiently homogeneous that you don't encounter different CPU architectures or storage interfaces, then fantastic.  For people with more diverse environments that include some RAID and non-RAID systems, some SATA and some NVMe-based systems, and some Intel and some AMD systems, Sysprep's generalization still has value, to say nothing of what else can be done with the Unattend XML file.

Yes, there's no problem taking a system that used to be running an Enterprise OS and reactivating it with the key printed on the underside.  If Microsoft is still allowing Win10 activations from keys/embedded licenses pertaining to old Windows versions, despite their official policy that the Win10 free upgrade period ended years ago, then that's convenient for users, I guess.

There's no "MAK server".  There's a KMS server, but that's a completely different licensing model.  I'm not sure from where you're digging up those unused keys you mentioned, but not everybody will have a well of unused keys from which to activate Windows installations at will.  OEM keys don't have anything that would visually distinguish them as OEM keys.  OEM keys just mean a key for a license that was purchased with the system itself, which more recently also included that key actually being embedded in firmware and/or being registered at the factory with Microsoft to obtain a "digital license" where no traditional product key is required at all.

I agree that there's no real harm in @vze26m98 trying to "transplant" a Windows 10 installation back and forth to see if it will work, assuming both systems are licensed for the same edition of Windows 10 (Home vs. Pro).  However, one additional noteworthy item here is that unlike Mac OS X, Windows does not allow itself to be booted from a disk attached via USB -- except for Windows To Go environments, but those require special preparation and enterprise licensing.  So even if transplanting a disk back and forth would work, doing so with a typical external hard drive as vze26m98 did with Mac OS X would not.  A Thunderbolt-based SSD might work since that would be running over PCIe rather than USB, just like an internal NVMe SSD, so Windows might "accept" that, but I haven't tested that -- but true Thunderbolt-based SSDs are rather expensive and Thunderbolt is still rather rare on desktop PCs.  And if even that isn't an option, then I would argue that since the OP is trying to switch between a desktop and laptop PC, moving a disk back and forth between those systems will be quite inconvenient even if Windows 10 itself doesn't make a fuss.  M.2 SSDs for example are specifically NOT designed for repeated removals and insertions, which is partly why the U.2 connector was designed for NVMe SSDs that will be used in the enterprise space where storage might need to be removed and installed more frequently and more quickly.

Edited 12 July 2020 3:14 PM 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