Redeploy to new hardware ok, but system freezes when booting up


Author
Message
RefDM
RefDM
New Member
New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)
Group: Forum Members
Posts: 37, Visits: 123
I have recently started a small pilot project to migrate over to Marcium from another backup software, and I think I have now found my first challenge. It will be interesting to see how this issue will be solved. Since I'm pretty new to MR, I guess that most likely I'm now just missing a small piece of pretty obvious information. I only don't seem to be able to figure it out myself, so here goes...

I have successfully built a "golden image" for Windows 10 installations in a VirtualBox VM. I also have successfully backed up the golden image using Macrium RE and successfully restored and redeployed it into two workstations. No problems, everything went just as I expected. Great product!

However I have had problems with the same image in two other workstations having somewhat older HW models. All four workstations are desktops.

When I boot the restored and redeployed image in the two older desktops, I get the static Windows 10 logo into the center of the screen, and nothing else. Not even the spinning dots... No error messages are shown at any phase. Green checkmarks are shown for all detected devices in the redeployment phase. No undetected devices are found.

For comparison, and to verify that the older workstations are definitely Windows 10 compatible, I tried installing Windows 10 into them from MS distribution media, and everything went smoothly: no problems during the installation, and the systems booted up nicely. So it does not seem to be a HW problem and it does not seem to be a Windows 10 compatibility problem. I performed the installation using the same Windows 10 installation media I used in creating my golden image.

I have now repeated the deployment process for the two workstations trying to vary whatever possibilities I have found, but with no luck... (I have e.g. recreated the RE USB stick with and without combined UEFI/MBR support; I have recreated the RE USB stick in both of the older workstations after first installing Windows 10 from MS media and installed Macrium thereafter. I have varied ACHI mode on/off for SATA controllers etc...)

Any help would be greatly appreciated.
jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)
Group: Forum Members
Posts: 2.4K, Visits: 16K
This is a long shot, but have you tried running Fix Boot Problems after running ReDeploy?  Otherwise, Microsoft's guidance for system image deployment is that the golden image needs to be sysprepped before it's captured, since part of that process involves "generalizing" the image so that it will boot on dissimilar hardware (somewhat similar to ReDeploy), but it also makes other changes that can be crucial when replicating a single source image onto multiple PCs, particularly if you'll be joining them to an AD domain.  Are you sysprepping?  Microsoft doesn't support images that were deployed without having been sysprepped, for what it's worth.  Even if you don't ever intend to contact MS Support, I mention it as an indicator of how important they consider that step.

Lastly, just in case you weren't aware, Macrium requires special licensing if you'll be using Reflect as part of an image deployment strategy.  You can either get a Deployment Kit License, details here, or a paid Reflect license for every PC you will be deploying images onto, since ReDeploy is a paid feature and can only be used on the system that holds the Reflect license or a new system intended to permanently replace the licensed system in a migration scenario.

Edited 18 January 2018 6:00 PM by jphughan
RefDM
RefDM
New Member
New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)
Group: Forum Members
Posts: 37, Visits: 123
Yes, I have run Fix Boot Problems, but it did not have any effect. I also ran the Windows "Fix Boot" utility which popped up after rebooting the frozen first boot. Unfortunately the MS utility was not any better; it was not able to solve the problem.

Actually my original plan was to use sysprep, and I used it in my first test installations while building the golden image. However I found some parts of sysprep not functioning as I expected (IIRC one of them being the copyprofile not copying everything I expected). At the moment I use sysprep only after deployment in some special workstations where I have a need to move the Users directory to a separate partition.

However I cannot see why sysprepping would be required, at least in my case. The workstations will not be joining a domain. And if my HW dies and I restore and redeploy the image into new HW, there is no way to sysprep, so nobody syspreps in that situation... Are you saying that MS does not support restoring an image into a new HW after the old HW has died?

