Recently, one of my students ask about driver management in his office environment and i find this article from the net so i re-post to here:
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.
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.
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.
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.