SCCM 2007 – OSD driver good practice

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

For an SCCM 2012 version of this article, go to


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.




20 thoughts on “SCCM 2007 – OSD driver good practice

  1. Do you have any recommendations or potential issues with Windows 7 Clients? Any issues with SATA drives? I’ve found configuring systems with IDE works much better, obviously. SATA seems to be troubling with SCCM OSD.

    1. Sorry mike, you’ve lost me there.
      SATA troubling with OSD ? since when ? how, what etc ? if the drivers aren’t included in the PE3 image – add them to the boot image…. done. With Vista and Win7, i dont see how OS mass storage drivers could be any easier…. XP, yep, pain in the arse…. but theres just one additional step that can sometimes be a little finnicky – but definately do-able (and its just the price we pay becase this type of deployment wasnt around when XP’s installer was being created)

      Whats the exact problem your having ?

  2. Hi,

    This is a fantastic article. You have also touched on an SCCM issue I am facing. I have realtek WLAN driver ( a beta version) I want to use in a build. I have tried to include this in to the build using a Driver Package and also by injecting. However after the build I see an older version ofthe driver being reported in Device manager !!!. I have done my very best to get rid of the old driver from where I could see it within SCCM. Yet after the build it appears. I have also used DISM directly and checked if the WIM file had the driver — It didn’t have it. So I injected the beta driver. Still after build I get the old driver…. I am not sure where and what to do now… Please help..

    Thanks in advance.

    1. Hey Nalin… that can be a couple of things that i can think of:
      1. the “old” driver hasnt been removed from the driver package – even if you have removed it from the database. If your using “apply driver package” the database doesnt matter.
      2. the “old” driver is actually the windows driver…. and its just that the beta driver isnt being picked up as a newer driver. This is more likely IMO.

      On a machine which has the device you want to use the beta driver for, look up the hardware id in device manager, then open the driver inf and look for that PNP ID, if there isnt a match – theres your problem…. quickest way to “fix” it is to manually update the inf with the exact PNP ID of the hardware…. then it will definately use that driver…

  3. Hi

    Sorry. running without “auto apply dirvers didn’t work and it actually applied an older driver ( perhaps one already in the WIM.) I also checked the Hardware ID and ( there are 4 of them). One of them is in the .inf file .. I will have to build and capture as it looks like as usual SCCM is driving me a bit loopy.

    Only people like you, with your helpful blogs can throw a light on the SCCM beast.. It can wear one down.

    Thanks again in advance for any helpful hints you can give me on this.

    1. Mate, you’ll be better off at a forum style enviornment such as than posting this stuff as a comment on my blog! (forums are designed for many people to support you, blogs arent!)

      Anyhoo – you’ve lost me on a few things there.
      When you were talking about manually injecting driver…. i dont undersdtand why you would do that, since SCCM does it for you, in both the boot wim and the OS wim…. so whatever you have done there – get rid of it – it will be confusing things.
      You still havent mentioned if the “older” driver is actually the microsoft supplied driver – as that will explain it – if you have removed the “old” driver from all your packages and the drivers section of SCCM – it can only be the MS default driver.
      Flat out – if the hardware ID of the hardware is in the inf – and the driver is either imported or in an “apply dirver package” step (and is the right driver) – it will work. Have you made sure you have the correct driver by manually installing it on an already build windows 7 box ?

      Additionally, this is the type of thing i could probably solve in 5 minutes on site… so – surely you have a local SCCM consultant in your part of the world that you could call upon. A fresh set of eyes on an issue is always handy.

  4. I think you need to add an additional driver type, ther should be good, bad and UGLY!

    The Realtek Audio driver for XP seems to me to be an ugly driver, as in XP it will install correctly as a normal driver and also using the setup.exe bootstrap, however in both those scenarios, there is no sound from the device, the audio device does not function correctly.

    The only workaround is to install the setup.exe as a user (as opposed to above which uses the local system account), there is obviously something required by XP which occurs when installing using the setup.exe.

    Another reason to ditch XP……just 9500 XP machines to go……..

    1. 🙂 thats a fair call mike!

      and yes – deploying XP now, when its about to be N-3….. im guessing that wasnt your decision!

    1. good stuff guys… basic, but good idea!

      get a better host that softpedia though…. still trying to download the thing….

Leave a Reply