HayesJupe's Blog

SCCM OSD – Driver best practices


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 ten 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.

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.

  1. DRV.Lenovo.T500.XP.x86
  2. DRV.Lenovo.T500.Vista.x86
  3. DRV.Lenovo.T500.Win7.x64

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

  1. Network, Display, Chipset, Audio, Modem, SATA

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

  1. 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.
  2. Extract the drivers into a temporary folder
  3. 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

  1. Give the package a name matching the folder name (e.g. DRV.Levono.T500.Vista.x86)
  2. <optional> Use folders to split your driver packages by OS/Arch or make/model
  3. Specify the driver package source (where your clean set of files are stored)
  4. Distribute your driver package to DP’s

6)    For Windows XP Driver packages only:

  1. Windows XP requires mass storage drivers to be specified for each model (This is not required for Vista/Win7)
  2. Because the vast majority of hardware uses Intel SATA chipsets, this one driver is likely to be the only mass-storage driver required
  3. Import the mass-storage driver into the driver database (only if it does not already exist)
  4. 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)

  1. 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

  1. 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>

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

                                          i.    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

  1. Add task using the same task sequence variable as above
  2. 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

  1. 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.

20 Comments »

  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.

    Comment by Mike — September 20, 2010 @ 9:20 pm | Reply

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

      Comment by hayesjupe — September 21, 2010 @ 6:31 am | Reply

  2. [...] [...]

    Pingback by [SCCM 2007] OSD Best Practice — September 5, 2011 @ 10:29 pm | Reply

  3. 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.
    Nalin.

    Comment by www.whitmore.harrow.sch.uk — November 10, 2011 @ 4:31 am | Reply

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

      Comment by hayesjupe — November 10, 2011 @ 10:10 am | Reply

  4. 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.

    Comment by Nalin — November 10, 2011 @ 8:26 pm | Reply

    • Mate, you’ll be better off at a forum style enviornment such as http://www.myitforum.com 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.

      Comment by hayesjupe — November 11, 2011 @ 6:37 am | Reply

  5. Thank you so much for your article. It is the best step by step on how to do it. Thanks alot!

    Comment by FixZitNow — December 2, 2011 @ 1:26 am | Reply

  6. Great article!

    Comment by C — February 3, 2012 @ 3:19 am | Reply

  7. [...] Decide which driver deployment method you are going to use.  More detail can be found here – http://hayesjupe.wordpress.com/sccm-osd-driver-best-practices/. Basically, if you have bucketloads of different makes/models in your organisation, then creating [...]

    Pingback by How to determine which drivers to update « HayesJupe's Blog — February 22, 2012 @ 6:26 am | Reply

  8. [...] SCCM driver best practice articles by Hayes Jupe suggests separating good drivers from bad drivers and provides a few examples. Given the absolute [...]

    Pingback by Folder Structure for Windows Images and Drivers in Win7 Server2008 & Server 8 | Interface Technical Training Blog — March 29, 2012 @ 6:57 am | Reply

  9. 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……..

    Comment by Mike — July 3, 2012 @ 8:02 pm | Reply

    • :-) thats a fair call mike!

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

      Comment by hayesjupe — July 4, 2012 @ 5:39 am | Reply

  10. Do you have a solution for SCCM 2012?

    Comment by Michael — July 4, 2012 @ 11:07 pm | Reply

  11. FYI, the “creating driver packages without importing into the database” will fail when migrating to Configuration Manager 2012. http://blogs.technet.com/b/michaelgriswold/archive/2012/09/19/404-for-driver-packages-can-t-find-content.aspx

    Comment by Mike — December 13, 2012 @ 2:06 pm | Reply

    • Yep – it will….. fair point, I should make a note of that in the main article….

      Comment by hayesjupe — December 14, 2012 @ 8:00 am | Reply

  12. [...] SCCM OSD – Driver best practices [...]

    Pingback by SCCM OSD – Driver best practices | IT Info — April 11, 2013 @ 3:31 pm | Reply

  13. We have just designed a program that retrieves the correct model information from your machine and then creates the correct WMI query for that model to use in Install Drivers task sequence steps, its available from here: http://www.techygeekshome.co.uk/2013/10/get-wmi-query-v13-released.html Hope it can help…Thanks.

    Comment by Techy Geeks Home (@TechyGeeks1) — October 14, 2013 @ 2:23 am | Reply

    • good stuff guys… basic, but good idea!

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

      Comment by hayesjupe — October 17, 2013 @ 10:54 pm | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 28 other followers

%d bloggers like this: