Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Deploy Anywehere causes sysprep to hang in AUDIT mode, doesn't get to OOBE

Created: 03 Sep 2014 • Updated: 03 Sep 2014 | 1 comment

During our imaging process, we create our own tokenized sysprep files. They work correclty on all models that do not require deploy anywhere and on some that do. On select models that use deploy anywhere sysprep fails with the "You must restart your computer to apply these changes" and "Windows could not complete the installation. To install windows on this computer, restart the installation" messages below.

 

DASysprepError.jpg

 

This issue is detailed here and, at one point had a fix: http://www.symantec.com/connect/forums/deploy-anywhere-causes-sysprepped-image-fail-unable-process-unattend-answer-file. I have obtained the most recent version of the deploy anywhere executables from support and am still having the issue.

After digging through the sysprep logs, I discovered that deployAnywhere is booting the system to audit mode and that it fails to process anything after the audit mode tasks. If I don't use deploy anywhere and use the same custom unattend.xml file, sysprep completes as expected.

Has anyone else encountered this?

 

 

 

Operating Systems:

Comments 1 CommentJump to latest comment

Thomas Baird's picture

OK - there are some weird things in this post.

First, DA doesn't boot the PC to anything.  All DA does is scan the system, copy some drivers to the OS drive, and modify the Unattend.XML file.  That's it.  Rebooting to ... whatever, is handled by the task and agent.  VERY important distinction because of troubleshooting the issue.

So, be aware that this is all DA did.  It DID modify the Unattend.XML file, and at that point, you may want to see what it did.  You have a custom file - see what it added or subtracted.

In the past, what I saw that MIGHT affect this was one of two things:

  1. DA added another "version" of the same section that was already there, or modified the section already there incorrectly.
  2. The sections already there may have incorrect architectures specified in them (in the Unattend.XML file) and break when DPInst runs.

Remember, the 3rd part of driver injection (the DA method anyway) is to run DPInst during Mini-Setup.  This is not something most people put into their own Unattend.XML file.  To do this, DA tries tell the Unattend file to have MiniSetup create a GhostUser admin account, log in as that account so that is has rights, and then run DPInst.  All this COULD affect (or be affected by) something you already have in there.

OR DPInsta my itself be failing.  The installation logs during MiniSetup can tell you that (capture those back in automation after it fails from the production drive: c:\windows\panther)

Most likely, your problem lies in that area.

ONE other thought.  DA is ... interesting and a headache to many out here.  Many of us have taken to using DISM for driver injection instead of relying on DA.  DISM is nearly 100% reliable on Win7 and above.  Really nice once you know how to do it and have it set up correctly.  However, it is NOT supported.  My point?  Maybe for these models you need a different job/method, while Symantec Dev figures out how to fix it.  Just saying.

Thomas Baird
Private Consultant & open to full-time opportunities.
That means I CAN help beyond the forum (directly).