Deploying Windows 7 – Part 24: Managing Drivers – Issues and Approaches

By /


If you would like to read previous articles in this series, please go to:

Tip:
You can find more information about automating LTI deployment in the Windows 7 Resource Kit from Microsoft Press. I am the lead author for this Resource Kit and I also maintain the Unofficial Support Site for the Windows 7 Resource Kit with answers to questions posted by readers, as well as links to the latest resources on Windows 7 deployment, administration and troubleshooting.

In the previous article of this series we saw how to use MDT 2010 to inject a boot-critical out-of-box mass storage driver into a Lite Touch Windows PE boot image in order to deploy Windows onto a system for which no in-box mass storage controller driver was present. We also learned the steps for importing drivers into the Out-Of-Box Drivers folder of your deployment share. But what if you need to add dozens, hundreds or even thousands of out-of-box drivers to MDT for different operating systems you need to deploy, for different system architectures (x86 or x64), and for different makes and models of systems? In this article and the next few we’ll learn how to use new features in MDT 2010 to manage complex driver scenarios.

Why Drivers Complicate Deployment

Anything but the most simple deployment scenario involves deploying more than just an operating system. Real-world deployment scenarios usually involve deploying all of the following to target computers:

  • Operating system
  • Device drivers
  • Applications
  • Language packs
  • Patches for OS and apps
  • Customizations for OS and apps

Deploying drivers is one of the more difficult tasks of real-world deployment scenarios. One reason for this is because organizations with large numbers of computers tend to purchase them over time. The result is often a plethora of different makes and models of systems from different manufacturers and may even include custom-built white-box systems. The result is that many different drivers are needed to support all the different systems in your organization.

Another reason drivers add complexity to deployments is because drivers may not only be needed for the installed operating system to work properly, they may also be needed just to boot the system to start the installation process. As we saw in the previous article of this series, sometimes drivers (especially mass storage drivers but sometimes network interface card drivers also) need to be injected into the Lite Touch Windows PE boot media, otherwise you won’t even be able to boot the target computer to start deploying Windows to the computer. Fortunately with desktop computers, the generic Lite Touch Windows PE boot image created by MDT is usually able to boot the computer, connect to the deployment share over the network, and continue with the installation. For servers however, with their RAID cards and other goodies, you may need to add additional drivers to Windows PE just to get the installation started.

Another reason drivers make deployment difficult is because incompatibilities can sometimes arise. For instance, there are situations where installing the wrong driver on a system can cause the system to “bluescreen”. This can particularly be an issue with mass storage drivers. Or sometimes installing two similar drivers (one recent, one older) for the same hardware can cause the wrong driver to be installed because the vendor designed one driver poorly (e.g. malformed INF). Or sometimes the vendor releases a new driver for an updated version of the hardware and says that the new driver still supports the older version of the hardware, but when you try it you find out that the old hardware doesn’t work properly with the new driver.

Finally, when you are deploying the latest version of Windows such as Windows 7, both very new and very old hardware can often have driver problems. While Windows 7 has tons of in-box drivers, it may not have suitable drivers for hardware that was released after Windows 7 RTM’d. And Windows 7 may not include suitable drivers for hardware from the XP or earlier era. Unfortunately it can sometimes be difficult to find the right driver for your hardware on the vendor’s website (assuming the vendor is still around for older hardware). Then, once you have downloaded the driver, you may need to jump through hoops to extract the driver files so you can import them into your deployment share. That is because the Import Driver Wizard you saw in the previous article can only import drivers that have INF files available. Unfortunately, some vendors like to release additional device management software bundled along with their drivers, with the result that these drivers may have to be installed at the end of the deployment process by running the vendor’s Setup routine, which requires extra fiddling with your task sequence.

Different Approaches to Managing Drivers for Deployment

Then there’s the question of whether to try and control which specific drivers get deployed to which specific target computers during deployment, or whether you just want to let Windows use Plug and Play to decide which drivers should be installed on any particular target computer. In other words, there are basically two different approaches you can follow for managing drivers during deployment: the “let me decide” approach vs. the “let Windows decide” approach. We’ll look at the second approach first since it’s the simpler approach to implement. But before we do this, a little history.

An Outdated Approach to Managing Drivers

Most organizations perform their desktop deployments by building a master installation image and then deploying this master image to their target computers. We saw in article 10 of this series how you could use MDT to create a master image by deploying Windows (along with applications, language packs, patches and other customizations) onto a master (or reference) computer and then capturing a sysprepped image of that computer and uploading it to your deployment share. And in article 11 of this series we saw another way of creating a master image by starting with a preinstalled/preconfigured computer and using the new Sysprep and Capture task sequence to capture a master image from this computer. Either way, you first build your master image (or two if you need to deploy both x64 and x86 Windows) using an MDT server in your lab environment, and then you deploy your master image(s) to target computers using a separate MDT server on your production network.