My current understanding is that if I deploy without sysprepping the only "problem" is a duplicate SID, and I remember reading a MS written blog post stating that duplicate SIDs are not a problem in real life (and at least not a problem when not connected to a domain).

About licensing, no problem: We have a separate license for every workstation.

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)Most Valuable Professional (3.3K reputation)
Group: Forum Members
Posts: 2.4K, Visits: 16K
CopyProfile on Windows 10 has typically been creating more problems than it really solves, which probably explains why (if memory serves) the TechNet documentation for that setting mentions that it's been deprecated or isn't recommended or something.  When I've used it on recent builds, I've encountered problems ranging from the Quick Access shortcuts being broken because they point to the Administrator profile, Windows Search not working at all, some Modern apps failing to start, etc.  There are threads over on MS where users have shared lists of files/folders that should be deleted from the Administrator profile prior to capturing the image so they're not copied over, but those are workarounds at best, and likely not complete ones.  It's clearly not something Microsoft is supporting anymore, which is hugely disappointing.  At least they provided a separate way to export the Start menu layout to the default user template, but that's by no means a full replacement.

The SID is definitely one thing that gets handled by sysprep, although as you say, the ramifications of duplicate SIDs even in systems that ARE joined to a domain is actually contested.  But another key aspect that sysprep takes care of is Windows licensing.  I was helping a customer that had a batch of identically configured PCs.  One had a hardware failure, so I transplanted that system's drive into another system whose data wasn't needed at the time.  Since it was identical hardware, it booted just fine as you would expect, but the Windows installation fell out of activation and then would not reactivate, even though the new system had already claimed its own digital license for the same edition of Windows 10.  I even ran the troubleshooting tool and it literally said, "We found a digital license for this PC, but to activate with it, you need to reinstall Windows," or something like that.  It would not use the PC's digital license to reactivate the existing installation in-place -- nice, right?  So you might encounter that type of issue if you try to replicate a non-sysprepped image.  Alternatively, you can try to make sure that the golden image never activates before you capture it, which may work around it, but that can be tricky if you can't keep the golden image off the network the entire time you're building it, and probably impossible if the system you're building with has a Windows license embedded into its firmware.

Anyway, it's a completely fair point that someone just trying to migrate from one PC to another would not have sysprepped their image and could therefore run into your situation.  I wonder if there's a ReDeploy log file that gets generated that might help determine underlying cause?  Hopefully Macrium will assist here.


Edited 18 January 2018 7:47 PM by jphughan
RefDM
RefDM
New Member
New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)
Group: Forum Members
Posts: 37, Visits: 123
Three weeks have now passed since I opened a support ticket (#14945) due to this issue. The final outcome I received from support today was as follows:

"The evidence does point to a (start at boot) driver on your source win10 system being incompatible with your specific AMD based h/w causing a cpu exception/halt during the kernel initialisation phase. We automatically disable any drivers that are flagged cpu support and we can't see any other drivers on your source system that would cause this issue.

I am sorry we cannot offer any further guidance in this matter."


To my eyes this seems that if I take Macrium into production use, and after some time (Intel & AMD having published new generation CPUs) I would like to redeploy my systems to new hardware, I may well find myself being in a blind alley - not being able to ReDeploy to new hardware.

At first glance this is really hard for me to believe, and I certainly hope to be wrong here... I wonder if someone can shed some light on here for me, please?

In this case the source system was a Windows 10 Enterprise 1607 LTSB 64-bit running on Oracle VirtualBox 5.1.28 in an Intel based VM host, and the target system is an AMD based desktop PC with no virtualization.

If I understand correctly what Macrium support told me, the ReDeploy process has failed to recognize CPU ppm drivers in the backup image that are incompatible with AMD CPU and for this reason the system does not boot up, but there is nothing they can do for it.

I'd be surprised if a standard Windows 10 installation media contained CPU ppm drivers that are impossible to detect and disable in the ReDeploy process.. (I guess that I'm missing something obvious here...)


GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search