Microsoft

System Center Configuration Manager Feedback

How can we improve Configuration Manager?

Allow for dynamically selecting Apply Driver Packages

Allow for dynamically selecting Apply Driver Packages, pretty much like it works for normal packages (applications). This would reduce the number of hardcoded Apply Driver Package in the task sequence.

695 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Johan ArwidmarkJohan Arwidmark shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Noted  · 

    21 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Michael KlintebergMichael Klinteberg commented  ·   ·  Flag as inappropriate

        We are doing this.
        1) In Drivers management; Create a Category for each driver and model. Example "Windows 10 x64 Precision 5510"
        2) In task sequence before Auto Apply Drivers. Add a script that set the variable OSDAutoApplyDriverCategoryList == DriverCategoryUnigueID. Example below is just a part of the script to show the important bits.

        sQuery = "select CategoryInstance_UniqueID from sms_categoryinstance where LocalizedCategoryInstanceName = '" & sOSDDriverOS & " " & sModel & "'"

        ' Process the query
        Set oDriverGUIDs = oSMS.ExecQuery(sQuery)
        For each oGUID in oDriverGUIDs
        oTSEnv("OSDAutoApplyDriverCategoryList") = oGUID.CategoryInstance_UniqueID
        Next

        Kudos goes to some deployment MVP on twitter (Sorry don't know how it was).

      • MarkMark commented  ·   ·  Flag as inappropriate

        The one thing I will say is that the solution will need to spare a thought for people that need to create offline OSD TS media. Our USB keys have bloated to needing 64 gig keys due to all the different driver packs for all the models we support.

      • Anonymous commented  ·   ·  Flag as inappropriate

        I work in ConfigMgr OSD team at Microsoft. Would like to hear some feedback to the following:

        At the present time driver packages cannot have associated programs that can be deployed to collections. This means that when we try to use driver package dynamically at run time, we cannot request dynamically policy for its package program and cannot get dynamically the content of the package.

        A simpler solution implementation wise would be the following:

        allow users to select several driver packages in the same “Apply Driver” step so that all of them will be considered package references (like it is done currently in Content Download task sequence step - always resolved and downloaded) , and also to let user to control which of these selected driver packages will be:
        1) applied always like single package is applied now or
        2) applying of which is controlled dynamically through some task sequence variable mechanism.

        Would this be acceptable solution? Will this help you your scenario?

        --
        Vladimir

      • Kim OppalfensKim Oppalfens commented  ·   ·  Flag as inappropriate

        This blogpost should get you pretty close to what you want to achieve.
        http://www.oscc.be/sccm/osd/The-holy-grail-of-ConfigMgr-diver-management,-or-whatever-you-want-to-call-it/

        The apply device drivers step doesn't give you the same level of control, and misses the ability to apply drivers for hardware that is not detected. Which is problematic on some devices where a certain piece of hardware only pops up after a "parent" component is detected.

        Other methods require one to modify your tasksequence each time it has to support a new hardware model. This request (or the alternative implementation in the blogpost) allows for a hands-off approach, needing no TS edits to support new models.

      • StarmantleStarmantle commented  ·   ·  Flag as inappropriate

        Here is how I implemented drivers injection... (the only drivers in the SCCM console.. are those required for WinPE)

        - Manually Install Drivers on each and every make/model combo.. then copy the drivers off each of those machines up into a network share...
        - In TS... I Collect the Make/Model.. and standardize them.. removing spaces.. (replacing every Dell or Dell, Inc, etc.. with DELL)
        - In TS.. I map that network share.. and run a "Dism /image:%OSDisk%\ /Add-Driver /driver:Z:\Drivers\10\%SMake%\%SModel% /recurse /ForceUnsigned" command to install the drivers apropriate to that particular machine.

      • LBrownLBrown commented  ·   ·  Flag as inappropriate

        I would enjoy seeing this implemented in such a way as to allow a string of TS variables set by WMI queries or other Dynamic means to specify the driver package to install within a particular folder structure.
        Something like "TSOSVar\TSManufacturer\TSArchitecture\TSModel" could direct my TS to the driver package "Windows10\Dell\x64\Precision Tower 7910"
        This way the TS wouldn't have to be updated with every new model (our list of supported devices isn't getting any shorter) but rather we'd simply add the driver packages to the appropriate location and let the Apply Driver step find it where we put it.

      • dgrdgr commented  ·   ·  Flag as inappropriate

        We pretty much do this today. Just package your drivers as a normal application and call dpinst.exe to inject them.

      • Andrew MalcolmAndrew Malcolm commented  ·   ·  Flag as inappropriate

        I see where this is coming from now. If your oem of choice has **** drivers that match incompatible hardware I'd say "switch oem's!" but that's admittedly not an option for everyone...

      • Roth, ChaseRoth, Chase commented  ·   ·  Flag as inappropriate

        This would be such a help! Straight auto apply drivers does NOT always get the driver you want or need. Specifying the driver packages via WMI is the ONLY way to go in my book, since "Model" variable in MDT integration is not wildcard or "like" capable without fancy scripts from Johan or Deploymentbunny. Now I need to work on reducing the number of non-INF driver install packages and they take 3/4 of my task sequence. Maybe time to convert them to be Applications to reduce the area taken up in TS.

      • Jay TuckeyJay Tuckey commented  ·   ·  Flag as inappropriate

        There is already an "Auto Apply Drivers" step for task sequences. Surely this addresses what you guys are trying to achieve. I've been using this method for over a year without any issues.

      • Jay ConnorJay Connor commented  ·   ·  Flag as inappropriate

        Alternatively overhaul the driver step -
        Add Applicable rules to each driver package
        1. Hardware model
        2. PNP ID
        3. TSVariable
        Then Driver Pack OS preference order if multiple driver packs match
        -

      • John BrucklerJohn Bruckler commented  ·   ·  Flag as inappropriate

        The way it's designed now is very prone to human error, and makes OSD difficult to manage when supporting large numbers of device models and manufacturers.

      ← Previous 1

      Feedback and Knowledge Base