A Simple Alternative to DeployAnywhere for Hardware Independent Imaging Drivers

Introduction

We've been doing Hardware Independent Imaging (HII) since DS 6.5, long before DeployAnywhere came along. When were first determining the process, we looked at several driver management tools and they all had the same issues. They worked fine for 95% of the drivers, but there were always 5% that just would not work, even though the drivers auto-installed just fine if they were in the Windows DevicePath. Finally we decided that the benefits of a driver database and avoiding driver replication just weren't worth the hassle. The method we've been using since then was developed on Windows XP and has worked flawlessly on every release of windows since then (actually getting simpler with the death of HAL files in Vista).

Preparation

First we set the DevicePath in our base image to add C:\Drivers. We then take advantage of the Driver packs available from most major business PC manufacturers (we use Dell and HP and both work great). We have a driver repository in a windows share called 'Drivers' on each site server. This share contains a folder for each model with subfolders containing drivers for each OS version we support, and a third folder called 'Common' for drivers that work for any windows OS. Within these folders we extract the driver packs. We also add one batch script we call 'OEMSetup.cmd' which for the vast majority contains nothing. In the very few cases we have drivers not fully install automatically during minisetup, we add command lines to this script to be performed after imaging in production. These driver folders can be synchronized using whatever method of fileshare replication you like (DFS for example).

The job scripts also need several tokens (Settings>Deployment>Tokens) to access the driver folders:

Siteserver token:

select c.name from TaskTargetDeviceCache vc 
   left outer join Inv_Client_Task_Resources ctr 
      on ctr._ResourceGuid = vc.Guid 
         And vc.Guid = '%COMPUTERID%' 
   left outer join Inv_Client_Task_Servers cts 
      on cts.ClientTaskServerGuid = ctr.ClientTaskServerGuid 
   join vcomputer c on cts._ResourceGuid = c.guid

SymUser token:

Select '<symantec network username>'

​SymPwd token:

Select '<symantec network user password>'

Deploy Image Jobs

Our image deployment jobs then contain a deploy image task with DeployAnywhere unchecked, a Driver Copy run script task appropriate to the OS being deployed, a boot to production task, and a run script task to execute the 'OEMSetup.cmd' script. 

The Driver Copy run script looks like this:

@Echo off
REM Copy Drivers to production for Win7 x64
Setlocal EnableDelayedExpansion

Echo Authenticating with Site Server
net use \\%Siteserver%\drivers %SymPwd% /user:<domain>\%SymUser%

Echo Retrieving Model Name...
For /F "tokens=2 delims==" %%A In ('WMIC computersystem get model /format:VALUE') Do Set STR=%%A
SET MODELNAME=%STR%
For /L %%A in (1,1,50) Do If "!MODELNAME:~-1!"=="" (Set MODELNAME=!MODELNAME:~0,-1!)

Echo Copying Driver files...
xcopy "\\%Siteserver%\drivers\%MODELNAME%\Common\*.*" C:\drivers /S /Y /I
xcopy "\\%Siteserver%\drivers\%MODELNAME%\Win7\X64\*.*" C:\drivers /S /Y /I
If %ERRORLEVEL% Neq 0 Goto DriverFail
Goto End

:DriverFail
REM driver copy failed.  This may be because C: is not mounted or is 
REM mounted as RAW.  Retry after manually assigning C: using diskpart
Exit 253

:End

The script authenticates with the site server share, queries the model name of the computer via wmic and then copies the contents of the appropriate OS and Common folders from \\%SiteServer%\drivers\%modelname%\ into C:\Drivers. Note that for WinXP you may also need to copy correct HAL files into place. We stopped supporting XP before we switched to 7.x so you'll need to track down that information elsewhere. Mini-setup then installs all the drivers automatically during the boot to production. Finally after the boot to production the OEMSetup.cmd script is run to finalize anything that doesn't work automatically.

Integrating New Hardware

With all this in place our process for adding a new computer model is:

1. Determine the full model name (also known as productname in the BIOS) for the new computer and create a folder named this in our driver repository.
2. Download the driver pack cabs for each OS we support from Dell or HP and extract them to the appropriate subfolders.
3. Determine if any drivers are universal (applicable to all OS versions) and move them to the Common subfolder.
4. Copy in a blank OEMSetup.cmd to this folder.
5. Perform initial deployment on the first new computer (which deploys our standard image) and verify that all drivers installed correctly.
6. Add custom unattended installation command lines for drivers that didn't install automatically (rare, so far only bluetooth drivers)

Closing

This works extremely well for us. We currently support 24 different models, both Dell and HP, laptops and desktops, and only two require any OEMSetup customization (both older models, both bluetooth drivers). We've never had a single issue with USB3 drivers, which seem to plague everyone else. Note that extended configuration applications for things like video cards (like AMD Catalyst) do not automatically get installed. If you want these (we generally don't) their setup command lines need to be added to OEMSetup.

The one downside to our method is driver duplication. Since many models have the same base hardware, the drivers are duplicated in each model subfolder. The total storage required for all 24 models' driver folders is currently 21GB per site server. Honestly, slow storage is cheap and we really don't care about this. In fact it makes it easier when some models are finicky about certain (older) driver versions working better than others.

Hopefully this helps those of you looking for a simple alternative to DeployAnywhere. Good luck!