Updated on :  03/02/2015
Relevant to:   SCCM 2007 (including R2 and R3 versions)

For an SCCM 2012 version of this article, go to http://hayesjupe.wordpress.com/sccm-2012-osd-driver-good-practice/

---

 

My existing articles on this site point to a great post by the deployment guys on driver management – however i still get asked a lot, which driver management methodology do i use…. well…  here it is…

Driver types

Drivers can very broadly be split into two categories:

• Good Drivers: Drivers which come in an inf/sys/cat format and can be installed on systems easily
• Bad Drivers: Drivers which come with a setup program and must be installed (common examples are laptop Bluetooth drivers)

It is very important that the driver type is correctly identified. Many drivers come in an .exe format, but can be extracted to expose the inf/sys/cat files. Whenever working with drivers, you should always try and install everything possible as a “good” driver.

---

 

Driver import methodologies

There are 2 main driver import methodologies that can be used in SCCM for “good drivers”:

• Import drivers in SCCM database
• Create driver packages without importing into driver database

Each of these methods has their pros and cons:

Importing drivers into driver database

• Pros
  • Allows use of “auto detect drivers” in task sequences
  • Very quick and easy
  • Allows drivers to be imported into boot images
  • Only a single version of each driver can be imported
• Cons
  • Driver database can get very large, very quickly
  • Driver categories can assist with sorting, but can still cause confusion
  • Badly written drivers may identify themselves as the same driver version as a previous version, and therefore not import

Creating driver packages without importing into database

• Pros
  • Very clean – ensures no conflict of drivers
  • Easily updatable – ensures that an update to one driver package will not impact on another model
  • Each model/OS combination has very defined set of drivers in use – makes troubleshooting any driver related issue much easier
• Cons
  • More effort required to identify drivers for each model
  • Duplication of existing drivers

---

 

My recommendation

I recommend using the “creating driver packages without importing into the database” for any environment where more than twenty makes/models are in use. I recommend this model primarily for compatibility, as you can ensure that updating drivers for one model will not cause issues with any other models.

Note: Generally driver “quality” has improved since this article was originally written in 2010. If your environment is primarily Windows 7 (or above), utilising auto-apply drivers seems to have less conflicts than it previously did, especially when not using Windows XP.

---

 

Driver package process

In order to identify and create driver packages, the following process should be completed:

1)    Identify the make/model which you a targeting

2)    Create an appropriately named folder structure, including the make/model, OS and architecture e.g.

a) DRV.Lenovo.T500.XP.x86

b) DRV.Lenovo.T500.Vista.x86

c) DRV.Lenovo.T500.Win7.x64

3)    Create sub-directories for required drivers e.g.

a) Network, Display, Chipset, Audio, Modem, SATA

4)    Identify the correct drivers for the model from the manufacturers web site

a) For drivers such as Intel chipsets, Intel and Broadcom network adapters – these should be obtained from the Intel/Broadcom   site, not the Lenovo/Dell/HP etc. site.

b) Extract the drivers into a temporary folder

c) Copy only the required files into the driver folder structure

i) Strip out files not required for driver installation such as setup.exe’s

ii) Locate the folder where the *.inf, *.sys and *.cat’s are located

iii) Identify the one set of inf/sys/cat’s required

iv) Additional files such as dll’s etc may be required

v) Avoid copying entire directories, you will bloat your driver packages

vi) Using an existing build laptop can help you identify which exact files are required

5)    Create a driver package in SCCM

a) Give the package a name matching the folder name (e.g. DRV.Levono.T500.Vista.x86)

b) <optional> Use folders to split your driver packages by OS/Arch or make/model

c) Specify the driver package source (where your clean set of files are stored)

d) Distribute your driver package to DP’s

6)    For Windows XP Driver packages only:

a) Windows XP requires mass storage drivers to be specified for each model (This is not required for Vista/Win7)

b) Because the vast majority of hardware uses Intel SATA chipsets, this one driver is likely to be the only mass-storage driver required

c) Import the mass-storage driver into the driver database (only if it does not already exist)

d) Add the mass-storage driver to your driver package

i) Right click on the driver

ii) Select “add or remove drivers to packages”

iii) Select your driver package

iv) Update the distribution point(s)

e) In the task sequence, select the specific mass storage driver required (see example below)

---

“Bad driver” package process

“Bad Drivers” are just another application which must installed, similar to acrobat 9 or office 2010. Standard packaging processes should be followed for these applications.

---

 

Adding driver packages to a task sequence

To target machines correctly, a step specifically targeting the make and model should be added.

1) Get the model name from the existing machine by typing

a) WMIC CSProduct Get Name

2) Create a “Apply driver package” task near the existing “apply driver” tasks

3) Enter the appropriate driver package

4) In the options tab, enter a task sequence variable of model equals <model name>

a) In the case of some models, there are long rambling characters in the model string. E.g. HP Elitebook 590 WRERTYG67In this case, use a WMI query instead such as

b) Select * from Win32_computersystem where model like “%HP Elitebook 590%”

5) For any “Bad” drivers which must be installed, the task must be added once the operating system is installed

6) Add task using the same task sequence variable as above

7) This task must be after “setup windows and SCCM” and generally should be before applications are installed or user state is restored

---

 

Adding boot image drivers

Boot image drivers are injected in Windows PE and provide local disk and network access; which are required to initiate a build process.

SCCM 2007 SP1 installations use Windows PE 2.x (Based on Vista)

SCCM 2007 SP2 installations use Windows PE 3.x (Based on Windows 7)

1)    Identify the network and mass storage driver required for your version of Windows PE and your hardware model

a) Remember, this is not the same driver as the OS you are installing, it’s the driver required for the version of windows PE your using in your boot image

2)    Import the driver into the SCCM driver database, with a category of “Windows PE boot drivers”

3)    Go into the properties of the appropriate boot image, go to the “Windows PE” tab and add the appropriate drivers

4)    Click on ok, then accept the message which will re-compile and distribute your updated boot images

---

 

Updating drivers

When updating drivers, simply remove the old driver folder contents, e.g. network and replace with the new drivers, update the DP, then test.

---

 

Common mistakes

Importing all drivers you can find – This bloats the driver database, creates possible conflicts and makes drivers harder to manage

Adding too many drivers to boot images – Boot images only require network and mass storage drivers, nothing else. Adding wireless, audio, gfx etc. drivers just bloats the PE boot wim, increasing build times.

 

---