• Home  / 
  • The Drivers Saga Continues… This time we battle SCCM 2007…

The Drivers Saga Continues… This time we battle SCCM 2007…

By arwidmark / December 3, 2008

In part 1, They call me a control freak – a drivers Tale, I explained driver handling in MDT Lite Touch. Now I continue with best practices for SCCM 2007 driver handling, control freak style (meaning, 100 percent working style)…

Background info…
In SCCM 2007 you group imported drivers into packages, and you can have two types of packages. Auto Apply Drivers and Apply Driver Packages. The Auto Apply Drivers package relies on PNPID detection, does not work with standalone media and does not support mass storage drivers for legacy operating system (Windows XP and Windows Server 2003). The Apply Driver Package, does not rely on PNPID detection and always works, no matter what… If you want 100 percent success, you should use the Apply Driver Package type. Period.

If you import the drivers, SCCM keeps track of each driver so if try to import the same driver again, it refuses to do so… So if you want to import duplicate drivers, you are in trouble…

The workaround is easy, just add a unique textfile to each folder (I prefer to use a textfile named OS – Platform – Model.txt). This will tell SCCM – Hey, I’m a unique driver – and SCCM will happily import it.

Note: In ConfigMgr 2007 you don’t have to import drivers in order to create Apply Driver Packages, however this is not supported by Microsoft and will prevent you from migrating those driver packages to ConfigMgr 2012. For more info on ConfigMgr 2012 and drivers, check this blog post: The Drivers Saga continues – How to Master Drivers in ConfigMgr 2012

Step-by-Step Procedure

In this guide we will create the structure, and I will use a 32-bit Vista deployment to a HP Compaq 8510w laptop as an example. There are two options, wither create the packages without importing the drivers, or import the drivers using the *.txt file method described earlier.

