Managing Drivers with MDT 2008 and SMS 2003
I’ve seen a lot of various posts discussing drivers and the best way to manage them. SCCM has some great built-in features for dealing with drivers, but not all of us have the ability to upgrade to SCCM just quite yet. So, what is the best way to handle drivers if you have MDT 2008 and SMS 2003? Well hopefully I can help explain the various options and then you can choose what works best for your environment. This post will address MDT 2008, SMS 2003, and Windows XP and I’m assuming you have some knowledge of working with the workbench and SMS OSD.
When I talk about drivers, i like to break it down into a few categories, well fundamentally, 2 categories, 99.9% of your drivers will fit into one of these two categories.
1) Mass Storage Drivers
2) Everything else
Mass Storage Drivers
Windows Vista – I won’t touch on this, we don’t have this in our environment currently so my knowledge is limited
Windows XP – Without getting into great deal, the best way to deal with mass storage drivers is simply that they need to be included in your image before you capture it and correctly identified in your sysprep.inf file
See this post for more information:
http://myitforum.com/cs2/blogs/cnackers/archive/2009/01/22/mass-storage-controllers.aspx
Everything Else
Most of your drivers can be extracted out, and I would recommend cleaning up the unnecessary files to help keep the sizes down. If you have .exe driver that doesn’t extract out, i have used Driver Genius Professional in the past to create the necessary files that I needed. It’s a very cool little utility. A good example of this is the Microsoft UAA driver bus you need for most of the Soundmax Audio. Until that UAA bus is installed you cannot install the audio drivers. This is also a good example of why i don’t recommend PNP detection for all of your drivers.
Ok great, that now we’ve covered the driver basics, what about SMS and MDT, what do I actually need to do in order to get this stuff working? Well…
SMS 2003
Quick Summary: You only need to make sure that your WinPE source is up to par with the correct mass storage drivers and NIC drivers for your environment.
I’ll talk about SMS first because quite frankly you don’t really have to do a lot in regards to driver management. You really only need to be concerned with making sure the your WinPE source is up to par and has the appropriate mass storage and NIC drivers built into it. Unless you get a new mass storage driver or a new NIC, you don’t need to update your PE source in SMS very often. I would also recommend that you are using WinPE 2005 from a Server 2003 SP1 source, so that you can take advantage of RAMdisk for booting from RIS and for some other things you can use RAMdisk for. I use the source created from the MDT workbench for my WinPE source files. The one thing to note is that you need to re-add your mass storage driver support to the WinPE source everytime you do a full update in the workbench and don’t update just the files. A full update recreates the boot source, and for whatever reason it’s been my experience that MDT will not integrate the SATA drivers into the boot source for you, i’m sure for the same reasons it won’t integrate mass storage drivers into Windows XP for you, assuming it’s just a limitation. So just keep that in mind, if you suddenly are getting a blue screen, or WinPE can’t see your SATA drive.
When you pull in a new PE source, SMS will create a new osdwinpe.wim under your \sms\osd directory. When you do a “update operating system files” on your SMS OSD package, it will pull this new .wim file into your OSD package source folder. You will also see previous versions of your osdwinpe.wim file under the sms\osd folder, so if you suddenly notice a drop in the size, you might want to double check your work.
MDT 2008
Here is the meat and bones of driver management with SMS. Most of your work will be done through the work bench in some way shape or form. You can manage drivers with 2 core methods or a combination of them both. The first method is to utilize PNP detection and have MDT pull the drivers and copy them down during the OSD process for you. This works 95% of the time i would say and therefore i don’t typically recommend this method, but it is useful for some scenarios. The other method is to use a method to identify the model and set the driverpath variable for that model and then MDT will copy down everything in that driver path. The one advantage to PNP is that if you have a new model or unknown model, you have a good chance of getting some or all of the drivers to come down for that new model. The one disadvantage to using the driverpaths method, is that if you have a unknown model, you won’t pull anything down for that model.
I also want to touch on a PNP detection issue that i’m not fond of. We utilize Solidworks which is a high-end CAD application in our environment. We run a specific driver version that is certified by Nvidia/ATI to work with a particular version of Solidworks. Most graphics companies utilize a unified driver architecture which is a problem when you want to have certain driver version installed. What typically happens is that when PNP runs, it grabs the “best” “newest” driver, so if you have a particular version of the driver you want (i.e. certified) but your newest laptop needs the most recent unified driver, you have a problem. That “best” driver will now get installed on your workstation that runs CAD, because it’s the “best” driver found during PNP. Now you can modify the INF’s and all sorts of fun messy stuff to get around that, but this is another reason i prefer using what i call the “driver direction” method since I then only have available the driver i want available.
ResourceRoot Variable
Either method requires the use of the RESOUREROOT variable. This variables needs to be specified in your customsettings.ini file and in your boostrap.ini for it to work correctly. Either method always requires the use of a drivers.xml file, although how they use that file is vastly different.
You will need to point the RESOURCEROOT to either your custom share or the deployment point you want to use in both cs.ini and boostrap.ini
This is the line i use in both files:
ResourceRoot=\\%SMSDP%\DRIVERSMDT$\
DRIVERSMDT$ is my share that contains my drivers for OSD.
In customsettings.ini you would typically put this under the [Default] section, unless you are defining it somewhere else based upon locations or something of your choosing. Note that i’m taking advantage of the %SMSDP% variable, i will normally use as many of the known variables as i can because it makes your task sequence commands and anything else you set much easier to work with.
So if you are using PNP then your need to point the RESOURCEROOT variable to the deployment point you want to use (more info below) and if you are using the other method then you need to point the RESOURCEROOT variable to your share you want to use.
MDT 2008 – PNP
Disclaimer: It’s been awhile since I’ve managed drivers through this method, so it’s possible i have a few things mixed up below, so just be aware that some of what i detail below might not work exactly as i’m describing it, and if so, forgive me and shoot me an email and i’ll correct it. I’m doing my best from memory so that you have the information available to you.
If you are going to use PNP then I would recommend creating a “NETWORK” Deployment Point in the workbench, this will allow you greater control over the drivers you are dealing with. When you create this type of deployment point, then you can make use of driver groups to control what drivers are on that deployment point and thus which drivers are listed in the drivers.xml.
PNP relies upon the drivers you have imported in to the workbench, so anything have listed under “out of box drivers” could be fair game depending on how you configure it. Again this is why i recommend using a network deployment point and creating driver groups when you import drivers. Always assign drivers you are importing to at least one driver group.
Here is an example screenshot of how you can use driver groups to control the drivers in your network deployment point. You can pick and choose the driver groups you want to use and then you will have some control over what drivers PNP is scanning. Also that network deployment point basically becomes a mirror of your Distribution share except you have some control over what files are going there. There is more data copied to that share than you will need for driver integration, but if you were using the Workbench for builds, then you would need the extra info. The only files in the network deployment point that are of interest for what we are talking about are your out of box drivers and the drivers.xml under the \control folder.
So, now that you’ve specified your RESOUREROOT path in both customsettings.ini and boostrap.ini and you’ve created your NETWORK deployment point or whatever you have decided to use, and assuming you have imported the drivers you want to work with, you should be ready to rock. I’m also assuming you’ve made changes to your files and you have updated your deployment point, then used the “update operating system files” action in SMS to pull the files into your OSD packages source, and then updated your Distribution Point(s) in SMS. Once that is all done, you can being testing PNP driver management.
So what will happen is that when the Task Sequence runs, it will pick up on the RESOURCEROOT path and scan the drivers.xml, and then when the “ZTIDrivers” process runs, it will run PNP and copy down all the drivers it finds that match PNP detection to your \Drivers path on the machine being imaged. This is based upon the data contained within the drivers.xml file, which when you are using this method is every driver you have told it to have in the deployment point or workbench. Then it will update sysprep.inf with the new drivers paths, and when your machine images, it will have the drivers found during PNP detection available to it.
Works great as long as the devices are available and don’t have dependencies upon another device being installed. Also works great for unknown machines since it can use whatever you have available, which when working with the same vendor, typically you have alot of the same hardware on various models. However if your new machine has a new NIC, when then you won’t get this far anyways :)
MDT 2008 – Driver “Direction” Method
I’ll call this the direction method and you can do it 2 different ways, one which is preferable i think, but either way you are basically saying, hey look “here” for your drivers! I’ll show you the 2 ways to do this type of driver management, but neither will work without having a drivers.xml in place. Typically you are going to be using a share of some sort in this, i have a folder on my SMS server called \DriversMDT, i then have this configured as package in SMS called “MDT Driver Share”. I prefer to use the Share Distribution folder for data access so i know what the share will be called, otherwise you will have to set your RESOURCEROOT to the \SMSPKGX$\XXXXXXXX\ value, which just seems like you are asking for a typo/mistake. So i prefer this method so you can control the end result and still take use of SMS DP’s for your drivers, so that when you image a machine in another state, it’s not pulling drivers from your primary server.
In the root of this “source” you will want to create a blank XML document labeled “drivers.xml” without this file the driver detection process will halt and you’ll end up with a machine with no drivers. I don’t know why it’s like that, but that’s just the way it is from what I have gathered. The process will run, find the blank file and then continue on to do what what we want. You still see PNP detection in your bdd.log, but that’s fine, there is nothing to detect and no drivers for it to pull down, since drivers.xml is blank.
This method takes advantage of the “driverpaths” variable, this can be set in customsettings.ini, but i typically do it through the task sequence. I like to create a “Driver Management” group in the Preinstall phase, just before the “Inject Drivers” action.
One of the ways to do this driver management method is to simply create a custom task that sets a TS variable.
Task Sequence Variable: DriverPaths1
Value: \\%SMSDP%\DRIVERSMDT$\%Model%
This will do a model query and then look in the DRIVERSMDT$ share for that model. So, that’s great, but here’s the problem i have with this method. HP doesn’t do a good job with their models :) Because “HP Compaq 6910p (GM120UT#ABA)” and “HP Compaq 6910p (RM231UT#ABA)” are 2 different models, thus you need to have a folder for each model variation, or any possible %model% value that could be returned. So you end up with a nasty folder looking something like this:
So, that’s great, but i like neat and tidy. Like this:
So, how do you get it to look that the above? Well this is method 2. This is why i use a the “Driver Management” group in my TS, to keep it nice and clean. For every model you have, you will need to create a TS step, what will happen is that it will run through all the steps and it will populate your Driverpaths variable when it finds the correct model.
So in this case, you still need to define the TS variable as “DriverPaths1” and then for the value you would put “\\%SMSDP%\driversmdt$\HP NW8240” I’m using the NW8240 as an example. You want to define the folder here, so you are basically saying, i want you to go here for this model and this will be the driverpath you need. What makes this work is a WMI query on the backend. You need to set your queries to “continue on error” so that when the query doesn’t return a result it process the next and so on. Here is the query for the NW8240:
So you can see i’m using a “LIKE” statement so that i can use “%” and thus get rid of the nasty part #’s on the end of the models. This allows me to have a single folder for all variables of that model. Within that folder, i have the drivers needed for that model. Which i think is about 75mb for this model. So when this process runs, i’m only pulling down the 75mb of drivers i need for this exact model.
So now when you run the OSD process, the Task Sequence processes the queries, sets the driverspath and then copies down all the drivers for that model to the \drivers path locally. Then updates sysprep and continues on.
Thus you have dynamic driver management that allows you to control what drivers come down for each model, and you can control the video driver version (my certified driver issue with PNP) and you are only grabbing the drivers you need for the model you are imaging. Also, it’s very easy to update the drivers for a new model, since everything is outside of the image.
That’s it! Let me know if you have any questions! I hope this helps some people out and clarifies a few things.
-Chris