Monthly Archives: September 2012

SCCM 2012 Driver Deployment: strategy for driver packages

A well known discussion in organizations is providing a strategy to deploy drivers for all machines during an Operating Deployment. The biggest challenge is how to organize your drivers and how to organize them in one or more driver packages.

If the number of hardware models is significantly low, let’s say less than 5, then I suggest creating a single driver package and use the Auto Apply Drivers task to have them deployed.

If the number of hardware models is higher, then some detective work is required.

A good inventory is required to investigate the specifications of each device.

To keep things not too complicated, let focus on desktops and laptops only. These are typical devices managed by SCCM 2012. Keep in mind though that more devices can be managed by SCCM 2012 (especially with SP1).

Relevant questions you can ask yourself are the following:

  • How many devices are used?
  • What hardware is being used such as CPU, chipset, GPU, NIC, audio, etc.?
  • How many similarities exist between all devices? For example are all devices using an Intel CPU, or Intel NICs, or ATI graphics and so on.
  • Does one driver support many devices? For example the Intel Chipset drivers

The 3rd question is pretty important because it can help you determine how you want to organize your driver packages. In my opinion, two strategies are available:

  • Create driver packages for each model
  • Create driver packages for each hardware category

If you have many similar hardware, then it might make sense to create driver packages on hardware category. You use WMI queries to Task Sequence Variables to determine if a driver package needs to be applied to a device.

If almost similarities exist, then you can consider creating a driver package for each model (or models which use the same driver set).

Let’s illustrate this by an example:

You have 10 desktop models and 10 laptop models:

  • 5 desktop models are 5 laptop models are equipped with an Intel GPU
  • The other ones have an ATI GPU

In this scenario you can make 2 driver packages, one with the Intel drivers and one with the ATI drivers.

Both driver packages are added in the Task Sequence.

In the 1st task you query the hardware models who are equipped with the Intel GPU. Since the model names are available you can use them to creat your conditions.

The same thing is done with the 2nd for the other devices.


The main question is: why does anyone want to do it like this?

Answer: many driver manufacturers are providing the complete driver set for their hardware. All these driver sets take a great amount of space if you need quite a number of them. In my personal opinion, it doesn’t make much sense to have the same driver stored in your SCCM source location more than once. Having big driver packages also takes considerable more time distributing them if many Distribution points are used.

One other thing: if a driver package is applied, then the whole driver package will be injected in the Operating System installed on the device. The bigger the package gets, the longer it takes to inject it.

Sidenote: Auto Apply Drivers work differently. Auto Apply Drivers checks which drivers are required and will install the ones who are available.

If you have a more modular buildup of your drivers, then you can limit the disk space used and it will shorten the duration if the deployment. This work with ‘good’ drivers only…

Steve Thompson [MVP]

The automation specialist

Boudewijn Plomp

Cloud and related stuff...

Anything about IT

by Alex Verboon

Deployment Made Simple

Modern Workplace

Azure, Hybrid Identity & Enterprise Mobility + Security

Daan Weda

This site is all about System Center and PowerShell

IT And Management by Abheek

Microsoft certified Trainer -Abheek

Heading To The Clouds

by Marthijn van Rheenen