Common

  1. Create the following driver directory structure and share the D:\Drivers folder as Drivers$
     
    D:\Drivers\SRV2003X86
    D:\Drivers\SRV2003X64
    D:\Drivers\SRV2008X86
    D:\Drivers\SRV2008X64
    D:\Drivers\VISTAX86
    D:\Drivers\VISTAX64
    D:\Drivers\XPX86
    D:\Drivers\XPX64
    D:\Drivers\WINPEX86
    D:\Drivers\WINPEX64
     
  2. For this example (32-bit Vista OS, HP Compaq 8510w) we Copy the Vista x86 drivers for that model to the above folder (create subfolders like below, etc.
     
    D:\Drivers\VISTAX86\HP Compaq 8510w\Nic
    D:\Drivers\VISTAX86\HP Compaq 8510w\Audio
    D:\Drivers\VISTAX86\HP Compaq 8510w\Video 
     

Option 1 – Create Apply Driver Packages without importing the drivers…

Note 1: Again, in ConfigMgr 2007 you don’t have to import drivers in order to create Apply Driver Packages, however this is not supported by Microsoft and will prevent you from migrating those driver packages to ConfigMgr 2012. For more info on ConfigMgr 2012 and drivers, check this blog post: The Drivers Saga continues – How to Master Drivers in ConfigMgr 2012

Note 2: If you are adding storage drivers for legacy operating systems you need to import those drivers in order to be able to select them when adding the apply driver package containing the storage driver in the task sequencer.

  1. In the Driver Packages node, create a Driver folder structure in SCCM, example Driver Packages \ VISTAX86. 
     
    Se below. 

  2. Create a Driver Package named HP Compaq 8510w, as Source Path, set \\Server\Drivers$\VISTAX86\HP Compaq 8510w.

    Se below…


     

  3. No it is time to update the Task Sequencer, edit the Vista X86 task Sequence.
     
  4. In the Post Install node, disable the Auto Apply Drivers Action. After the disabled Auto Apply Drivers action, and before the Setup windows and ConfigMgr action, create a group named Apply Driver Packages.
     
  5. In the Apply Driver Packages node, add an Apply Driver Package with the following settings

    Name: HP Compaq 8510w
    Driver Package:  VISTAX86 \ HP Compaq 8510w.

    Se below image.
     

     

  6. Add a WMI condition to this action with the following settings:
    Query WMI: SELECT * FROM Win32_ComputerSystem WHERE Model LIKE “%HP Compaq 8510w%” .
     
    Se below image.
     
     
     

Option 2 – Create Apply Driver Packages and import the drivers

  1. In each unique above folder, create an empty text-file named: _VISTA X86 – HP Compaq 8510w.txt

    So now the D:\Drivers\VISTAX86\HP Compaq 8510w\Nic, the D:\Drivers\VISTAX86\HP Compaq 8510w\Audio and the D:\Drivers\VISTAX86\HP Compaq 8510w\Video folder all contains the file _VISTA X86 – HP Compaq 8510w.txt file.

    This file will make the folder unique to SCCM, and will allow you to import the same a driver twice to the rpository, but into a separate folder in the UI
     

  2. Next step we need to create a Driver folder structure in SCCM, example Drivers \ VISTAX86 \ HP Compaq 8510w, 
     
    se below…
     

         
  3. After the Drivers node structure is done, we do exactly the same thing for the Driver Packages structure. The difference is we only create the VISTAX86 folder, and then we create a Driver Package named HP Compaq 8510w. 
     
  4. Then we go back to the Drivers structure, select the VISTAX86 \ HP Compaq 8510w folder, and import the HP Copaq 8510w drivers (selecting the HP Compaq 8510w driver package during the wizard). 
     
  5. No it is time to update the Task Sequencer, edit the Vista X86 task Sequence.
     
  6. In the Post Install node, disable the Auto Apply Drivers Action. After the disabled Auto Apply Drivers action, and before the Setup windows and ConfigMgr action, create a group named Apply Driver Packages.
     
  7. In the Apply Driver Packages node, add an Apply Driver Package with the following settings

    Name: HP Compaq 8510w
    Driver Package:  VISTAX86 \ HP Compaq 8510w.

    Se below image.
     

     

  8. Add a WMI condition to this action with the following settings:
    Query WMI: SELECT * FROM Win32_ComputerSystem WHERE Model LIKE “%HP Compaq 8510w%” .
     
    Se below image.
     
     

 WinPE Drivers

  1. As a final not, let’s think about WinPE drivers… If you look carefully on the first image, you will se a WINPEX86 and a WINPEX64 drivers folder. Yes exaclty, of course we will have our own folder for WinPE drivers, using the same technique we have learned…
     
  2. In the D:\Drivers\WINPEX86 and D:\Drivers\WINPEX64, folders add your WinPE drivers to that structure. Also add a unique text file to each subfolder, like _WINPEX86.txt
     
  3. When importing the WInPE drivers to each folder, don’t add them to any group, because we will instead add them to the correct boot image. But, a tip, rename the drivers after importing them… for example, rename Intel Pro 1000 MT to WINPEX86 – Intel Pro 1000 MT… The reason for doing this is when we browser for drivers to our boot images, SCCM (for some odd reason) does not honour the folder structure, and if we named the drivers WINPE-something, they will be easy to find. Of course, if you are using option 1, using drivers without importing them, you don’t need to rename them…

    Tip!. If you get tired of the SCCM Console crashing everytime you rename a driver (or in fact renaming most things when running the console on a 64.bit server)… Hit Apply before you hit OK… :It really helps  🙂

Additional reading:

In the “A Drivers Saga – The Control Freak meets The Dynamic Developer” session at MMS 2010 in Las Vegas, me and Michael Niehaus presented different methods of managing drivers with MDT 2010 and ConfigMgr 2007. I focused on MDT 2010 Lite Touch, and Michael Niehaus did the ConfigMgr part. On top of that Michael started blogging about his part of the session… so now I have to do my part 🙂

Michael’s blogs on ConfigMgr Driver Management can be found here:

Part 1:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx

Part 2:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-2.aspx

Part 3:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-3.aspx

/ Johan

About the author

arwidmark

petedoc - December 4, 2008

Nice article, it will really help us here. Can you elaborate on how the txt file works? Does it need to be in the same folder with the .inf for the driver?

Johan M - December 9, 2008

Thanks Johan!
But since I am a student of yours I feel free to add:

I create the drivers structure but do not import most of the drivers at all. Just change the source path for the drivers package to point out the files. That works!

Use MDT workbench to get a nice file-structure for the drivers by importing them in MDT and to copy the resulting out-of-box-drivers catalogs.

The only drivers to import to sccm are NICs and masstorage needed for winpe.
For XP/2003 ,create a masstorage package and point out the package and driver in the sccm-TS.

Also, WMI-scripting is nice but the TS takes to long time to process having many models. Using “Model – equals” is faster.

Sebastian Kim Morsony - December 9, 2008

Hi Johan

Thanks for the tip about having a unique file in each driver folder. This really solves a big problem with sccm.

You have a few steps, that doesn’t work well for me.

Quote.
then we create a Driver Package named HP Compaq 8510w.
Quote

I’ve found, that if I don’t name the driver package with either XPX86 or VISTAX86 I will end up having a problem later on when adding drivers and having to select the driverpackage to add the drivers to, since there will be multiple driver packages with the same name. That’s why I add the OS in the name.

You do not mention what folder path to use for the driver packages. Figured out, that I should create a shared folder structure equal to the drivers folder, but for the driverpackages. I share this folder as Driverpackages$

Thanks for helping me out. :o)

arwidmark - December 10, 2008

Thanks for the feedback, updated the article into two tracks…. one when not importing the drivers at all, and one when importing the drivers… as for the naming, SCCM will honor the folder structure so it doesnt really matter what you name the driver package.

Sebastian Kim Morsony - December 10, 2008

Hi Johan.

I’ve just tested creating a driverpackage, that point directly to my drivers folder, without importing the drivers into sccm. Works perfectly. :o)
I will not import drivers into sccm in the future. Except Winpe drivers.

Thanks
Sebastian

Mark Thomas - December 16, 2008

Hi Johan,

Great article… it will save me loads of time in managing driver packages. :-).

Can you provide some more details about how you manage the WinPE drivers?

What folder structure do you use under the WinPEX86 and WinPEX64 folders (if any)… would you recommend putting all drivers into the root of this folder, create a folder per device type (Sata, Nic) or by device (Dell D630Nic). I guess this is relevant to both the driver source files and the UI in the console.

By using the same approach as the driver packages (with a txt file and split by model) could lead to multiple copies of the same driver being added to the boot image. Is this OK or is it best to avoid this?

If you could provide some clarification it would be most appreciated.

Thanks,

Mark.

arwidmark - January 7, 2009

Sorry for the delayed answer… for most customers I don’t use any folder structure for WinPE drivers in the SCCM Console UI… the reason is that the boot image driver selection does not use it anyway. However, I do use a folder structure for my WinPE source drivers folder, and after import, I rename the drivers to WinPE x86 – Driver name… I keep WinPE drivers separate from Windows drivers

Mr. Smee - March 17, 2009

We have deployed numerous models, mostly HP/Compaq and Dell, of computers here. Recently received 30 Compac DC5800 MicroTowers; uses the Intel 82566 DM-2 Gigabit network controller. Cannot get the PE boot disk to access the network. Even created a boot disk with NOTHING but the DC5800 network drivers and it still can’t find the card. How do we start the deploymeny when the boot CD won’t recognize the network? HELP!!

Marimar - March 31, 2009

Hi David!

Try this http://support.microsoft.com/kb/923831
This error occurs with most of the chipsets in Intels 825xx driver family, both with xp drivers and vista drivers, and also in Winpe 2005 and 2.x
I’ve come across this error at several sites so I’m pretty sure this is the solution for you.

Wester - April 26, 2010

Hi Johan,

Have you made available your script for adding drivers to the Driver Packages area only scenario #3B from the BC32 A Drivers Saga – The Control Freak meets The Dynamic Developer seminar? Or could you email me the code.

Thanks!
-Wester

arwidmark - June 1, 2010

Hi Wester,

Michael Niehaus posted the script on his blog, see the Additional reading section in this article.

adelatorre - September 2, 2011

I’m very new to this and trying to implement this system. I need help/clarification/more detail, on exactly where you GET the drivers you are supposed to COPY in step 2 above.

HP has a driver dvd which has drivers for all their different models. I’m not able to find a disk to download anywhere that has drivers for just a particular model.

I went to the hp support site, and with much effort can download drivers for each hw component, but they are .exe files that want to execute and install, and no command line switch I’ve tried lets you just unpack them.

