Getting the most from DeployAnywhere for all builds of Deployment Solution (DS 6.9 and 7.x) - Contains new build of DeployAnywhere executable


Article ID: 156253


Updated On:


Deployment Solution


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.



  1. Lack of understanding - Documentation on the DA Process.
  2. Mini-Setup fails to complete
  3. The autologin count settings may be removed from your unattend answer file (DA build 4128 and earlier).  As a result, you have to manually log into the "Ghost User" account so that the deployment process completes successfully. 
  4. Devices may not be properly detected on client system.
  5. Drivers for detected devices may not be properly applied to client systems.
  6. Troubleshooting and Logging


*** 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:

  • Critical Drivers.  These are NIC and Mass Storage.  Mass Storage is all that is critical by Microsoft standards, (system wont start without them) but without NIC, you can't do anything remotely.
  • Non-Critical Drivers.  Literally anything else.  Up until DS 7.1 SP1 and 6.9 SP6, we only supported Critical Drivers with DA.  Now we support just about anything, except for some hardware types we can't detect yet or drivers in a non-standard format (e.g. EXE).
  • Driver Rank.  This is a score applied to a driver that DA discovers, either from our DB, or from Windows, as it's scanning through appropriate drivers to apply.  Highest rank driver that matches a device wins.

Now, here are some answers to the questions above:


1. Lack of understanding / Documentation on the DA Process.

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)

  1. As soon as Ghost finishes, the Deploy Image task creates a BAT file (generally in the root of X:) for DA which it will then execute called DEPLOYANYWHERE.BAT. 
  2. The task then executes the BAT file which launches DA.
    1. It should be noted that this is an excellent way to 1) learn what DA is doing and 2) run DA manually by taking one of these BAT files and modifying it.
  3. DA discovers where the production OS is, and where Windows is (what drive letters).
  4. It scans all devices on the BUS to determine what is present.  Some newer equipment (e.g. USB 3.0) may not be recognized at this time, but we will update DA as quickly as we can.
  5. It looks for Non-Critical drivers
    1. Scans all Windows drivers to see if appropriate drivers are present in the image for these devices.
      1. DA looks for a "full match" of data in the inf file which includes Vendor, Device, and SubSystem ID's.  This is called a "Best Match" and has the highest rank.  Information similar to this can be found under Device Management in Windows under the properties for the device under Hardware ID's.
      2. DA will also look for partial matches of the Best Match where only one part of the full device ID matches (e.g. only one of the fields).  This is considered a "Compatibility Match".  Information similar to this can be found in the production OS for loaded devices under Compatible ID's in Device Management.
    2. Scans our DriversDB folders to see if we have a match available. (repeate of step a above)
    3. In the event of a tie (multiple drivers match), several things are considered:
      • Native Windows drivers always win
      • Drivers with CAT files get next priority
      • Latest version gets next priority in the event of two or more having CAT files.
    • The highest scoring driver is copied to an appropriate folder on the Target system under  Symantec\drivers\noncritical.  This will be used as a re-target of the MiniSetup when the system reboots.
  6. It looks for Critical Drivers (Mass Storage and NIC drivers only)
    1. repeat of the process in step 3 but for these drivers and copied to a different location:  Symantec\drivers\retarget
  7. Finally, it modifies the Unattend.XML file in production or the Sysprep.inf file to point MiniSetup to the drivers location.

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:

  • DA added a section to the Unattend.XML to create a GhostUser account with Admin rights.  When this section is read by MiniSetup, that user is created.
  • DA added another section to run DPInst, which is a Microsoft utilitly that calls and installs drivers.  We point DPInst to the folders added during the DA execution above.
    • At the end of this section, we delete the GhostUser account and reboot.


2. Mini-Setup fails to complete.

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.

  1. Capture the Panther folder on the affected system.  This can be done in production if you can get into production, or it can be collected in automation if the production environment is blue-screening ro something.
  2. Check the unattend.XML file in the panther folder AFTER MiniSetup has completed.  You can see sections that were processed and not.  If the two sections we added didn't run, obviously there will be driver problems, unless we didn't add one.
  3. Check the folders where the drivers were added to see if they can be added manually into Windows
  4. Of course check the DA logs
  5. It is possible the failure was not DA related, and you may need to check the other files in the Panther folder for possible issues in Windows itself.  It's not always a driver problem!


3. The autologin count settings may be removed from your unattend answer file

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.

4. Devices may not be properly detected on client system.

To determine what is, or is not working, you need good logs.

  1. Be sure you're using the latest release of DA.  
  2. Enable full logging per the switches in the table below.
  3. Check the DA logs to find out what it is, or is not doing with your device.  As mentioned above, some devices are not yet supported like USB 3.0, where others may simply be handled differently than you expected.  
    1. A prime example of this is if the Windows driver comes back with a higher-rank for success than the driver you supplied.  DA attempts to be "smart" but perhaps you know a driver is better than that supplied by Windows.  If so, the manifest file for the driver can be modified to increase its rank.
  4. Ensure you have good drivers that match the version of Windows you're deploying.  Symantec does NOT supply drivers and will only assist you in finding them.  Drivers must be obtained from the hardware manufacturer or some partner.

