Partager via

Configuration Manager - Dynamic Driver Categories

  • Article

When injecting drivers using the "Auto-apply Drivers" task you can filter the drivers that are injected based on the hardware type. The MDT documentation identifies a method of doing this but it his requires an update to the task sequence every time you add a new category (model type).

The following process will allow you to dynamically specify the a category based on the models WMI identifier. This means that you will not need to add a new "Auto-apply Drivers" drivers each time you add a new model type.

So how does this work?

The “OSDAutoApplyDriverCategoryList” property in the task sequence is used to determine which categories to use in the “Auto-Apply Drivers” task. So all we have to do is override the categories configured through the task sequence editor. However, the value you would need to set is not obvious.  Here’s a sample:

             DriverCategories:3be2057f-1508-44a8-8325-0f5ab444b422,DriverCategories:bf594013-a680-4319-91bf-809f5502f620

These happen to be the GUIDs assigned to the two categories I’ve defined in the apply-drivers task.

So the trick to creating dynamic categories is to run a script that takes the WMI category and determines the associated GUID. Then we simply update the “OSDAutoApplyDriverCategoryList” property with this GUID, easy :).

Now we know how this works lets look at how you can implement it.

1. Import the drivers for your new model into ConfigMgr

2. Assign the drivers to a category that's name based on the WMI model value. The category name must match the model value returned by WMI. I have found the simplest way to determine this value this is via a WMIC query.

    The following steps detail how to perform a WMI, ensure that these steps are run on the new model NOT the server:

           a. Open a Command Prompt

           b. Type WMIC

           c. To determine the Model, type CSProduct Get Name

3. Update the attached script replacing the following values:

              sProviderServer = "SERVER" - The ConfigMgr server

sSiteCode = "X01" - The site code of the ConfigMgr server

sUsername = "domain\user" - Credentials required for a remote connection to the ConfigMgr provider.

sPassword = "Password"

4. Create a package using the attached script.

5. Create a program with the command line cscript zCFG-UpdateDriverCategories.vbs

6. Add a new task to your task sequence that runs the program. This task must run before the "Auto-apply Drivers" task.

 

This post was contributed by Ben Hunter a Consultant with Microsoft Services New Zealand.

zCFG-UpdateDriverCategories.zip

Comments

  • Anonymous
    January 01, 2003
    Is there a way of getting a workstation that did not have the drivers in the Task Sequence (thus not in Standalone Media) to do a rescan automatically when it does join the network and then query the OSD Driver Library?

  • Anonymous
    January 01, 2003
    I have been working on a script for our SCCM OSD task sequences. For years we have simply had all of

  • Anonymous
    January 01, 2003
    Hi Adam, I have updated the script, hopefully you could download it now. Thanks, Ben

  • Anonymous
    January 01, 2003
    The link is at the bottom of the page. I am not sure why you aren't getting it, however here it is for you - cid-7be6feba9e7c999c.office-df.live.com/.../zCFG-UpdateDriverCategories.zip. Thanks, Ben

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    December 09, 2008
    So I don't have to make any "Apply driver package" anymore? All drivers that I have, I have to change the category that must meet the exact name of the pc model? Not "%model%" but "model"? Thanks

  • Anonymous
    December 17, 2008
    So the big and only advantage against the normal "Apply driver package" would be that it will look for the correct model (categories) instead of making each time a different "Apply driver package" for each pc model? Thanks for your reply

  • Anonymous
    February 24, 2013
    The comment has been removed

  • Anonymous
    December 10, 2013
    Hi Ben, Does this still work in SCCM 2012 R2? I have been using this method in 2007 R3 for a while but on migrating to SCCM 2012 it no longer works. I'm guessing the variable needs a slightly different format.