Premise:

Since DS 7.1, DeployAnywhere (DA) has been used for driver injection to accomplish Hardware Independent Imaging (HII).  Many have become very familiar with that process.  However, with the advent of ITMS 7.5, we also have several security changes, and several modifications in DS to allow for HTTP imaging.  Imaging with HTTP has provided interesting challenges for DA which is accustomed to working with mapped drives.  So, a new process was introduced (and is providing... interesting challenges.

Purpose:

This KB will hopefully help explain the new process of Driver Injection.  We will no longer refer to it as DA because DA is now only a piece of the puzzle, albeit a large one.  Driver Injection for HII is of necessity a new title.  Knowing the new process will hellp troubleshooting, both in understanding what you see in the DSTasks logs, where other files and logs are coming from, and how all of this works together.  Additionally, it will help you communicate quickly with support exactly what is wrong if you have problems.

Explanation:

A Short Background:

In short, there are more steps to the process now than existed in the past.

NOTE: More is being learned about some subtleties in the process.  For instance, there seems to be a slight difference in how the UNC method and HTTP method works, but we don't yet have all those details.

Key to understanding this is to understand how we use Package Servers in DS 7.5.  DS 7.1 used Task Servers and a Deployment Share for all data and execution.  DS 7.5 has been aligned properly with regular Package Server replication, codebases, and security.  This makes the product more scalable and flexible, but poses an interesting challenge: we now have to support HTTP and HTTPS codebases!

Default behavior for Package Servers is to return both a UNC and HTTP codebase for all packages.  The preferred download method is HTTP though for security and flexibility reasons.  Because DS now uses Package Server behavior, and to improve security (UNC mappings are notoriously unsecured and in some locations are completely blocked), it needed a new injection method that supports HTTP and/or HTTPS communication for things like deploying images, downloading tools or copy file packages, and executing DA against a folder of Drivers in DriversDB.

The New Process:

Since most people are now defaulting to an HTTP method, this is the method that will be outlined. Additionally, we only describe how Driver Injection works when used as we recomend - that is, by including DeployAnywhere in the Deploy Image task.  The graphic below helps outline the process along with showing how each component works together:

<graphic to come>

The brief descriptive version of this is as follows:

1. Ghost completes as part of the Deploy Image task.  GHConfig has already run and runs again to verify the production drive.  Where the production drive is, is needed for a later step in Driver Injection.
2. DA is called with the /EVAL switch to determine what devices are present on the system.
   1. It first determines what drivers are present in Windows and excludes these.
   2. Then it determines what drivers are missing and creates a Driver List of those devices that are still required for full functionality.
   3. It then exits
3. Driver Manager is then called, uses the Driver List created by DA, analyzes the drivers present and creates an DA_Eval_List.xml file with all the drivers that are required from DriversDB on the network.
   1. Unfortunately, the log file created, DA_Eval_List.xml is deleted
4. The DS Plugin (PECTAgent.EXE essentially) uses the DA_Eval_List to copy drivers to the local drive into a sort-of Miniature version of DriversDB, located under d:\program files\altitis\altiris agent. This is based on the information gleaned earier from GHConfig.
5. DA is then called again with the /retarget switch, but pointing this time to the local copy of DriversDB, selects the best drivers as present, and populates the d:\drivers\ folder(s) depending on if there are critical or non-critical drivers injected.
6. We "think" the DS Plugin then deletes the mini-DriversDB created earlier - more research is needed here.
7. The DS Plugin then modifies the Unattend.XML file to call DPInst and modify the registry with the new drivers paths with appropriate rights using the GhostUser account.

Outputs from this process include:

• 2 separate executions of DA, both logged, only minutes apart, both essentially called DA_Logs
• Driver_List.txt
• DSTasks.LOG
• At least 2 versions of act_wnd files from GHConfig
• DA_Eval_List.xml, but unfortunately this is deleted and non-recoverable at this point in time.
• Customized Unattend.XML file
• c:\Drivers folder with drivers to be used during MiniSetup

Conclusion / Key Take-aways:

Knowing the process, you should be able to determine what happened if a driver you think belongs didn't make it.  Here are a few possible conclusions based on the above information that may be used as examples in your own troubleshooting, along with personal action items to correct the problem:

Example 1: Driver Injection fails due to missing drivers in DriversDB (similar to DS 7.1 troubleshooting).

To determine this, first you would see most likely a warning and/or failure in DSTasks from the Eval run of DA.  NOTE: Anytime DA is needed, there are missing drivers, so this is not a critical error!  Checking the devices that are marked as missing in the DA logs (look for the text "Missing critical driver detected :") you would see that DriversDB is missing something matching the PCI ID (look at the line similar to: PCI ID = PCI\VEN_8086&DEV_155A&SUBSYS_05CA1028&REV_04).

Your job then is to find the correct driver from the manufacturer, add it to Driver Management in the console, and try again.

Example 2: Driver injection fails due to missing drivers in the "mini" version of DriversDB in the production drive.

To determine this, first, you would see a warning and/or failure in DSTasks from the Eval run of DA, just like the above example.  However, upon checking the PCI and Vender ID, you'd find your drivers present in the network copy of DriversDB.  So, following the process through, you'd see your devices listed in the Driver List text file.  The DS Tasks log would show DA running the second time with a failure, and in the retargeting DS logs, you'd see a failure.  Since the process stopped due to failure, the Mini DriversDB folder would still be present, and you'd notice that the drives that matched in the full DriversDB did NOT get copied down to the local version, and thus, of course DA could not retarget them.

Your job then is to collect the entire logs folder, and contact support to notify them that the files which are present on the network are not in fact copied locally.  You should also be prepared with a copy of the drivers, OR a download location, so that Support can attempt to duplicate the issue.

Example 3: DA fails to properly retarget your drivers (similar to DS 7.1 troubleshooting).

To determine this, essentially, like the above two examples, the process works, and DA fails.  However, in this scenario, DA "says" there's a missing critical driver, but you can "SEE" a valid match in the Mini DriversDB copied to the local drive.

Your job then is to do one more troubleshooting step: try to run DA manually.  In the logs, you can see the execution of DA (see HOWTO95220 for how to determine this) and you should be able to test it manually.  This may indicate a difference in how DA runs as part of the task vs how it runs standalone and can help in discovery.  If you are not comfortable doing this, or even if you do, you should gather ALL the local logs, the driver files and/or download location for them, and detailed steps of how you came to your conclusion and contact support.