Troubleshooting Drivers and Driver issues in Deployment Solution 

Desired Outcome:

You will understand how to do basic troubleshooting, problem isolation, and collecting of information/logs to either 1) find answers online through the KB and Forums or 2) if necessary, escalate to Support and get quick answers from them.

Process:

Step 1: Understand what "category" of driver issues you are having

There are 3 categories of Driver issues: Automation Environment, Driver Management, and DeployAnywhere.  Let's quickly look at each so you know what category of issue you have.

1. Automation Environment
   
   This category describes those drivers necessary to communicate on the network when in Automation.  They are added to BootWiz or the preboot environment if you built your own.  They must be compatible both with your hardware, and with the automation environment to which you are booting.  The production or "normal" environment you boot the computer to makes no difference here, because you will be rebooting to an automation environment which is an entirely different OS.
   
   In DS 7.5, generally that means booting to WinPE 4.0, which is a lite version of Windows 8.  That means you will need drivers for Windows 8 or Windows 8 compatible drivers (e.g. many Windows 7 drivers also work, but Windows XP drivers almost certainly will not).

The following is a list of WinPEs and the OS Build version drivers supported for the NIC cards.

WinPE 3.0  =   Win 7.
WinPE 4.0  =   Win 8.
WinPE 5.0  =   Win 8.1
WinPE 10 =  Win 10
WinPE 11 =  Win 11

In DS 8.0, support has been added for WinPE 10. DS 8.6 has added support for WinPE 11.

The drivers are imported or added to the system in one of two ways: 1) From the console using Settings | Deployment | Driver Management and the selecting the BootWiz tab, or 2) by running BootWiz directly from the file system (not documented here).

A common symptom of not having drivers is a DHCP Retry message that appears when you boot to WinPE Automation, or an inability to ping or otherwise communicate on the network when there.

Common verbiage may include things like "Automation Environment drivers" or "Drivers for BootWiz" or "BDC Drivers".
 

2. Driver Management
   
   This category overlaps the next category of DeployAnywhere in that the driver set is the same, but the use-case is very different!  It is very important that when researching and/or contacting support you know the difference.
   
   For a driver to be used in Hardware Independent Imaging and/or by DeployAnywhere, it first must be imported into the system.  This can be done in two ways: 1) From the console using Settings | Deployment | Driver Management and then selecting the DeployAnywhere tab, or via command line using Driver Manager directly (not documented here).
   
   The key difference in this category and the next is that Driver Manager and the console is involved, but DeployAnywhere is not involved at all!
   
   During this import, Driver Manager no matter how it's called, both adds the drivers, and creates a manifest file for the drivers which DeployAnywhere uses later.  It also updates a master Driver Manifest file that lists all your drivers, again, for DeployAnywhere to use later.
   
   Common symptoms of problems in this category include getting an error when importing the driver, or getting no response at all, not showing the driver in the console after importing, and corrupt or missing driver manifest files.  Additionally, all symptoms from the next category (DeployAnywhere) may apply.
   
   Common verbiage may include things like "Adding Drivers for DA" or "Driver Management import problems for DA or DeployAnywhere"
    
3. DeployAnywhere (DA)
   
   This category overlaps the previous category of Driver Management in that for DA to work correctly, the drivers first must be imported into Driver Management.  So, though the driver set is the same, the use case is different, because now the Driver Management step is complete, but DA has to retarget these drivers, or rather copy those drivers to your production image you just deployed!  Driver Manager is not involved at all at this point in the process.
   
   For a driver to be used by DA, first, you must be in an Automation Environment (see the Automation Environment discussion above) and the drivers must be available for use - that is, replicated to your site servers.  DA is called from the X drive while in automation (either included or copied there) and copies drivers from the DriversDB location to the production system for use.  The "production system" in this case is either the new image you just deployed with a "Deploy Image" task, OR the new image you built with a Scripted OS Install task.
   
   Common symptoms of problems are rarely seen in automation unless DA actually fails.  If it does, it's because of missing critical drivers usually, and then the Deploy Image task will fail and you will be left in automation.  The more common symptom though is that when the computer is rebooted, either it wont start correctly or many drivers are missing once in production.
   
   Common verbiage includes things like "missing Audio or Video drivers after reboot" or "The system wont restart when using DA" or even "The Deploy Image task fails, but works if I turn off DA".

Step 2: Problem Isolation and Basic Troubleshooting

As with Step 1, what troubleshooting steps you take depends on which issue you have.  Therefore, there are 3 short sections below to relate to each.

Automation Environment

First, remember that you need drivers for the automation environment, not production.  In DS 8.x  that means finding Windows  10 or 11 drivers for WinPE.  The drivers that matter are Network and Storage drivers, so you need drivers for any have in any hardware you own, and these need to be imported into BootWiz via the console as outlined above.

Troubleshooting is moderately simple, especially if you use PXE for delivering the Automation environment.  Boot a computer into Automation / WinPE, and see if it works.  If not, find the drivers for the NIC(s) on that system, import, rebuild the automation environment (under Settings | Deployment | Preboot Environments)(remember to let the drivers replicate to site servers if necessary) and test again.

If you are not using PXE, troubleshooting takes on a new complication of having to re-distribute the automation environment.  For instance, if you are using Automation Folders, after the "rebuild" process completes, you then have to follow the KB on making sure your automation folders are upgraded.  If you are using a thumb drive or CD, the "Rebuild" process changes into launching BootWiz manually and then rebuilding the CD or Thumb Drive.

If you can not find drivers, or make them work, you should normally contact the system manufacturer first.  Symantec does not supply drivers other than the ones that come with the product - which are very generic and relatively limited in support for newer hardware.