Can anyone explain what the SOURCE of your drivers is?

Thanks.

arwidmark - September 4, 2011

For HP i recommend using the HP Softpaq Download Manager.

You might also want to review this presentation I did on drivers at TechEd: http://channel9.msdn.com/Events/TechEd/Europe/2010/WCL314

/ Johan

CT - November 26, 2011

If I create a driver package, but don’t import the drivers into SCCM what about DPs? If the source directory is in the United States and a PC in China requests the driver package, won’t it need to come all the way back across the WAN? Almost seems like you must import the drivers unless you have a small/localized environment. Also, has anyone implemented this successfully using NOMAD?

arwidmark - November 27, 2011

You still need to add a DP to the driver package, and the client will pick the closest DP (depending on configuration) when downloading the driver package(s). I have not tested this with NOMAD.

/ Johan

Benjamin McConnell - January 24, 2012

Nice article Johan. I like the trick you used to add multiple copies of the same driver to the driver store.

I have a different approach that I’d like to share. I prefer to use as few folders in the driver node as possible due to the static nature of folders. Instead I rely heavily on Search Folders. This allows me to create dynamic folders by category, class, provider, and several other properties. When importing drivers into SCCM, I create a new category, for example: “Dell_PrecisionM4600_Win7x64”, and then assign that category to all the drivers I am importing. After the drivers are imported, I create a new search folder named after the Category. I also have categories for Winpe drivers. The key to driver managment is accessiblity and ease. Search Folders are structured but extremely flexible and make finding a specific driver or group of drivers very easy.

I also use the wmi query method shown above in my task sequences to ensure they don’t break when I add new drivers to SCCM. This works great. I recommend using a query that collects all the unique models in your environment to determine your search strings though. If you do not match the model exactly, you may end up applying a driver package to the wrong system. An example of this is the similarity between many of the Gateway laptop models and Dell laptop models.

Tip of the night: M4600 touchpad driver prevents Windows Server 2008 R2 SP1 Build and Capture Task Sequence from succeeding. Apply only storage and nic drivers during Build and Capture Task Sequences, and you will avoid this issue.

arwidmark - January 24, 2012

Thanks Benjamin,

Yes, it’s a good approach, and I have been using that with SCCM 2012 since SCCM 2012 doesn’t really allow for the same type of “creating packages from a separate folder structure thing”….

And thanks for the extra tip on the touchpad driver breaking build and capture !

/ Johan

Huy - December 3, 2012

Johan – I’m using the same drivers management concept as you’re and ran into a problem that I couldn’t understand the reasons behind this strange behaviour.

I deleted the root folder, say VISTAX86, within SCCM ConfigMgr Console – the sub-folder “HP Compaq 8510W” would end up merge to the root folder under Drivers after a refresh (F5). Then if I deleted “HP Compaq 8510W”, the sub-folder NIC would end up in the root folder after a refresh (F5) and so on… (ie, if I have another folder under the sub-folder NIC, it would merge to the root folder again). So it is a nightmare when one has about a dozen of models and they were organized in nested folders 5 level deep.

The same issue applies to Driver Packages and Software Distribution packages (I created packages for “bad drivers”).

Have you ever seen this strange behavior from SCCM from your experiences?

Thank you for your help in advance.
HH.

Huy - December 3, 2012

Johan – I’m using the same drivers management concept as you’re and ran into a problem that I couldn’t understand the reasons behind this strange behaviour.

I deleted the root folder, say VISTAX86, within SCCM ConfigMgr Console – the sub-folder “HP Compaq 8510W” would end up merge to the root folder under Drivers after a refresh (F5). Then if I deleted “HP Compaq 8510W”, the sub-folder NIC would end up in the root folder after a refresh (F5) and so on… (ie, if I have another folder under the sub-folder NIC, it would merge to the root folder again). So it is a nightmare when one has about a dozen of models and they were organized in nested folders 5 level deep.

The same issue applies to Driver Packages and Software Distribution packages (I created packages for “bad drivers”).

Have you ever seen this strange behavior from SCCM from your experiences?

Thank you for your help in advance.
HH.

arwidmark - December 3, 2012

I’m assuming you have imported the drivers. Try deleting the drivers first, and then the folders.

/ Johan

Comments are closed