Roger Zander had posted another nifty way of dealing with mass storage drivers here, basically created a task sequence section that detects the mass storage device and injects the driver. This is an alternative method to injecting the mass storage driver from within a model specific driver package. For example having a driver package for a Lenovo T61p that includes the Intel Mass storage driver and selecting it, similar to the screenshot below:
Here is the link to Roger’s post:
What i want to do with this post is show you how to take that information above and import it into your existing OSD TS.
1) Download and extract out the task sequence so that we have the file we will need to import.
2) Next we need to prepare ourselves for the task sequence, so lets make sure we have a Mass Storage Driver Package created and the appropriate drivers in that package.
3) Next lets import the task sequence that we downloaded previously
Browse to and import the “massstoragedrivers.xml”
You’ll first get an error message about an invalid boot image:
Then an error message about invalid packages:
Click on edit on this screen, and then we can correct the task sequence to point to the correct Mass Storage Driver Package for our site.
Once it loads you’ll have a nice TS with a bunch of errors:
Credit due where credit is due! 🙂
So first lets fix the VMware SCSI Controller as an example:
We first need to browse to our Mass Storage Driver Package:
Then we need to modify the values to fit the entry we are editing:
If for some reason you don’t have a signed driver, you will need to check this box:
You can see if you have a signed driver by looking at the driver properties in the console:
Now that we’ve modified the VMware SCSI Controller entry, you can see that we have one green check box now:
So we need to go through and modify the rest of them so that these TS entries are valid for our environment, I disabled a few that I don’t want to use right now, also the disabled ones are ones that are not in the standard Intel RAID/AHCI drivers.
So now we have a TS that contains valid entries for our environment, so i need to incorporate this into an existing TS of mine.
4) Integrating the Mass Storage task sequence steps in an existing OSD task sequence.
NOTE: You can also move the Mass Storage steps into your task sequence by using copy/paste, in order to do this, you need to have both task sequences’s open at the same time. This is easier than editing the XML.
Here is a basic Windows XP TS that i’ve added a “Driver Management” category to. (No MDT integration, even though i normally use MDT)
The Driver Management category is good because it gives me a place in the TS that i can find when editing it to add my new content. That’s typically how i prefer to manage my TS’s.
First lets export our TS so we can work with it. We need to export our Mass Storage Driver TS and our OSD TS.
Next lets open up our OSD TS with notepad ++ and find the Driver Management section we created:
Also, open up the Mass Storage TS.
Now we need to copy the “steps” from the Mass Storage TS to our OSD TS.
You basically want what i’ve detailed in this screen shot (it’s a collapsed view). This is in the Mass Storage task sequence we exported.
This will give us a new group and the relevant steps. Basically the information we want to copy over into our existing task sequence.
Lets move this information over to our OSD ts, and we want to place it right below the line i’ve detailed below.
This will create a new group and steps underneath it.
After we paste this info (collasped view again) you will see that i have a new group called “MassStorage Drivers” underneath my “Driver Management” group:
Now lets save the TS, exit notepadd ++, and then we need to import the task sequence back into ConfigMgr.
Next we look at our new OSD TS and see the new “Mass Storage” steps under our “Driver Management” section in our TS.
There we go, we now have the new Mass Storage detection section in our Windows XP task sequence.
5) Time to test
6) Test again 🙂
This post should help you be able to configure the information Roger/Richard put together and integrate it into your existing task sequence without too much trouble. I hope this helps, and remember to test 🙂
I caught this posting here today and thought it was good information. This is just yet another way you can handle mass storage drivers with Windows XP and SCCM.
One method of integrating drivers or mass storage drivers into Windows PE involves using the winpeoem.sif file which is located in the \system32 directory. This will not work with every driver, however, i would recommend trying this method first, since it’s one of the easiest methods to do. If this method doesn’t work, then you may need to modify the txtsetup.sif file.
Here is a picture of the default winpeoem.sif file:
First we will want to create the necessary folder structure for the driver. In this example lets use the VMware SCSI driver.
I’m going to store my drivers under \system32\drivers\VMware_SCSI
So I need to create that folder and then copy my driver files into that folder:
No I also need to look at the txtsetup.oem and see how they want the folder structured.
If you open the txtsetup.oem for the driver you need, you will want to look at the [Disks] section and see what folder it’s expecting to find the driver in.
In this case, denoted by the “\” at the end, it’s expecting all the driver files in the root of the folder. So in this case our “Vmware_SCSI” folder will work just fine.
So we have our files in the correct place, so now we need to somehow let WinPE know that there are some new drivers it can use. We need to modify the winpeoem.sif file.
In the bottom of the file you will find a [OemDriverParams] section.
We need to uncomment this section and add new directory here. The default for the “OemDriverRoot” is “” which means \system32. To keep it cleaner, i created my directory under \system32\drivers, so i need to modify that value to tell it that the “root” directory is now \system32\drivers instead of \system32.
Next we need to modify OemDriverDirs to identify the VMware_SCSI directory we created.
Now, if all goes well, we should have support for the driver we have just integrated, in this case the VMware SCSI driver.
Also here is the explanation of the sections provided by the winpe.chm
The below post is a combination of information i have learned as well as information i have found on the internet. I posted some “credits” at the bottom to some sources i pulled a few things from.
Also please note that is method is not supported by Microsoft as detailed here http://support.microsoft.com/kb/288344/, as per usual, use at your own risk, although this is a fairly common method.
Additionally, keep in mind that MDT 2008 will integrated mass storage drivers for you when you are only using the workbench, if you are using the integration with SMS 2003, then MDT 2008 will not integrated mass storage drivers for you and a solution like below is needed.
When integrating Mass Storage drivers like the Intel driver into either WinPE or your image I’ve always known the steps i needed to take, but i never really understood where that information was coming from. When i first started with ICH5 (i think), I already had the modifications, so as new versions of the intel driver came out, i simple added the new strings to my existing information to cover the PCI ID’s. So if i ever had a new driver that i needed to start from scratch with, how would i get the information i needed to modify txtsetup.sif?
I would generally recommend that you try using the winpeoem.sif method first, since it a much easier method. If that does not work, then you most likely will need to use this method that involves modifying the txtsetup.sif file.
I will use the Intel driver to demonstrate
Gathering the needed information from the txtsetup.oem file
1) The PCI ID String
2) The INF file name
3) The SYS file name
4) The Device driver description quoted (although you can change this to whatever you want, i would recommend you use something descriptive)
Copying the necessary files to correct locations
1) Copy INF files to “WinPE Source”\i386\inf
Modifying the txtsetup.sif
1) Open the file “WinPE Source”\i386\txtsetup.sif
2) Locate the section named [HardwareIdsDatabase]
3) Add each PCI ID like this…
[PCI ID String] = [SYS File name (Without .sys)]
4) Locate the section named [SCSI.Load] in the txtsetup.sif
5) Add each INF File name without .inf like this…
[SYS File name (Without .sys)] = [SYS File name],4
6) Locate the section named [SCSI] in the txtsetup.sif
7) Add each INF File name without .inf like this…
[SYS File name (Without .sys)] = [Device driver description quoted]
“The description can be anything you want”
Now the documentation I have for the Intel driver also shows the following section needs to be added to [SourceDisksFiles] section in txtsetup.sif
This is the section i have always struggled with the most as far as figuring out where the heck all the commas and numbers come from. I will post what i have been able to find for information below.
First a nice picture that details the information, followed by a much more in depth explanation.
The following line shows the syntax of each line in the [SourceDisksFiles] section:
Extra fields specified by commas (,) are Windows NT—specific.
diskid is used when a floppy disk installation is used. (Or multiple CDs?)
subdir is the directory to which files are copied.
Codes defined in the [WinntDirectories] section of the TXTSETUP.SIF file are used to identify the destination directory.
Codes in the [Files] Section of TXTSETUP.SIF for File Copy
Status Code – Copy Action
0 – Always copies the file
1 – Copies the file only if it exists in the installation directory
2 – Does not copy the file if it exists in the installation directory
3 – Does not copy the file
newinstallcode is a single digit that is used if this is a fresh installation. It specifies whether the file is copied during the text-mode portion. The same codes are used as for upgrading Windows 2000 and are described in Table 4.3. The newinstallcode is optional; if it is not included, the file is not copied (code = 3).
newfilename is the name to which the file is renamed if it is copied. As an example, consider this line from the [SourceDisksFiles] section.
autochk.e XE = 1,,,,,,_x,2,0,0
The file AUTOCHK.EXE in this line is on the CD or the disk with diskid d2 defined in the [Media] section. The file also is on Setup Disk 2 (_2), also defined in the [Media] section. The file is installed in directory 2, which is defined in the [WinntDirectories] section. If you look up the [WinntDirectories] section, directory 2 is the System32 subdirectory in the Windows 2000 root directory. The upgrade code and new installation codes are 0, which means that this file always must be copied to the installation directory, whether this is an upgrade from an earlier version of Windows 2000 or a fresh installation.
Windows® 2000 Server Professional Reference
By Karanjit S. Siyan Ph.D.
Publisher : New Riders Publishing
Pub Date : July 10, 2000
ISBN : 0-7357-0952-1
Pages : 1848
MDT 2008 and SMS 2003 – Automatically integrating Mass Storage Drivers support into your Windows PE source for SMS 2003 OSD
Although MDT will integrate both network and mass storage drivers for your Lab environment, it does not automatically integrated mass storage drivers for your SMS 2003 OSD Deployment Point/WinPE Boot Source. So when you import that boot source into SMS 2003 OSD, you will not have mass storage support, unless you add it prior to the import.
So looking at your Lab deployment point, you can see it will nicely integrate mass storage drivers for you:
However, if you look at your SMS 2003 deployment point in the workbench, you will not see that option available to you:
So how do we address that? You could manually integrate mass storage support into your PE source, using the method described here. However, the downside is that every time you do an “update” to the deployment point, it will rebuild that boot source and you will lose your mass storage integration that you manually added. Which is fine as long as you remember that before you import the new updated WinPE source into SMS 2003.
Taking advantaged of the “Extrafiles” feature in MDT, we can do a few customizations to ensure that when we build or update our deployment point in the workbench, that our boot source always contains the mass storage support we want.
First, we will want to create a folder to house the files, i typically just name it “Extrafiles” and put it in the Distribution folder.
You will want to build out the structure i have pictured below:
For the sake of it, i would recommend you throw trace32.exe in the \system32 folder so that you can view log files in a friendly view from within WinPE, you can also add anything else you might want to access from within WinPE.
I will use the Intel mass storage driver as an example below since that is what we use and it’s very common for many vendors to require this driver.
So in the \INF folder we will want to put the following files:
In the \DRIVERS folder you will want to put the other files from the driver package:
in \I386 you will want to put your modified txtsetup.sif that contains the necessary information for the Intel mass storage controllers, or whatever controller you are adding support for. If you are using the Intel one, make sure you have add the appropriate lines as per the document linked again here.
Now what we have our necessary folder structure, we will want to make sure we add the extrafiles directory to our SMS 2003 deployment point in the workbench:
Now when you use “update” on the deployment point, the necessary files required for mass storage support will be copied into your WinPE boot source every time.
One less thing to take care of manually 🙂
I hope this helps, please let me know if you have any questions.
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:
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…
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.
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.
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:
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
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.
First things first, want to make sure i have this information posted since this is one of the most common things I see on the forums.
In my environment we have mostly HP and Lenovo laptops, which all use Intel SATA, so it’s fairly easy for us. Basically I took HP’s sata guide and modified it to encorporate all the steps needed for integration into SMS. Also see these threads on MyITforum: SATA integration –
In my environment we have mostly HP and Lenovo laptops, which all use Intel SATA, so it’s fairly easy for us.
Basically I took HP’s sata guide and modified it to encorporate all the steps needed for integration into SMS.
Also see these threads on MyITforum:
SATA integration –