Skip to main content

Cloning with 2017 causes Sysprep to fail

Thread needs solution

I've been using True Image 2010 to clone my Windows 10 images without any problems. I just purchased a copy of True Image 2017 from the Acronis website and find that when I use 2017 to clone an image then run Sysprep it fails, but if I use 2010 everything is fine. What's up with that?

0 Users found this helpful

I'd open a support case with Acronis directly to have them look into this more.

As I understand it, Windows 10 does not need to be sysprepped and Acronis acutally removes the built in feature to do this in Snap Deploy and the Entperprise backup versions.  This may be why it's failing after being cloned in 2010 - to some extent. It's been posted in the forums before, and I just Googled it and found this SpiceWorks forum thread with a response from Acronis as well...

https://community.spiceworks.com/topic/1347801-acronis-snap-deploy-5-generate-sid-windows-10

A few other thoughts - 2010 was strictly MBR/legacy.  2014 and newer have UEFI and Legacy support.  Do your new systems support legacy or are they designed for UEFI - things like the SATA mode being different, or perhaps booting the recovery media of 2017 in UEFI mode instead of legacy mode might be causing an issue.

How many times have you used your disk to sysprep?  There is a sysprep limit (rearm) of any one image... Good practice would be to take an image that has never been sysprepped, deploy that to the new system and then run sysprep on it - this will prevent you from hitting a rearm limit as your base image will always have 0 syspreps peformed against it.

 

We are using only legacy boot. Also, we don't sysprep our master images but rather clone them (using True Image 2010) to another drive then sysprep in order avoid the whole rearm issue. I'll take this up with support.

Thanks

This may be worth a read too... others with Windows 10 sysprep issues - no relation to Acronis that I could find, but actually caused by the Tile Data Model service when it's running.  

https://redmondmag.com/articles/2016/03/04/sysprep-work-with-windows-10…

Curious as Acronis 2010 is not supported on Windows 10 if it does not take into account some of the new Windows 10 services or features with the App store that can be an issue with sysprep, yet, 2017, which is Win 10 compatible, has to take them into consideration - really don't know.  Would be instresting to see what Acronis responds with. Would also be curious if the suggested sysprep work-a-round in the above article works...

stop the Tile Data Model Server service. When the service stops, click Refresh. You will see that the service has restarted. Stop the service again, and click Refresh again. Once again, the service will have restarted. You will need to repeat this process for about five or six times until the service stops without restarting. Once the service has stopped, be sure to click Refresh at least three or four times to make sure that it has really stopped. Now, quickly switch over to your Sysprep window and run Sysprep. You must do this quickly because the service that you stopped will not remain stopped indefinitely. If the service starts back up during the Sysprep process, Sysprep will fail.

 

 

Also curious if you have tried with 2010 using the most current version of your image as well. I've read several articles today about sysprep failing due ot newer Windows apps or updates to these apps...

https://4sysops.com/archives/windows-10-sysprep-was-not-able-to-validat…

%windir%\system32\sysprep\panther\setupact.txt may point to an app as the culprit - I get that it may be working in 2010 and not 2017 (assuming you're using the exact same system and just cloned it with 2010 and then with 2017 and the problem only exists after cloning with 2017, but if these aren't side by side clones with both products at nearly the exact same time, then there could be more to this as well).  

When you shutdown for your clone, do you do a shutdown/p to ensure that there is no locked disk or fastboot hibernation file in play as well?

Yes, I've tested it three times with 2010 and three times with 2017 on the exact same image and gottent consistent result - succeed with 2010 and fail with 2017. I'm not doing a shutdown /p - I'll give that a try and post the result.

Well, Acronis tech support was zero help but it turns out that the suggestion of shutdown /p did the trick. All of the newer versions of True Image I tested (2014, 2015, and 2017) were failing sysprep after cloning (whereas 2010 worked just fine) until I started shutting the image down with the /p switch.

Thanks for the help!

Glad to hear it.  I've gotten used to disabling faststart / fastboot in Windows since I primarily use fast SSD's and/or NVME PCIE drives.  The difference in boot times with these drives when fastboot is disabled is pretty negligible in most cases.

The downside with fastboot, is when you shutdown using the standard method, it leaves a hibernation file on the drive that locks the disk in some cases.  Not sure how that specifically impacts sysprep, other than Microsoft isn't taking this into accountability for some reason either.  Why the difference in behavior with Acronis 2010 and 2016/15/17 - not sure either if the image is being taken outside of Windows while the OS is idle.  Going forward, before taking your image, running shutdown /p first there might help so you don't have to run it each time after you deploy the image.

While it is good to hear that sysprep runs successfully after cloning with Acronis True Image 2010, I would like just to point out that neither 2010 nor any other version of Acronis True Image is not intended to be used for massive system deployment. Acronis Snap Deploy should be used instead - it has both appropriate tools and licensing model for that.

Regards,

Slava