Deployment Solution

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.

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?

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.

I have the same issue more or less. I am getting an automated image together for my training rooms. The desktops are now Optiplex 745's and Optiplex 9020's will be on the horizon to replace the 745s.

I build the image off of a vm > use jobs and tasks which includes:

1. Prepare for image capture

2. create image

3. reboot

I have some drivers in the drivers db under DA for the 9020. Some drives as of today with the latest version of DA from SP1 HF5 still do not upload to the DB.

Now a deploy image job:

1. Deploy image

2. Reboot

FYI, I have not set this for complete automation yet. Until this is working I am using the initial deployment menu. If the deploy image job has DA checked off I am consistently in audit mode. The image has NOT been in audit mode before the image capturing job was running. I have a ticket in with Symantec, this one looked too complicated for a forum entry so i went right to Symantec about this. So far, DA is being blammed for this but no details as of yet on why DA is putting the image in audit mode.

MJammer,

I have similar Dell models as you and have found this alternative to DA to be much easier to maintain/understand.  Might be worth a look - I got it up and working with all of our dell models in a day.

https://www-secure.symantec.com/connect/articles/simple-alternative-deployanywhere-hardware-independent-imaging-drivers

I had a breakthrough this afternoon with my imaging issue. It is DeployAnywhere causing 7 to go into Audit Mode and stay there. Cause of that is clearing the data out of two registry strings:

HKLM\Software\Microsoft\WindowsNT\CurrentVersion

The two strings: RegisteredOwner and RegisteredOrganization. I clear these two strings so my unattend.xml enters in the proper data. DA does not like those two strings empty and requires something, so I manually enter the proper info before running my capture job. I am now imaging a pc with 7 and no more audit mode!!!! These tooks months with Symantec to figure out. The Engineer and myself had to run DA and logs manually while in automation. One of the logs pointed this out at the bottom. There was a DA error mentioned and refered to that exact key location and said FAILURE!!! Look into doing this if you clear out the strings also.