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.
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.
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.
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:
Outputs from this process include:
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:
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.
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.
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.