Better Driver and Driver Package Management
Driver Management within the console is unacceptably slow (still). We manage 60+ unique Models across Windows 7 all the way up through Windows 10. As a result there are a LOT of drivers to maintain and manage. With SCCM 2007, we had the ability to at least break these down in folders. With sccm 2012 you removed the ability to import directly to a folder. The trade-off was "categories" however, it is still incredibly slow to search for drivers.
In addition, with SCCM 2007, we could just fill a folder with inf's and create a driver package from that without having to import the drivers into the console. With sccm 2012 this was taken away. There are only 2 reasons that a driver needs to be imported:
(1) using "Auto Apply Drivers" which doesn't work very well and every MS Engineer we've talked to tells us not to use it
(2) if importing into boot media. With a wide support base for hardware, the SCCM Console would fail constantly when attempting to inject drivers into the console. We have gone back to injecting these via DISM, then importing the Boot Image due to the poor performance and reliability of using the SCCM Console.
All-in-All, we had much better success staging a driver package manually rather than using the console. Either bring back this feature, or fix the console.
Tom Stack commented
The current driver management as already talked about is slow, cumbersome, not easy to maintain and delete old unneeded drivers, etc. Know what ones are still needed. Please put some improvements to the driver functionality.
Ryan Morash commented
It would also be nice if you could automatically create driver packages from Microsoft Update based on the inventory/Asset Intelligence information in SCCM.
Thomas Bianco commented
i have several client using packages and DISM command lines to deploy drivers from a (application) package, bypassing the driver library, it's overhead, and the risk of duplicate drivers affecting unintended models.
perhaps this could be addressed by changing the way driver packages are updated to permit manually creating the package directly the same way an application package is created?
I emulate what ConfigMgr 2007 did by just creating a regular package (not a driver package) with a source folder with all the drivers for a particular model.
In the task sequence, I do a Run Command Line step with the Package selected, WMI Query for model, and this DISM Command:
DISM.exe /Image:%OSPartition%\ /Add-Driver /Driver:.\ /Recurse
Where %OSPartition% is the partition variable from the Partition TS step.
Doing it this way has been very reliable with all versions of Windows since 7. It also prevents the file duplication that happens when creating a driver package. Plus the driver database was always a headache. I only import WinPE drivers now.
To piggyback off this idea, as an improvement to the Driver Package management: Please let us just right click on a driver package, add or remove drivers directly from the driver package. The current method of finding a driver you *THINK* might be on the package and removing it that way is a PITA.
David Stein commented
Oh boy. I like this suggestion, but it would also be nice if vendors could be encouraged (beaten?) to standardize their enterprise driver offerings in a way that makes it easier to process through OSD.
Jeremy Sichak commented
Have been dealing with this for a while. Driver management for Windows Boot media is abysmal. We've gone back to just injecting the drivers using DISM as well. It would be nice if Microsoft would change up the "Drivers" tab within the boot media so that it had more detailed information as to which driver was injected. Maybe allow us to customize the columns so that we can include the category assigned or some other defining property.
https://gallery.technet.microsoft.com/Integration-Kit-d4e32845#content check this on out. Created a drive package manager that uses the files system instead of the built in importer.
Use it all the time when I recreate new driver structures for clients.