I get this question all of the time:
”Is there a more streamlined way on troubleshooting the first-time setup? It is such a pain in the neck to have to wait and re-download an image just to test one simple command or piece of syntax!”
The answer is “Yes” – but with a very important caveat - it should only be used for troubleshooting FTS scripts during testing. This method is only designed to be used when testing a deployment on one or two machines. It is not designed to be an efficient method of mitigating a failure across a wide array of machines.
When a MED-V user starts a workspace for the first time, the image will either be imported from the Pre-staged Images folder or downloaded from an Image Distribution server. While the image downloads and extracts, an XML script is prepared from the policy to be injected into the workspace image. The ImageState.xml file is also created and it, in addition to other items pertaining to the image, also keeps track of the state of the image including where it is in regards to the first-time setup script.
When testing a workspace image in its deployment state (whereas, you are testing a deployment of an image rather than a specific image marked as a test image) I always recommend that you also include a published workspace command prompt or a menu that includes a command prompt prior to deployment. If you do not have one published, you can go back to the policy after the first-time setup fails and add in the published command prompt. It will get this information the next time you re-attempt to start the workspace that uses this deployed image.
So when a first-time setup script fails such as a domain join failed or a command line failed due to syntax, incorrect password, etc., the first thing you will need to do (assuming you have a command prompt published.) is to go to the following XML file:
<Path to Local Image Repository>\<Image Name>\<Version>\ImageState.xml
In the example below it is in C:\Med-V Images\ccm-managed-xp\V1\ImageState.xml
You will need to make the following changes to ensure each of the elements read as follows:
Save the file and re-attempt to start the workspace.
Note: If the autoadminlogon count is not set to a large enough of a count, you may get a prompt. Also if the workspace was configured for SSO in a domain and it was a domain join that failed, you will likely get prompted with an error like the one below:
If this happens, you can choose a local account password and logon. The workspace will then continue to start. When workspace finishes, start a command prompt (the one you published.)
Go and open up the following file in Notepad:
C:\Program Files\Microsoft Enterprise Desktop Virtualization\Workspace\DomainToolPersistentData.xml
This is the file that is used by the DOMAINTOOL.EXE utility to process the first-time setup script. it is built and injected upon the workspace setup. You can correct a known error (such as password, domain name, user account, or any other syntax error to confirm that this fixes the setup process with re-downloading/re-importing the image.
Once you have made the necessary script changes, you should shutdown the workspace from the guest command prompt using the following command:
That will also stop the workspace. At that point, you will need to return to the imagestate.xml file and set back the values manually as follows:
Once you restart workspace – it should re-attempt first-time setup. NOTE: Now that sysprep has ran the autoadminlogon count is done so this time you will need to manually enter in local credentials when prompted. Once you have confirmed the first time setup process script completes successfully, you can then permanently adjust the policy.
Steve Thomas | Senior Support Escalation Engineer
The App-V Team blog: http://blogs.technet.com/appv/ The WSUS Support Team blog: http://blogs.technet.com/sus/ The SCMDM Support Team blog: http://blogs.technet.com/mdm/ The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/ The SCVMM Team blog: http://blogs.technet.com/scvmm/ The MED-V Team blog: http://blogs.technet.com/medv/ The DPM Team blog: http://blogs.technet.com/dpm/ The OOB Support Team blog: http://blogs.technet.com/oob/ The Opalis Team blog: http://blogs.technet.com/opalis The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager The AVIcode Team blog: http: http://blogs.technet.com/b/avicode