Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Driver injection - During Sysrep or post image boot?

Created: 29 Aug 2014 • Updated: 04 Nov 2014 | 12 comments
This issue has been solved. See solution.

Hello all,

Historically I have usually injected drivers via Sysprep mini-setup. So, the image comes down, Sysprep fires back up and mini-setup runs and puts the drivers into place. I edit the DevicePath registry to point to the driver location on the local drive and Syprep parses that. Sometimes I get driver issues with blue screen errors (USB 3 drivers are notorious) and have now started to look at alternative driver injection methods. This is for Windows 7/8. Also utilizing a DS 7.5 environment with PXE.

I know some engineers inject drivers with various scripting mthods after the image is laid down and booted.

What do you guys use? What's best practice these days? I only have a few models of laptops/desktops to support.

Operating Systems:

Comments 12 CommentsJump to latest comment

Sally5432's picture

I use Symantec's deployanywhere tool, but they broke it in 7.5.  Can't say I recommend relying on it as 8 months later it still doesn't work like it should/used to prior to 7.5.

There may be some ideas in my thread about it that might be of help to you

https://www-secure.symantec.com/connect/forums/75-...

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

tloenhorst's picture

Thanks for the feedback, Sally. Up to now I have not been using DA as I see some of the issues others, like yourself, have with it. I know others use custom VB scripts, etc for driver injection. I just wanted to see what others used and pros/cons. I have been using the sysprep injection method for years and it works well.

sfaucher's picture

We put the drivers into place in winpe after image deployment. We have a driver repository on each site server with a folder for each model containing a set of drivers extracted from the Dell or HP driver pack. A batch script copies them into place after querying the productname via wmic. The devicepath is in our custom answer file. Mini-setup then installs all the drivers during the boot to production. We also add one batch file to the driver folder for each model (OEMSetup.cmd) which is usually blank but in the few instances we find drivers that don't auto-install properly during mini-setup we put the manual unattended installation command lines in there and fire it off as a task in the deploy job after booting to production.

So our process for adding a new computer model is:

  1. Determine the full productname (model) for the new computer and create a folder named this in our driver repository.
  2. Download the driver pack cab from Dell or HP and extract the 64bit contents to this folder (we only support 64bit Windows 7).
  3. Copy in a blank OEMSetup.cmd to this folder.
  4. Perform initial deployment on the first new computer and verify that all drivers installed correctly.
  5. Add custom unattended installation command lines for drivers that didn't install automatically (rare)

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.

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 21GB. 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 driver versions working better than others.

Shawn Faucher | Senior Technology Analyst

Armstrong Teasdale LLP
 

Sally5432's picture

Shawn - this is good info.  I'd love ot try it sometime when I have the time to see if I could pull off something similar.  I wish Symantec would give up on DA as it is now and just support something like this that seems to work.  I guess the "add custom unattended installation command lines for drivers that didn't install automatically (rare)" would be a wildcard though.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

tloenhorst's picture

Indeed...good info. I would like to see those scripts you are using to query the product name. Especially helpful for Lenovo laptops that have fairly granular model name changes inside of a model line.

sfaucher's picture

Here you go:

@Echo off
REM Copy Drivers to production
Setlocal EnableDelayedExpansion

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\*.*" 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.  Reboot and retry after assigning C:
Exit 253

:End

Shawn Faucher | Senior Technology Analyst

Armstrong Teasdale LLP
 

SOLUTION
tloenhorst's picture

Awesome. Thank you!

Where exactly are you calling this from in the preboot environment? Is it wrapped up in your PXE image?

sfaucher's picture

No, it's a run script task that runs in automation after the image is deployed but before booting to production.

Shawn Faucher | Senior Technology Analyst

Armstrong Teasdale LLP
 

Sally5432's picture

thanks for posting this @sfaucher.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

jbanq's picture

Hey Shawn,

Thanks for the helpful post.  I've tried to implement this in our environment but I've run into issues.

I have a question regarding your Driver repository.  Did you just open up all the permissions to where you have your drivers?

While trying to keep it secure, I've only been able to make this work by adding permissons to the share for SYSTEM.

...maybe I'm implementing it wrong.

Any assistance would be greatly appreciated.

Thanks,

Jay

sfaucher's picture

We have the drivers in a windows share on each site server. We actually have several shares on the servers for other things as well, so we do the share authentication in a separate script, but you could add it to the driver copy script if that's all you needed.

To do this we add several tokens:

  • 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>'

Then the script looks like this:

net use \\%Siteserver%\drivers %SymPwd% /user:<domain>\%SymUser%

We're also looking into changing this into a DFS structure to simplify things and automate the synchronization of files but haven't tried it yet.

Shawn Faucher | Senior Technology Analyst

Armstrong Teasdale LLP
 

jbanq's picture

Thank you for taking the time to reply, Shawn.  I really appreciate it.  This has been very helpful.