When using DeployAnywhere with DS 6.9 / 7.x, you may run into various problems, including Minisetup failures, autologin counts being reset, improper detection of devices and/or application of drivers, etc.
*** First, get a new version if possible. (attached to this KB)***
DA is a stand-alone executable and as such can be updated without updating the rest of Deployment Solution. As we uncover problems in the product, we can fix and test these fixes quickly and provide updates. This is particularly useful in an environment that is so quickly changing, such as with hardware and drivers. Additionally, we've drastically improved logging and a few other features (added command-line switches) to DA to help, specifically when compared to the version that ships with DS 7.1.
We've attached the latest tested version of DA to this KB for you to download. We recommend making a backup of the DA executable, then replacing it with this. No services need to be stopped to make this change, though an imaging job should not be "in progress" so as to avoid any possible conflicts.
We will document some of those changes here.
Note: DS 6.9 SP5 MR3 and prior, and DS 7.1 name the executables differently. DS 6.9 SP6 and later name the executables the same as 7.x.
DS 6.9 SP5 MR3 and prior: ghDplyAw32.exe is the 32-bit version of DA; there is no 64 bit version of DA in these versions. Place ghDplyAw32.exe in the ghost directory
DS 7.1 and 6.9 SP6: DeployAnywhere.exe is the 32 bit version of DA (Place DeployAnywhere.exe in the ..\taskhandler\ghost and ghost\x86 directories); DeployAnywhere64 is the 64 bit version of DA. (Place Deployanywhere64.exe in the ..\ghost\x64 directory)
Next, you should understand a few key terms:
The first thing to note is that the version of DA attached to this KB has significantly improved logging. This is one of the first changes we made, so if you've not done so already, please get a new version of DA per the section above. Logging makes a LOT of difference when we are troubleshooting. Note: If you need to call support, this is one of the first things we'll ask you beyond basic troubleshooting, because we need the logs to know what to tell Development.
Basically now, here's how DA works if executed with by default with the deploy image task in 7.1: (More information can be found in the Dataflow and Architecture document in a version post October 2012)
At this point, DA is done and does nothing else.
Note: When the system reboots (next), MiniSetup takes over. Sysprep and DA never run again. MiniSetup simply uses the information given to it in the Unattend.XML file to find drivers on the system. More information about troubleshooting that is provided later, and elsehwere. There are only two things to be aware of related to what DA did, during MiniSetup:
If when you skip DA Mini-Setup runs, but when you run it, Mini-Setup fails, more troubleshooting is necessary to find out where the problem actually is. The problem could be driver related, or MiniSetup related, or a number of issues.
As a result, you have to manually log into the "Ghost User" account so that the deployment process completes successfully.
This only occurs in Build 4128 or earlier. This is corrected in a later release of DA. Please use the one attached.
To determine what is, or is not working, you need good logs.
Troubleshooting for this should start with similar steps as in #4 above.
The only real difference would be in the case of missing drivers. Remember that if you add the drivers to the console, they now exist on the SMP. There are then some additional things needed if you have anything more than a single server environment:
You should verify replication prior to performing an imaging task.
Additionally, the drivers must match the system and have the appropriate information DA needs. Consider the following:
More info and suggestions:
If you need additional help from Symantec, contact Technical Support. They will need the following information:
Several other aspects of imaging interact with DA and or Drivers but may in fact point to other issues.
DA Switches of note:
|/Target||/target=<fully qualified local path to active windows partition to be re-targeted | ghost positional notation specifying active windows partition to be retargeted >
This switch is mandatory [it is the only one that is]
/target=c: [DA searches c: for a suitable target]
If /target is specified using a drive letter, it must be the drive letter as seen from the PreOS.
If positional notation is used DA will translate from the positional notation to the driver letter currently pointing to that physical partition. In GSS2.5 DA uses GhConfig32.exe to perform the translation.
If /eval is not specified with /target then the target OS will be modified. If the retargeting does not succeed the target is left in an indeterminate state and the target may need to be reimaged before another attempt at retargeting can be made.
If there are errors then they will be logged to GhDplyAw32.txt in the Current Working Directory (CWD).
* This file is always overwritten
* This file is never deleted
|/ddb||/ddb=<fully qualified local path to the driver database>
Network drives need to be mapped using ‘net use’ command.
Not specifying /ddb is equivalent to saying "do not use a driver database"
|/Managed||This tells DA to output results to a "driver_list.txt" file. Note, output to this file can be extensive depending on the switches used. Cannot be used with both /Eval and /Debug|
|/Eval||Requires /Target. This tells DA not to actually re-target anything or change the destination OS in any way, but simply to look for missing drivers. It may be used with or without the /DDB switch. If used with /ddb, then it looks for drivers missing from the Drivers DB. If used without it, it looks for drivers mssing from the target OS.|
|/Precheck||This tells DA to enumerate all devices that require drivers and check if those drivers are present in the database. NOTE: it does NOT check for drivers present in the target OS like the /eval switch does. /Precheck can also be used with a /ddb switch (which also would require a /target switch). It can also be used with /reportnoncriticaldevices for an expanded output of results.|
|/ReportNonCriticalDevices||This will expand the output of DA to include non-critical devices to the logs.|
|/handleNonCriticalDrivers||Required if you want DA to do more than just Critical Drivers|
|/skipMissingCriticalDrivers||DA will fail if it finds critical drivers missing, unless this switch is used.|
|/loglevel||Set this to 255 for verbose logging of DA. NOTE: The most recent versions of DA have extensive logging even without this switch, so this switch is no longer necessary most of the time.|
|/byPassDrvVali||Use this if DA is finding drivers, but failing on validation, but only if you're confident, for DA will use them without validation which could cause issues (See KB TECH200444)|
|/logPath||Currently this switch is ignored. Please see above for the default location on the attached site server. This|
Login to Subscribe
Please login to set up your subscription.
Get support for your product, with downloads, knowledge base articles, documentation, and more.
Maximize your product competency and validate technical knowledge to gain the most benefit from your IT investments.
Set default language
Do you wish to save this as your future site?