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.
Michael Klinteberg commented
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
Kudos goes to some deployment MVP on twitter (Sorry don't know how it was).
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.
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?
Kim Oppalfens commented
This blogpost should get you pretty close to what you want to achieve.
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.
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.
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.
We pretty much do this today. Just package your drivers as a normal application and call dpinst.exe to inject them.
Andrew Malcolm commented
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, Chase commented
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.
Andrew Malcolm commented
I've been using autoapply drivers for years... it works just fine?
Jay Tuckey commented
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.
Jim Walker commented
This would help quite a bit.
Jay Connor commented
Alternatively overhaul the driver step -
Add Applicable rules to each driver package
1. Hardware model
2. PNP ID
Then Driver Pack OS preference order if multiple driver packs match
John Bruckler commented
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.
You got my vote!
Joe Garza commented
In for the solution.
Henrik Rading commented
Yep, We need that feature to keep TS cleaner.
Kenneth Sundby commented
If I had any remaining votes I would give them to this..
This would be a killer feature!
Eric Wood commented
This would be great!