One way to verify if the drivers actually imported and are available for use is to check for a folder created in BootWiz.  Look on the Notification Server / SMP server under:

Program Files\Altiris\Deployment\BDC\bootwiz\Platforms\WinPE\x86(or X64)\Drivers

There should be a STD folder for the ones we ship with the product, and a CUSTOM folder where your drivers are copied to.  You should search for the INF file if you can't find it by folder name and simply verify that the drivers exist.  Both folders are compiled into the PE environment on rebuild.

Driver Management

The number of drivers needed to make this work is much bigger than those for the Automation Environment.  First, you need drivers for every version of OS you deploy (e.g. Windows Vista, Windows 7, Windows 8, Windows 2012, etc), and second, you need drivers for NIC & Mass Storage at a minimum, as well as for any other hardware you want to support, like Video, Audio, USB, Bluetooth, etc.  In fact, some go so far as to download entire driver packs from manufacturers and import them en-masse using the command-line interface of Driver Manager (not documented here).

Troubleshooting is more simple than you might think, because for this section, we really don't care if the drivers actually work in your OS!  Granted, you care, but that's for the next section, not this one.  All we care about is if the drivers are imported, and if the driver manifest files are created correctly.  In short, the import process consists of 3 steps: 1) Copy driver files to the appropriate folder, 2) extract information from the INF file for a driver manifest file and 3) compile the driver manifest data into the master driver manifest file.

The import success and/or failure is seen up-front when you do it.  If you get a failure, look first for support-ability (e.g. we don't support CAB or EXE's for import) and then if you're positive the driver is correct, you may need to contact support.

Another way to check is to simply look at the folder structure.  The drivers are copied to:

Program Files\Altiris\Deployment\DriversDB

Search for the folder, if you know the name, or the INF file if you do not.  If the files are not present, obviously the import did not work.

There should also be a Manifest file in this folder called "drivers.manifest.txt" in this folder.  If not, then the import did not complete or run successfully.  This manifest file should contain a portion of the top of the INF file formated into valid XML.  Garbage characters or invalid data is obviously a bad thing.

Finally, verify the data from this manifest file was added to the master Drivers.Manifest.TXT in the DriversDB folder.  If the data is also there, then the process is complete and successful, even if the drivers don't ultimately help you in the long run!

NOTE:  It is perfectly safe to delete these manifest files as a part of troubleshooting.  Search on the root of DriversDB for Drivers.Manifest, and wipe them all out.  Then in the console, launch Driver Manager by selecting Settings | Deployment | Driver management and all the manifest files will be re-created.  If you have issues with them, or they do not exist, or whatever, try this step before contacting support.

DeployAnywhere (DA)

For this step, we will assume that you have imported drivers into Driver Management already and that this process worked.

Troubleshooting is a bit more difficult for this step, but you should be aware of the following:

• • After booting to production, if drivers are missing, try using Device Manager to point to the DriversDB folder and see if the drivers are found.  if so, then something in the DA process is not working correctly.  If not, then you are probably missing drivers and should return to the Driver Management section and get new drivers to add from the manufacturer.
  • DA logs it's process in automation.  These logs are copied to production during the "Reboot To" production task (translation, if you do not run a reboot to production task and reboot another way, the logs are lost).  The logs can be found here:
    Automation: x:\program files\symantec\deployment\logs
    Production:  %\Program Files\Altiris\Altiris Agent\Agents\Deployment\PreOS_Task_Logs

Some keys to knowing what is happening:

• • Try running the Deploy Image or Scripted OS Install task without DA selected and see what if any difference there is in the outcome of the task.
  • Be sure the drives you THINK are present, really are, in the Driver Manager section.
  • Be sure the DriversDB package has replicated to the site servers.  This can take several minutes depending on your configuration, but will rarely take less than 15 minutes.  So, unless you're imaging directly from the SMP, you may want to add drivers, and then wait 30 minutes, or manually check the site servers to ensure the DriversDB package actually replicated.

Step 3: Be prepared to get further help!

The focus of this step is to ensure that if you go to the forums, to a friend, or even need to call support, you have all the files and details you need to get answers fast.  Here's what we recommend:

1. 1. Be prepared with the proper verbiage.  Tell whomever you are getting help from where your problem is, accurately, by not simply saying you're having a problem with imaging or drivers, but by telling them what kind of problem it is, and where/when.  Automation after imaging, Automation before an image and we can't connect, Can't add drivers into the console - be accurate.
   2. Have logs / files in the ready.  The logs gathered depend on which scenario:
      1. For BootWiz, there's actually a BootWiz log file that has a TXT extension and is created on Site Servers under the LOGS folder at the same level as the BDC folder (in earlier releases it was in the same folder as the BootWiz executable).  You may as well capture that, AND the DSTasks.LOG in the same folder.  You should also have the actual drivers ready to send to support to see if they get the same results.
      2. For Driver Manager, the logs are few, but you might consider the a.LOG of the time you were testing.  You may as well zip up the entire folder.  As with BootWiz, have your drivers in the ready.
      3. For DA, you'll need all the logs in the locations indicated under troubleshooting (x:\program files\symantec\deployment\logs).  Generally we wont ask for drivers unless you also had troubles with Driver manager.
   3. Be prepared to show them exactly how you got to your problem, with steps like "This is what my Deploy Image task looks like, and it's in this job with these steps around it" or "I clicked on Settings | Deployment | ... to get this error - and here's a screen shot".  This speeds things up a LOT!!

Conclusion

You can do this and get answers fast, if you understand the processes.  Be familiar with all 3 tracks above and how they differ and not only will you get faster answers, you'll be able to help others as well!