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:



  1. NICE Drivers – Drivers that install using an INF file.

  2. 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:



  1. Host OS – These are drivers that are installed on the Host OS.

  2. 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:



  1. 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.

  2. 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:



  1. Create a new package that contains all of the required drivers for this hardware type

  2. Add an “Apply driver package” task to the task sequence with a WMI filter based on model type

  3. If required I configure the “Apply driver package” to apply a Mass Storage driver

  4. Create an application for each driver that must be installed

  5. 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:



  1. Devices that aren’t found by a PnP scan such as USB devices, multi level drivers and devices not enabled during deployment (like Bluetooth). 

  2. 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.



       image


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.




        image 



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”.



      image


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.


       image



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 (64)

  1. Anonymous says:

    Comme plusieurs personnes sont en mode de préparation au déploiement de Windows 7, je vous recommande

  2. Anonymous says:

    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,

    Rich

  3. Ben Hunter says:

    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,

    Ben

  4. Anonymous says:

    I am often asked what the best way is to manage drivers with both BDD/MDT and ConfigMgr. With this in

  5. Ben Hunter says:

    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,

    Ben

  6. Ben Hunter says:

    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,

    Ben

  7. Anonymous says:

    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!

    Rich

  8. Anonymous says:

    The following post recaps on the questions we covered off during last weeks webcast on desktop deployment,

  9. Anonymous says:

    Ben put together a really nice artice on driver management in MDT and ConfigMgr. File this one away!

  10. Anonymous says:

    Looking forward to it.  In the mean time, here is the issue I’m having:

    I’m trying to deploy a Windows XP WIM image to a Dell Latitude D610 using the MDT 2008.  The image was captured from the laptop with no drivers added, not sysprepped.  I’m trying to deploy it back and have it install all of the drivers for the laptop.  I’ve added the drivers to the Out-of-Box Drivers in the Distribution Share and created a group for the drivers, they also happen to be the only drivers I’ve added at this point.  After deploying the image and going back into Windows, none of the drivers have installed.  I’ve also copied them to the $OEM$ share with no luck.  I’ve been searching for a solution for this for about a week now but it seems no one has had an issue with this and can only find the standard answers of adding the drivers to the Out-of-Box drivers and $OEM$ share.  I have not made any modifications to my Task Sequence.  I attempted adding the LTIapply.wsf script after the Install Operating System task in hopes that it would copy the drivers before rebooting, but alas no luck.  I apologize if I’ve just confused you, I’m still pretty green to the Deployment Desktop work after having worked with Image X for the past year and a half.

  11. Ben Hunter says:

    I am working on it now :). So it shouldn’t be too long.

    So much to do so little time :(.

    Ben

  12. Ben Hunter says:

    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,

    Ben

  13. Ben Hunter says:

    Hi Rich,

    I will cover this in my next post :).

    I just have to find the time to finish writing it.

    Thanks,

    Ben

  14. Ben Hunter says:

    Hi Greg,

    I would suggest that you try the method in my previous reply to Rich and see if that works.

    Thanks,

    Ben

  15. Ben Hunter says:

    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,

    Ben

  16. Ben Hunter says:

    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,

    Ben

  17. Ben Hunter says:

    Hi Mwest,

    I would suggest that you should sysprep the machine before you add it into MDT. This could be causing some of your issues.

    The out-of-box process should work for most drivers witout you needing to do anything special.

    Thanks,

    Ben

  18. Ben Hunter says:

    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,

    Ben

  19. Anonymous says:

    Hey guys,

    Great blog, been really informative so far.  When can we expect to see Part2 for the MDT 2008?  I’ve been trying to deploy a captured WIM of XP and add my Out-of-Box Drivers but can’t for the life of me get them to work.

  20. Ben Hunter says:

    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

    Ben

  21. doxley says:

    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,

    Daniel

  22. Anonymous says:

    Ben,

    I understand now what you meant earlier in relation to writing a script to execute the install of the patches.  I bring my XP gold image down every 3 months to update the capture with security updates.  At that time, I see if there is anything else that I could add to the image, such as hotfixes, and the items mentioned above.  

    Is there anything wrong with doing it this way, opposed to adding them in via task sequence?  

    Rich

  23. Anonymous says:

    Injecting Apply Driver package in Task Sequence (SCCM SP2) reboots the cilent machine without installing any OS.

  24. Ben Hunter says:

    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,

    Ben

  25. Ben Hunter says:

    Hi Rich,

    I like to create an application for each task that I perform when creatig an image.

    So what I would do here is create an application with source files. The source files would be the patches. I would then write a vbscript that installs these patches. The command line for ths application would then run the vbscript.

    I then add the application to the task sequence.

    Thanks,

    Ben

  26. Anonymous says:

    Ben we have been using almost the same concept however we created a Vista X86 driver package and Vista X64 Driver package.  The reason for this is we are maintaining drivers for about 8 different Dell models that share a lot of the same drivers.  For example if I add the Dell Optiplex 755 Drivers this will also use the same chipset drivers as several other Dell workstation models.  The problem here is SCCM lets you add the drivers to the repository once and if you accidently add them again it errors out.  The only reason why we would add them again is it is much easier to create a packge and point it to a folder with all the appropriate drivers for a certain model rather then hunt and peck looking for the drivers from the repository.

    This also has it down-falls.  Since everything is associated to 2 groups X86 and X64 it may cuase issues by Vista selecting a wrong driver however this has not happend yet.  You are also injecting a lot of drivers not needed for that model.  So here is an example of what I am referring to, when adding drivers for a computer that may allready have them in the repository you get the errors indicating it allready exists.  Well this is a real pain in the ass if I have to go and manually add every single chipset driver that may be needed for a certain model.  Maybe chipset makes sense to create a seperate category or even use application packages for these?

    I would like to follow your method however I was curious how you deal with drivers that are the same driver across muliple models?

    Thanks

    Error: Some driver(s) can not be imported successfully. Please see following details.

  27. Ben Hunter says:

    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,

    Ben

  28. Ben Hunter says:

    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,

    Ben

  29. Ben Hunter says:

    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,

    Ben

  30. Björn Axéll says:

    Hi Ben

    Thanks for an exilent post, looking forward to the WD part.

    Thanks!

    Björn

  31. Or Tsemah says:

    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 NewerBetter

  32. cca1 says:

    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?

    Thanks

  33. Rich says:

    Hi Ben,

    Looking forward to your post on this process with MDT/BDD!

    Thanks!

    Rich

  34. Rich says:

    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!

    Rich

  35. Rich says:

    Hi Ben,

    Sounds like I should be bringing down my captured WinXPSP2 Image and adding these updates such as the UAA High Def Audio class driver to my gold image, then recapture, and redistribute to MDT?

    I was sort of confused with what you were trying to get at when you say you create another application to install them.  

    Thanks brotha!

    Rich

  36. Rich says:

    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,

    Rich

  37. greg says:

    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?

  38. Rich says:

    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,

    Rich

  39. nico says:

    Ben,

    When are you gonna post Part 2 of the Driver Management?

    I’m very interested!! Thanks

  40. MD. BDD part 2 blog entry would be great.  Ben, do you expect to have it done any time soon ?  thanks in advance.

  41. Andrea says:

    Ben- First can you send a link,or post the link for the setup logs blog you have? I can’t find it. I’ve used your blog for mass storage drivers and am having an issue with the machine just re-booting after deploying a captured image.I can boot from the cd and look at the logs and the setup api log has a couple failures on 3 diff devices. All these devices are in the out of box drives and should be in the c:drivers folder in the captured image, which sysprep has the path for. What else can I do to troubleshoot this problem? Also, MDT 2008 has a task in the client std task sequence to resolve the uber bug problem. I’m not sure a lot of people know that. It’s disabled by default. This link tells how to fix a problem in the script, but I found that with MDT 2008 the script was modified and looks ok.

    http://blogs.technet.com/msdeployment/archive/2007/11/22/workarounds-for-two-bugs-in-microsoft-deployment.aspx

  42. jarod.han says:

    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 driver

  43. Andrea says:

    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.

    😉

    andrea

  44. Rob says:

    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?

  45. 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

    JAred

  46. Patricio says:

    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!

    /Patricio

  47. Andrea says:

    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?

    Andrea

  48. Andrea says:

    My fault- used the XP driver that shipped with the machine- Forgot that I needed the vista driver for Win PE- All happy again. 🙂

    Andrea

  49. rudi says:

    Hi Ben,

    Concerning the installation of the "Bad Drivers": is it possible to download and execute these packages, instead of running from the SCCM Distribution point?

    Very good article! helped us a lot,

    Rudi

  50. Dustin Mobley says:

    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?

  51. Brian Hall says:

    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!

  52. Louis Dawso says:

    I have stuggling with running the ATI and Nvidia driver setup during a XP deploy task sequence. The driver installs OK when I run it interactivly via a advertised program. I get the following error when it runs in the task sequence:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~

    The task sequence execution engine failed executing the action (Install ATI Radeon X550 Graphics Driver) in the group (Hardware Based Applications) with the error code 50

    Action output: . The operating system reported error 50: The request is not supported.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~

    The command line i’m using is the following:

    Setup.exe -s -SMS -f1"setup.iss" -f2"c:WindowstempRADEON.log"

    I found the solution.  The command line looks something like this:

    setup.exe -s -f2c:driversnvidia.log

    For some reason you need to drop the -f1setup.iss and -SMS switches. I also worked out how to install different drivers depending on what model of graphics card is installed. This is an issue for us since the same computer Model could have different graphics cards. Just work out what PNPiD your graphics cards are. eg PCIVEN_10DE&DEV_0402&SUBSYS_043910DE&REV_A14&196AFE53&0&0008

    Trim off the sub-revision ids a like this VEN_10DE&DEV_0402

    Creat a Package and install it in your task Sequence after the apply Drivers section.

    Now in your task sequence step set the WMI condition to query the PNPdeviceID like this:

    SELECT * From Win32_PnPEntity WHERE PNPDeviceID LIKE "%VEN_10DE&DEV_002C%" OR PNPDeviceID LIKE "%VEN_10DE&DEV_0171%" OR PNPDeviceID LIKE "%VEN_10DE&DEV_01D1%"

    This way you can install the right BAD driver devending on what PNPid the hardware has, which is much better than just the Model.

    Louis

  53. Mario says:

    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.

  54. christophe says:

    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.

  55. Oskar says:

    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".

  56. Abbylab says:

    I was curious about using SCCM as a tool for mass printer driver deployment?

  57. Herb says:

    So much for there being a PART 2

  58. SuperDAve says:

    Ben,

    I know this is an old post and I had my clients refer to it often when I helped them with XP and Vista OS deployments.  These same steps are also valid for Windows 7 driver injection.  As the years went by, I learned many "tricks of the trade" on how to find the best solution for driver injection.  Some months ago, I happen upon a utility called Double-Driver.  It does a backup of drivers on a target system.  I use this utility, backup the drivers and then import them into MDT or SCCM.  While it's not magic bullet to all my driver injection issues, it sure does cure about 90%+.

    The client gets a new make/model, with the OEM OS still on it.  We run Double-Driver, backup all the drivers that are not Windows 7 default drivers and then import them into MDT/SCCM.  We then update the Task Sequence to include these drivers based on WMI query, and push our Win7 image to the new system and see what happens.  Typically I see HECI chipset drivers and the occassional Wireless driver not come over, but then I just download and inject those the old fashion way into MDT/SCCM.  I've sped up my driver injection solutions 10 fold by using Double-Driver.

    My two cents..

    SuperDave

  59. Shayan says:

    Thank you for this excellent post. Helping my new job role. thanks..

  60. Papa Bear says:

    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 deployement

  61. TimD says:

    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!

  62. Appreciated says:

    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.

  63. Martin says:

    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!!