Now when you build your master computer using your lab MDT server, you generally won’t want to inject any additional out-of-box drivers into your master image. Years ago, administrators building master images often used to add all the drivers all their different types of target computers needed to their master images. The result of baking all these extra drivers into their master image was often problematic—images were huge and difficult to maintain, and driver conflicts often caused problems—sometimes as severe as bluescreens.

Then BDD (the precursor to MDT) came along, and when BDD 2007 added support for Plug and Play enumeration the need for baking all your out-of-box drivers into the master image disappeared. Instead, you could now let Windows decide during deployment which drivers to pull down from the deployment share and install on each target system. Let’s see how to implement this approach now.

Using the “Let Windows Decide” Approach to Managing Drivers

In the “let Windows decide” approach you simply import all the drivers your different types of target computers will need into your deployment share. Then, when you use MDT to deploy your master image onto a particular system using MDT, Windows will use Plug and Play to determine which additional out-of-box drivers will need to be installed on each system by matching the PnP IDs of each hardware component with the PnP IDs supported by available drivers—in other words, by using Plug and Play enumeration.

The main advantage of this approach is simplicity. Since this is the way MDT performs Lite Touch deployment by default, there’s less initial time and effort needed for planning how to manage drivers for your deployment—you just dump them all into your deployment share and let MDT and PnP do their magic. And since almost no up-front planning or preparation is needed, you can get up and going very quickly by following this approach.

Here’s how it can work in practice. Let’s say your organization is in the process of transitioning from Windows XP to Windows 7 and has the following desktop systems:

  • Dell Optiplex 580 systems that will need either Windows 7 x64 or Windows 7 x86 installed on them
  • Dell Precision T3500 systems that will need Windows 7 x64 installed on them
  • Hewlett-Packard Pro 3015 Microtower systems that will need either Windows 7 x64, Windows 7 x86 or Windows XP SP3 installed on them.

Once you’ve downloaded all the drivers for these systems, copy them to a folder such as C:\Drivers on your production MDT server:


Figure 1: Dell and HP drivers to be imported into your deployment share

In this example, your downloaded driver files are organized into two folders (Dell and HP) with subfolders named after models. Then beneath each model folder are various subfolders for operating system (e.g. Windows 7 x64 vs. x86) or device (e.g. audio) or driver package ID number (for HP drivers).

To import all of these drivers into your deployment share, open the Deployment Workbench, right-click on the Out-Of-Box Drivers folder, and select Import Drivers to launch the Import Drivers Wizard. Then click Browse on the Specific Directory page and select the root C:\Drivers folder:

 
Figure 2: Select the root folder where all your drivers are stored

Click OK to return to the Specify Directory page:

 
Figure 3: Importing all drivers found under C:\Drivers

Note that what this does is it imports all drivers in C:\Drivers and in any subfolders beneath this folder. Click through the remaining steps of the wizard. The result will look something like this:

 
Figure 4: All the drivers needed for desktop deployment have been imported into the Out-Of-Box Drivers folder

Note that the import process may take some minutes to perform since there are hundreds of megabytes of drivers to import—and that’s only for three different make/models with a couple of different operating systems!

Now that all the drivers have been imported into your deployment share, you can use MDT to deploy your master image to your target computers. As the master image is being deployed, Windows will use PnP enumeration to determine which additional drivers in the deployment share will need to be installed on the target computer to ensure its hardware components function as designed.

This “let Windows decide” approach has the virtue of simplicity—are there any caveats? There’s really only one—driver conflicts may occur for certain types of hardware, especially if you’re deploying multiple operating systems from your deployment share. But if you’re only deploying a single operating system, for example Windows 7 x64, and you only have a few different makes and models of target computers, then this “let Windows decide” approach of simply dumping all your out-of-box drivers into your deployment share and letting PnP enumeration decide who gets what usually works just fine. On the other hand, if you test this approach in your MDT lab environment and you find that some systems get the wrong drivers installed on them (for example, a Windows XP Professional driver gets installed on a system you are deploying Windows 7 x86 onto), then you’ll need a different approach to managing drivers for deployment. That’s where selection profiles are useful, which is what we’ll look at in the next article of this series.

If you would like to read previous articles in this series, please go to:

About The Author

Mitch Tulloch is Senior Editor of both WServerNews and FitITproNews and is a widely recognized expert on Windows Server and cloud technologies. He has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press and other publishers. Mitch has also been a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management. He currently runs an IT content development business in Winnipeg, Canada.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top