Traditional OSD Driver Deployment
Driver deployment during OSD has remained mostly unchanged since the days of ConfigMgr 2007, despite some of the awesome new features that have appeared since. For many, it can be a real bugbear to have to cater for an ever-expanding line of models to support.
Traditionally, the process of driver package processing during OSD involves creating a driver package and associating a WMI query to match the model and apply the driver package where a match is found. That is of course for those admins who stay away from the dreaded “use at your own risk” method that is Auto Apply Drivers.
In the example below you can see how the traditional WMI filtering method is applied for a Dell Latitude E5470:
WMI Query
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE “%Latitude E5470%”
Modern Driver Management
Back in March of 2017, Nickolaj Andersen and I posted a method which attempted to address this issue. We called the process “Modern Driver Management” or MDM for short, not to be confused with Mobile Device Management.
The process used a web service as a secure method to query various objects in ConfigMgr and leverage the returned data with a PowerShell script. The initial three-step method was based on the model name of the machine which is retrieved from WMI in PowerShell. An example of WMI query can be seen below:
Improving Model Matching
Having considered the unique matching values we could use for model matching, we found that there was no one fits all approach to this. For example, HP models contain a unique matching in the BaseBoardProduct value:
Model: HP EliteBook Folio G1 Notebook PC
Get-CIMInstance -ClassName MS_SystemInformation -NameSpace root\WMI).BaseBoardProduct
8170
(Get-WMIObject -Class win32_computersystem).model
EliteBook Folio G1 Notebook PC
Using the BaseBoardProduct value in this instance, we can then provide a match against the HP XML feed resulting in a download. Using this approach across other manufacturers needs to be tweaked to cater for unique identifiers in different property fields. Here we have a PowerShell extract showing how this is achieved for each of the manufacturers:
Microsoft
$ComputerModel = Get-WmiObject -Namespace root\wmi -Class MS_SystemInformation | Select-Object Expand-Property SystemSKU
Hewlett-Packard
$SystemSKU = (Get-CIMInstance -ClassName MS_SystemInformation -NameSpace root\WMI).BaseBoardProduct
Dell
$SystemSKU = (Get-CIMInstance -ClassName MS_SystemInformation -NameSpace root\WMI).SystemSku
Lenovo
$SystemSKU = ((Get-WmiObject -Class Win32_ComputerSystem | Select-Object -ExpandProperty Model).SubString(0, 4)).Trim()
MDM Component Updates
With an improved model matching method, we set about putting through a number of improvements with the goal of having a single task sequence step for fully dynamic driver deployment.
In the background, we implemented updates to the Web Service and Driver Automation Tool to return matched values based on model entries written into the driver packages. Below is an example of a Lenovo driver package:
You can see that in this instance there are many sub-models all supported by this single driver package.
One Script. One Step. Fully Dynamic Driver Deployment
Here we arrive at our solution today, a single PowerShell script that can do the following;
- Query the web service to return a list of available driver packages
- Match packages from the full list based on the models, OS and architecture supported by the driver package
- Download the content using OSDDownloadContent.exe and set the path variables
- Apply the downloaded driver content using DISM
That is a single task sequence entry to achieve all this automation:
I think you will agree with me saying this is awesome.
Conclusion – PowerShell / Automation FTW
Most of what has been achieved here is done directly with PowerShell. So, for those of you who are still considering what value it has, please take time to learn how to script and provide some much-loved automation to your environment.
More information on the Modern Driver Management process and links to the Web Service, Driver Automation Tool and associated scripts can be found on the SCConfigMgr blog here.
Many thanks to Mattias Benninge in the post for providing the idea of the web service.
MEET YOUR MVPS
