Driver deployment with Microsoft Deployment Toolkit (MDT) – Part 1: OS deployment

• Author
• Recent Posts

Joseph Moody

Joseph Moody is a network admin for a public school system and helps manage 5,500 PCs. He is a Microsoft Most Valuable Professional (MVP) in Cloud and Datacenter Management and blogs at DeployHappiness.com.

Latest posts by Joseph Moody (see all)

• SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
• Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
• PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019

Concerning imaging, I would wager that the Microsoft Deployment Toolkit (MDT) provides the best functionality for the best price. After all, it is hard to beat free! Because of MDT’s automatic organization and extensible nature, an IT department can spin off some pretty great projects! Just in our environment, MDT took us from 51 separate client images to one image, allowed us to remotely image entire sites, and to completely get out of managing drivers! In this two part post, we are going to focus on that last project. We are going to structure a driver store and use our MDT share as a remote driver installation server. Through a little planning, we can make use of Windows’ automatic driver selection in order to deploy drivers in a Windows PE environment and in a full-blown operating system. Meaning that you, our Windows Administrator, will never have to visit a client to install a printer, scanner, or some silly device again. Got your attention? Good – let’s get started!

Note: This post assumes that your MDT environment is already configured. If you are just getting started with MDT, I would strongly recommend reading this Introduction to MDT as well as this excellent step-by-step walkthrough. Although they are written for MDT 2010, the setup and structure still applies.

MDT makes use of the Out-of-Box Drivers folder in order to organize imported drivers. By default, this folder is found at \\SERVER\DeploymentShare$\Out-of-Box Drivers\.

The Out-of-Box Drivers folder showing two created sub-folders

When organizing drivers, Microsoft allows you to logically organize based on any number of schemes. The scheme that I found to work the best is to divide drivers up by the intended operating system. To make organization easier, I then break up the operating system folder into architecture subfolders.

I keep hoping that Microsoft will kill the 32bit OS…

Finally, for every unique computer model that we have, a subfolder is created under the correct architecture folder.

Yes, we have a Latitude X1 running Windows 7

Note: The model folders above have to exactly match the model reported by each computer or driver installation will fail. If you would like to double check a model, simply run “wmic computersystem get model” from the computer in question.

Although this is a pain to setup the first time, it will make your driver management life very easy! When you retire a particular device model, you can simply delete the corresponding MDT driver folder. When a driver needs to be updated, you will always know exactly where to find it. A final subfolder that is created is a generic folder named “Other”. This folder holds all third party device drivers including those for printers, scanners, and other user-centric hardware. By storing all of our known third party device drivers here, we can have our imaging computers install drivers for any attached hardware. This means no more imaging a computer and having to come back later in order to install a personal printer!

Now that our Deployment Share has a driver folder for each model, we need to create a Selection Profile for each model. A selection profile essentially is a filter that can be used in our task sequence.

The selection profiles above include the default and custom selections

When you create a selection profile, you will be prompted for a name and a folder to select. For the model specific profiles, select only the corresponding driver folder.

Select the driver folder for model specific profiles

The final piece to the puzzle is a rather simple change in our task sequence. Under the PreInstall section, we will create a new “Set Task Sequence Variable”. It should look like:

Create a new “Set Task Sequence Variable”

This variable basically tells the task sequence to only search for applicable drivers under the equivalent computer model folder. We next need to alter our existing Inject Drivers task. It should be changed to the following:

Alter Inject Drivers task

Now, we need to make sure those pesky third party devices get installed. To do this, add a new Inject Drivers task directly below the existing one. It should look like:

New Inject Drivers task for third party devices

And for our last edit, we will disable the post Inject Drivers task. Select the Inject Drivers task under PostInstall. Select Options and then Disable this step.

Disable Inject Drivers task under Postinstall

We are done and ready to image! When a computer connects to the deployment share and beings a task sequence, it will query the local model. Using that model as a reference, it will now only download the specific drivers needed! Finally, it will search for any drivers needed in the Other folder. This will catch any attached user hardware.

In the next post I will discuss how to deploy Windows drivers after Windows is installed.