5. Drivers for detected devices may not be properly applied to client systems.

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:

  • These will NOT be successfully replicated up the hierarchy.
  • These MAY be replicated down the hierarchy, but you will need to verify.  if so, they will NOT make it to the Child SMP server.
  • These are supposed to then be replicated out to Site Servers, but it takes time.
  • Verify the drivers made it into the correct location on the target system: Drivers\Symantec\noncritical   --&/or--  Drivers\Symantec\retarget (for critical drivers)

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:

  • Drivers can typically be added by browsing to the folder where the .INF and .CAT files are located. There have been issues when trying to load the drivers from a parent folder.
  • Make sure that the VEN and DEV numbers for the new driver in the .INF file match those same values in the .NFO file produced by running MSINFO32.EXE on the client computer involved.
  • Make sure that the OS type for the new driver matches exactly what is on the target machine.
  • Do the new drivers show up on the NS under \Program Files\Altiris\Altiris Agent\Agents\Task Handler\DriversDB\drivers.manifest? If not, then the drivers did not get added to the drivers database correctly.

 More info and suggestions:

  • You could build a special image of the model computer that already has all drivers that are needed or simlpy add the drivers into the image directly.  This is old-school, but still works.
  • Try adding the contents of the driver download that include .INF and .CAT file in to the DriversDB folder ( as documented above ) using a unique folder name.
  • Typically, driver downloads include .EXE components designed to be run to automatically update a driver.
    • You could, from the NS, build a 'Copy File' task that copies such an .EXE and runs it. This can be done in WinPE before the target boots. NOTE: If the target machine is 64 bit, use the 64 bit version of WinPE in this case.
    • You could extract the drivers from the EXE using a tool like 7zip to make them usable by DA (we do not support EXE drivers at this time.).

If you need additional help from Symantec, contact Technical Support. They will need the following information:

  • The output from MSINFO32.EXE on a client computer that will not take the driver. This should be an .NFO file, not a .TXT file.
  • The driver itself. This must be an exact match of vendor and device numbers that are shown in the .NFO file from the same client computer.
  • The driver.manifest file as documented above.

6. Troubleshooting and Logging

  • Know the process.  It is extremely important that you understand what DA does, and does not do.  This will both help you find answers faster, and will help us if you need to call.
  • The original version of DA that ships with the product only produces a log file if an error occurs.  The one attached to this KB always creates a default / low-level log file, and accepts a switch to increase logging to a maximum level (loglevel=255).  
    • By default, the DA log will be in the 'task handler\ghost\x86 or 'task handler\ghost\x64' depending on the architecture of the preboot environment.  This will be on the site server to which the client is connected and is therefore "still present" even if the system reboots.  
    • The name of the log is 'DA_logs.txt'.
    • The option to specify the path of where to store this log, at this time, is broken and that switch is ignored.  Therefore, the logs will always be in the above location.  If, therefore you run it twice, or on two systems, it will be over-written.
  • DA can be run in "eval" mode to let you know what drivers you may need to look for.  This can give you a quick look at what it will be looking for that it doesn't have to help prevent problems you have later and must dig through the logs to find.  We recommend doing this on any new hardware type, and possibly spot-checking through deployments in case the manufacturer changed the hardware (VERY common).
  • DA can be told to NOT insert either critical, or non-critical drivers.  Sometimes this can be a good troubleshooting step.
  • You may need to verify that drivers you've added in the console are actually replicated out to Site Servers where DA is run from.  See #5 above.
  • Remember to add drivers to DeployAnywhere, not just BootWiz.  They are separate tabs and the two get copied into different locations.
    • BootWiz drivers MUST be for the version of WinPE you are using (2.1 in DS 7.1 = Vista) and DA drivers MUST match the destination OS you are deploying.
    • Drivers can be inserted manually into the File System under DriversDB if the console will not accept them.  Every time you launch the console applet, it re-reads every folder and should both update the master Manifest file, as well as adding a manifest file for the drivers you just added.  This can be very useful at times (especially if migrating from another installation), though the need for this is much removed in the latest releases.
  • If you need to test DA, or run it in a way that is custom (not fully supported), use the BAT file indicated in #1 above as a starting point.
  • There are a number of supported switches for DA.  DA can be run either without switches or with /? to learn all the switches it accepts.  Many of those are in the documentation, but there are a few that are new (per the release attached to this KB) and a few you really should understand.  These are outlined in the table below.  Some to keep in mind include:
    • Running DA in eval mode to let you "see" what it's doing and what it finds.  VERY useful for when you get new hardware

Additional Troubleshooting:

Several other aspects of imaging interact with DA and or Drivers but may in fact point to other issues.

  • The Unattend.XML / Sysprep.INF file it modifies can be reviewed for accuracy.  For instance, in some circumstances, we've discovered a bug in Windows can prevent the now modified files from working.  %SystemDrive% is supposed to be recognized by Windows during MiniSetup, but they have a bug at this time that affects only some OS's.  If you are having this problem, the Unattend.XML file could be modified prior to a restart (we have a sample script for this).
  • As indicated in #2 above, you can review the logs Mini-Setup creates to see what Windows tells you happened.  This is very useful to determine where failures actually occurred, if it was actually DA or something else, and if DA, where/why the problem occurred.
  • If the task fails, don't assume it's DA unless you check.  Look at the agent logs, and for the Ghost log for additional information.  Though DA runs at the end of Ghost, so do other processes, so it's not a given that it's a DA problem.
  • TECH200444- Signature checking of newer drivers (Intel NIC drivers for instance) in automation is not working correctly causing Deploy Anywhere to fail
  • TECH187749- How can you tell if a driver can be imported into Deployanywhere DriversDB folder (using drivermanager.exe)

 DA Switches of note:

Switch Function
/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





ghDplyAw32.exe get_app
DeployAnywhere64.exe get_app
DeployAnywhere.exe get_app