Driver Management (Part 1) - Configuration Manager
I am often asked what the best way is to manage drivers with both BDD/MDT and ConfigMgr. With this in mind I thought I would create two blog posts dealing with this topic. The first post (this one) will cover ConfigMgr and the second BDD/MDT driver management.
Please note this is not the only way to manage drivers, there are many different ways to manage drivers. However this is an approach that I have used many times with much success.
Overview
Before I get into the details I would like to provide a quick overview of driver management.
The first thing we must understand is the type of drivers that you need to manage. I place drivers into two categories:
- NICE Drivers - Drivers that install using an INF file.
- BAD Drivers - Drivers that must be "installed" - This could be a Bluetooth driver, finger print reader software or even DVD software that is specific to a particular model type. I also refer to these drivers as "Hardware based applications".
Next we need to understand where drivers are used during the deployment process. There are two areas where they are used:
- Host OS - These are drivers that are installed on the Host OS.
- Boot images - These are drivers that are required by the ConfigMgr Windows PE boot images to enable OS deployment. The key driver types are network and mass storage drivers.
Finally we need to understand the options ConfigMgr provides for installing drivers. Whenever you import drivers you must add them to a driver package. Once the drivers have been added to a package there are two methods you can use to install the drivers:
- Auto apply drivers - Driver packages are primarily for distribution purposes. ConfigMgr performs a PnP scan of the computer and chooses which drivers to install from all available drivers in all available driver packages. You can filter by driver categories, is tells ConfigMgr to only consider certain categories when choosing drivers.
- Apply driver package - All the drivers in the package are injected, whether they are needed or not.
So now that I have covered the basics lets discuss how I manage drivers.
Process
I find the simplest way to describe how I manage drivers is by using an example. The example I will use I perhaps the most common scenario in OS deployment, adding support for a new hardware model.
At a high level the process involves the following steps:
- Create a new package that contains all of the required drivers for this hardware type
- Add an “Apply driver package” task to the task sequence with a WMI filter based on model type
- If required I configure the “Apply driver package” to apply a Mass Storage driver
- Create an application for each driver that must be installed
- Add all applications to the task sequence with a WMI filter based on model type
I can hear everyone asking the question, why do I use the "Apply driver package" process rather than the "Auto apply drivers" process? Well nice of you to ask, I appreciate the flexibility that the "Auto Apply Drivers" action gives but it does not cover all scenarios. I prefer to use one method of driver installation that will install all drivers (simple is best). The two scenarios that are not covered by "Auto apply drivers" process are:
- Devices that aren’t found by a PnP scan such as USB devices, multi level drivers and devices not enabled during deployment (like Bluetooth).
- Mass Storage drivers. On pre Vista operating systems, boot critical drivers have to be installed with Apply Driver Package.
The second obvious question is what is a WMI filter and why do we use it? You cannot add one “Apply driver package” task to the task sequence that will automatically determine the hardware and install only the package you require (this is what I would like :)). So to get around this issue you need to add an "Apply driver package" task to the task sequence for each hardware type. You do not want to apply every package to every machine so we need some way of ensuring that each package is installed on the correct hardware type only. Fortunately ConfigMgr has the ability to filter tasks based on a WMI query.
It is also worth noting that if a Mass storage is required for a particular hardware type then ConfigMgr will inject it for you! This was not previously possible with pre Vista operating systems. This is one of my favourite features of ConfigMgr.
Steps
So enough of all this talk lets get down to the actual steps required to implement driver management.
Create a driver package (GOOD Drivers)
1. Gather together all of the good drivers for the new hardware type and place them in a folder.
2. Open the deployment console and Navigate to Site Database - Computer Management - Operating System Deployment - Drivers
3. Right click on Drivers and select Import (This will launch the Import new driver wizard)
4. On the Locate Driver screen select Import all drivers in the following network path (UNC)
5. Specify a UNC path to your drivers folder in the Source folder field and click Next
6. On the Driver Details screen ensure all drivers are selected and click Next
7. On the Add Driver to Packages screen click New Package
8. On the New Driver Package window update the Package Name filed will an appropriate name (e.g. Toshiba - Tecra M5)
9. Update the Driver Package Source field with an appropriate location, this will most likely be stored with your other packages. Click Next.
10. If you need to add any network or mass storage drivers to your boot images then perform the following step. On the Add Driver to Boot Images screen select any boot images that require the updated drivers and click Next.
NOTE: You will need to update the boot image distribution points for this change to take effect.
11. At the Summary Progress and Confirmation screens accept the default settings and Close the wizard.
12. Once you have created your driver package then you should assign it to distribution points at all sites where this hardware type is deployed.
Add driver package to the task sequence
Once we have created the driver package we need to add it to our task sequence.
1. Create a folder that will contain all of your "Apply Driver Package" tasks. This folder must be added before the Setup windows and ConfigMgr task. When I have a group of similar tasks to add to the task sequence then I create a folder for these tasks. This is shown in the screen shot below.
2. Add an "Apply Driver Package" task to this folder specifying the driver package that you have created in the previous step. If this model type requires a mass storage driver then select it as shown below.
3. Next we need to add a WMI condition to this task. The first thing we need to do is determine the value of the WMI model field for our hardware type. I have found the simplest way to do this is via a WMIC query.
The following steps detail how to perform a WMI, ensure that these steps are run on the new hardware NOT the server:
a. Open a Command Prompt
b. Type WMIC
c. To determine the Model, type CSProduct Get Name
4. Select the task Options tab
5. Select the Add condition drop down menu and select Query WMI.
6. Add the following text to the WQL Query field where <MODEL> is replaced by the WMI value for your hardware type - SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" and click OK
NOTE: For some model types there can numerous variations of the WMI model value. For example the HP D530 or many IBM computers. In these scenarios you can specify part of the value in the <MODEL> field. For example when the WMI value for a HP D530 is "HP D530 [ABC12345]" then you can specify "HP D530".
Install Hardware based applications (BAD Drivers)
The last part of the driver management puzzle is the BAD Drivers or hardware based applications.
The first thing you need to do is create an application in ConfigMgr that will install the application. I will not provide step by step guidance on this process but it is important that the following two settings are enabled:
1. The program must be set to run "Whether or not a user is logged on"
2. The option "Allow this program to be installed from the Install Software task sequence without being advertised" must be enabled
Once you have created the application you need to add it to our task sequence.
1. Create a folder that will contain all of your "Application Installation" tasks. This folder must be added after the Setup windows and ConfigMgr task. I usually call this folder "Hardware Based Applications".
2. Create a folder within the folder you created in the previous step. This folder should be named after the hardware type (e.g. Toshiba - Tecra M5).
NOTE: When installing hardware based applications I create a folder for each hardware type that contains all of the applications for that hardware type. I then apply the WMI conditions to the folder, NOT the application.
4. Next we need to add a WMI condition to this folder.
5. Select the task Options tab
6. Select the Add condition drop down menu and select Query WMI.
7. Add the following text to the WQL Query field replacing <MODEL> with the WMI value for your hardware type - SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" and click OK
8. Add an "Install Software" task to this folder specifying the application that you have created in the previous step.
9. Repeat this process for all hardware based applications!
So that's how I manage drivers .... simple :)
For more information no driver management please refer to the ConfigMgr online documentation library.
Driver Management (Part 2) - Manageing drivers with MDT 2008 can be found here.
This post was contributed by Ben Hunter a Consultant with Microsoft Services New Zealand.
Comments
Anonymous
January 01, 2003
Comme plusieurs personnes sont en mode de préparation au déploiement de Windows 7, je vous recommandeAnonymous
January 01, 2003
Ben, I've had an issue with installing a video driver for an HP 8510W w/ MDT. For some reason the driver does not want to inject. The driver is an Nvidia v156.31 (sp36726.exe) from HP's website. If I had install the driver it loads just fine. I'd rather not have to add this driver and install as I do the rest of my "bad" drivers. Is there any other way around this using MDT? Thanks, RichAnonymous
January 01, 2003
Part 2 is located here - http://blogs.technet.com/deploymentguys/archive/2008/04/17/driver-management-part-2-mdt-2008.aspxAnonymous
January 01, 2003
Hi Rich, I like to include these patches in the base im age. I just create another application to install them. That way I don't have to worry about installing them for every client that requires them. Thanks, BenAnonymous
January 01, 2003
I am often asked what the best way is to manage drivers with both BDD/MDT and ConfigMgr. With this inAnonymous
January 01, 2003
Hi Rich, Does that file exist in the driver folder? You should also look to see if this driver is in the driver package itself? This sounds like a driver that may have to be installed as an application. Thanks, BenAnonymous
January 01, 2003
Hi CCA, By injected I mean that the drivers are in the driver store. This means they are available when a device is plugged in later. Thanks, BenAnonymous
January 01, 2003
Something very strage just happened. I added the entry to my sysprep.inf and now during Mini-Setup I receive an error "Setup cannot copy the file nvsvc32.exe. Ensure that the location specified is correct, or change it an insert the Nvidia Windows 2000/XP driver library Installation Disk 1 in the drive you specify." It then references to Copy the files from: C:driversdisplaynvb 6.14.11.5631. Any idea on where I can go from here? Thanks man! RichAnonymous
January 01, 2003
The following post recaps on the questions we covered off during last weeks webcast on desktop deployment,Anonymous
January 01, 2003
Ben put together a really nice artice on driver management in MDT and ConfigMgr. File this one away!Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I am working on it now :). So it shouldn't be too long. So much to do so little time :(. BenAnonymous
January 01, 2003
In this case I would recommend installing the Nividia driver using an application. If the installer is an installshield installer, create a custom install file that suppresses the reboot. Record an answer file first by extracting the source package to a folder (mine is extracted to C:NVIDIAWinVista169.25) Then run setup and record an .iss file with all the options required.: C:NVIDIAWinVista169.25setup.exe -r -f1C:NVIDIAWinVista169.25nvidiasilentsetup.iss You can silently install every time thereafter with: C:NVIDIAWinVista169.25setup.exe -s -f1C:NVIDIAWinVista169.25nvidiasilentsetup.iss An .iss file example follows, at the end you should note the BootOption (0 means no reboot): [InstallShield Silent] Version=v7.00 File=Response File [File Transfer] OverwrittenReadOnly=NoToAll [{EFB7D050-CAD2-11D4-B34D-00105A1C23DD}-DlgOrder] Dlg0={EFB7D050-CAD2-11D4-B34D-00105A1C23DD}-SdWelcome-0 Count=2 Dlg1={EFB7D050-CAD2-11D4-B34D-00105A1C23DD}-SdFinishReboot-0 [{EFB7D050-CAD2-11D4-B34D-00105A1C23DD}-SdWelcome-0] Result=1 [{EFB7D050-CAD2-11D4-B34D-00105A1C23DD}-SdFinishReboot-0] Result=6 BootOption=0 Thanks, BenAnonymous
January 01, 2003
Hi Rich, I will cover this in my next post :). I just have to find the time to finish writing it. Thanks, BenAnonymous
January 01, 2003
Hi Greg, I would suggest that you try the method in my previous reply to Rich and see if that works. Thanks, BenAnonymous
January 01, 2003
Hi Christophe, Unfortunately you will have to manually identify the driver that was a duplicate and add the driver to the package manually. Unfortunately this is not the most elegant process :(. Thanks, BenAnonymous
January 01, 2003
Hi Rob, The best method of doing this would be to advertise a taks sequence that applies a driver package containing these drivers. Then advertise this task sequence to the clients. Thanks, BenAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Hi Dustin, A 7B error suggests that you have a mass storage driver issue. Have you tried add mass storage drivers to your image as detailed in the following blog: http://blogs.technet.com/benhunter/archive/2007/07/12/bdd-2007-integrating-mass-storage-drivers-into-your-xp-image.aspx Thanks, BenAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Hi Bzwart, You are correct. If the driver has already been imported then you will need to manually add it to the driver package. This can be a hassle, but at least you only have to do it once for each model type. Thanks BenAnonymous
January 01, 2003
Jarod, You can add new drivers to be included in the WinPE image via the drivers section in the MDT console. Then, in the properties of the deployment point you can configure the creation of the WinPE ISO file to include extra network drivers, video drivers and system drivers. HTH, DanielAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Injecting Apply Driver package in Task Sequence (SCCM SP2) reboots the cilent machine without installing any OS.Anonymous
January 01, 2003
Hi Andrea, Here is the link you are looking for: http://blogs.technet.com/benhunter/archive/2007/06/16/bdd-2007-understanding-bdd-logs.aspx Your issues sounds like it is the uberbug issue but it could also be related to the HAL or Mass storage drivers. Are you using MDT or ConfigMgr for deployment? Thanks, BenAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Hi Patricio, There is no easy answer to this question. It really is completely dependent on your environemtn. I do not no of any physical limits for this process. I would just apply logical limits based on management of the task sequences. Thanks, BenAnonymous
January 01, 2003
Hi Rich, I have seen all sorts of weird issues with drivers. Try adding the following to your sysprep.inf file whe you create your master image: [Unattended] UpdateInstalledDrivers=yes Here is some more info on what it does: http://technet2.microsoft.com/windowsserver/en/library/4dba14f3-76e1-4a9e-b67a-3a93230f63071033.mspx?mfr=true Also your method of updating patches is fine. Thanks, BenAnonymous
January 01, 2003
Hi Jared, The seconnd part of this post that covers Lite Touch is here: http://blogs.technet.com/deploymentguys/archive/2008/04/17/driver-management-part-2-mdt-2008.aspx Determining the OS type at driver injection time cannot be done via WMI as the OS is not loaded yet. You could use the IMAGEBUILD value gathered by MDT to determine the OS type. You would probaly need to include some kind of script in your Task Sequence to translate the values returned into something easier to use. Thanks, BenAnonymous
February 15, 2008
The comment has been removedAnonymous
February 17, 2008
Do you recommend using the "Apply Driver Package" in conjunction with "Auto Apply Drivers" ? I've tried to use it after the "Auto Apply Drivers" Step to install the more "Problematic" Drivers which the previous step didn't recognized (Like Nvidia's 6100 Driver instead of MS's Nvidia 6100 WDDM Driver) but with no luck, The MS Driver allways took over ispite the fact that nvidia's driver were NewerBetterAnonymous
February 18, 2008
Ben, when you say 'injected' as for the apply driver package, do you mean unused drivers are actually statically in the driver store? Or is this only for the pnp scan and once the OS is installed these are not found on the Host? ThanksAnonymous
February 29, 2008
Hi Ben, Looking forward to your post on this process with MDT/BDD! Thanks! RichAnonymous
February 29, 2008
Ben, What is the suggestion for installing Common Windows XP update modules (ex. Q889816, Q909667) or the Universal Audio Arch drivers? This is an element of my task sequence that I need to cleanup a bit before I roll MDT out. I appreciate your feedback. Thanks man! RichAnonymous
March 02, 2008
The comment has been removedAnonymous
March 04, 2008
Hey Ben, Thanks for your response. I wanted to follow-up with you regarding driver management in BDD/MDT. You have a fan of the deployment guys blog that is eager to see the post. Let us know when we can expect any information regarding the post. :) Thanks, RichAnonymous
March 04, 2008
Hi, Thanks for the article.. very well written. I am trying to install a network card driver and am still experiencing issues. From what I can see, it is downloading the drivers from the driver package fine but it doesn't actually install it. When the image comes online, the network card appears as an unknown device. When I go through the process of installing the driver through the wizard, it actually finds the driver in the downloaded location (c:drivers2). Am I doing something wrong here?Anonymous
March 10, 2008
Ben, I'd love to see an article on installing BAD drivers in MDT. In particularly determining silent switches for BAD drivers that you have to add as applications in MDT. I'm building out my Task Sequence in MDT for an HP8510W. I'm finding by the time that I go through and find all the additional drivers that need to be installed (3D Drive Guard, BlueTooth, FingerPrint, DVD, Quick Launch Buttons, etc. - It's very time consuming. Then I have to find the silet installs, test them and add them to Task Sequence. Is there an easier way? I'm using a captured WinXPSP2 image for my deployments. Just a suggestion, I'm sure others out there have this problem. Thanks, RichAnonymous
March 11, 2008
Ben, When are you gonna post Part 2 of the Driver Management? I'm very interested!! ThanksAnonymous
March 19, 2008
MD. BDD part 2 blog entry would be great. Ben, do you expect to have it done any time soon ? thanks in advance.Anonymous
April 17, 2008
The comment has been removedAnonymous
April 28, 2008
When I used MDT 2008 Deployment Operating System sometime new NIC can't loading , because some driver in PE2.0 is older HOW can add new driver or replace old driverAnonymous
April 30, 2008
Hi Ben- problem resolved. Something messed up in the task sequence or typo in the unattend. Re-created all from scratch and no sata drive problem- no driver issues (except the HD audio thing which I can handle) life is good. You guys are a fantastic resource for all of us who don't have a lot of hours and need answers. Tanks a million. ;) andreaAnonymous
May 13, 2008
Great blog post! Is it a good idea to manage all non hardware dependent drivers (scanners, imaging, cameras etc) in a single package (to be included in the driver store for all Vista workstations) and what's the best way to manage driver updates after deployment?Anonymous
May 29, 2008
Ben, Any chance you ahve done this type of blog for litetouch driver injection? I dont cm, and trying to use the driverpath001= in cs.ini to point to specific make/model/architechure wmi calls. any idea how I can get this same process or work for a wmi call of the OS diffecence of Xp pro, vs Vista so i could use the same process ? something like... driverpaths001=\servernameshare%OS type %%architechure%%model% ? what would the %os type % wmi call be ? i can seem to figure that out. thanks JAredAnonymous
June 12, 2008
Hi Ben, is there any actual limits or best practices for how many "Apply driver Packages" that can be put into a Task Sequence? Let's say you need to support 30 (or more) different computer types, then there will be a lot of "Apply driver Packages" for both nice and and bad drivers ? Thanks in advanced! /PatricioAnonymous
October 14, 2008
Well, I sent soemething out yesterday,but thought I'd clarify. I'm trying to boot win pe on a DELL E6400. When I specify the all driver group (which includes all the network drivers including WiFi, win pe comes back and says it can't connect and ipconfig shows only the wireless and gives me a DHCP error. If I disable the wireless than Winpe comes back and says the device has no driver installed- and gives the correct dev id for the nic-I've verified that the driver is there in all driver group. I have the additions to the startnet command file and have through my whole desktop imaging. I've had no problems with any other machine with nic drivers and win pe. I've tried adding a separate group and just telling Win PE to use that group. I've deleted the wireless driver from all the groups in case there's a problem. No other driver has those device ID's from that driver in it. Not sure where to go from here. Any suggestions? AndreaAnonymous
October 17, 2008
My fault- used the XP driver that shipped with the machine- Forgot that I needed the vista driver for Win PE- All happy again. :) AndreaAnonymous
December 10, 2008
The comment has been removedAnonymous
December 22, 2008
Listen. I'm trying to apply an image to a Compaq 6730s and not having much luck. It seems to start working and then the next time I check on it, i got a BSOD error ending in 7B it goes by so fast, but looks like 0x0000007B. I'm thinking its a driver issue, however I'm pretty sure that I have downloaded all the drivers from the HP site. What am i missing?Anonymous
July 16, 2009
Thanks for this post. Do you have a similar walkthrough for MDT 2010 Beta 2? I'm trying to do hardware-specific driver injection for a Windows 7 deployment. Thanks!Anonymous
December 02, 2009
The comment has been removedAnonymous
March 11, 2010
Hi. Thanks for the great document you have posted. it has helped me a lot. I have a question about the BAD drivers. Could you give me an explanation of how i can accomplish this part? "The first thing you need to do is create an application in ConfigMgr that will install the application" I am assuming that means I need to create a package for each of the BAD drivers, correct me if I am wrong. Now, most of the Bad drivers get install with an .exe file. ( SORRY FOR THE CAPS, MY KEYBOARD STARTED WORKING WEIRD) AS FAR AS I KNOW A PACKAGE CAN BE CREATED FROM A .MSI BUT NOT FROM A .EXE FILE. AM I WRONG? THANKS.Anonymous
March 15, 2010
Hi Ben, Currently working on a task sequence to deploy XP SP3 on about 20 different HP models. When we try and import the drivers (GOOD drivers) for a 6930p SCCM informs us that this driver has already been imported (i.e. for a 2530p) and does not allow the driver to be duplicated. Can you advise on the best way to create driver packages where the drivers may already exist in SCCM.Anonymous
April 22, 2010
Christophe, We solve this by putting a text-file in each of the driver directories before importing them in SCCM. It's a textfile with the name "HP 6930p.txt" and the content is "HP 6930p". This way SCCM will identify the imported driver as a new driver since the directory differs from the 2530p driver directory, where we ofc have a file named "HP 2530p.txt".Anonymous
May 04, 2010
I was curious about using SCCM as a tool for mass printer driver deployment?Anonymous
May 07, 2010
So much for there being a PART 2Anonymous
October 08, 2010
The comment has been removedAnonymous
December 13, 2011
Thank you for this excellent post. Helping my new job role. thanks..Anonymous
October 05, 2012
Its 2012 and this post is still relevent. Thanks man this saved me big time, as I really needed to get up to speed with this task ahead of a pc deployementAnonymous
April 09, 2013
Hi, obviously I'm really late to this, but this post just helped me really a lot in our SCCM 2012 infrastructure. Thank you very much!Anonymous
July 26, 2013
Thank you so much for this! I've been trying to figure this out in Deployment Workbench 2012 (MDT 2012) and did not have this setup previously so had nothing to go on. This helped me and pointed me down the right path. Much appreciated.Anonymous
January 23, 2014
Dear Ben, thanks for this is really interesting! I do have a question maybe you can help me, I'm looking for a tool that let me manage and deploy drivers in a centrailzed way. That means that I can deploy drivers through a server to differents clients in a company, being these drivers for Linux or Windows or both, Active Directory integration would be nice but it is not a must. Do you know of a tool that can manage this type or requirements? Free or paid it is the same. I'll leave my email just in case stormharvester@gmail.com thanks in advance!!