This attempt may not be suitable for the faint hearted and it may be intertpreted as if I’m dropping a bomb but here it goes.
In all those years working with Configuration Manager, managing drivers for devices remains a daunting task. It is time consuming, requires a lot of administrative effort and storage as well. It is also difficult to explain to customers on dealing with it accordingly, just not my kind of fun…
With the release of Windows 10 and Microsoft’s approach with the semi-annual update channels it may make sense to reevaluate the daunting task of driver management.
Would it be great if it can be thrown out of the window (no pun intended) so you don’t have to bother about it anymore?
Well, the answer is yes if you meet the following requirements:
- The devices managed are pretty new, especially the ones who meet all system requirements to run Windows 10, especially the ones who meet the requirements stated at https://docs.microsoft.com/en-us/windows-hardware/design/minimum/minimum-hardware-requirements-overview (especially section 3.7);
- Internet Access is available in abundance (bandwith wise), this is especially true in the Netherlands where I come from;
- Time to invest some serious testing.
Microsoft has also redesigned update deployment for Windows 10. The number of updates have been significantly reduced by merging all updates in a single monthly bundle which will increase the build version of Windows 10 as well. From Windows 10 1607 and newer, a feature called ‘Dual Scan’ has been introduced as well you may even wonder if you can throw out Update Management in Configuration Manager out of the window as well. I understand this may be hard to let get go, but releasing yourself from all this administrative effort allows you liberate yourself from this as well, unless the required processes and company policies are in place allowing you to have this automated…
To summarize it all, would it be great to have a fully patched machine including all drivers during deployment?
After investigating, I found an old but still valid approach by Chris Nackers which is available at http://blogs.catapultsystems.com/cnackers/archive/2011/04/28/using-ztiwindowsupdate-wsf-to-install-updates-in-a-system-center-configuration-manager-task-sequence/
I followed the steps except setting the variable (by not setting it) required by ZTIWindowsUpdate.wsf to make sure the script will go to Microsoft Update and retrieve all required updates from there. Additionally, I did check the ‘Continue on error’ checkbox to make sure the Task Sequence can continue in case update installation may fail. During testing I noticed some old printer driver failed to update while the rest installed properly. Enabling the ‘Continue on error’ checkbox is easier than collecting all exit codes.
In my scenario, it looks like this.
Alternatively, you can place the step after installing all applications so they may be updated as well.
Of course this requires some testing, if some devices are not installed because the driver is not available on Microsoft Update, then you can add them yourself.
Since Microsoft likes Github so much, you can even download ZTIWindowsUpdate.wsf (and ZTIUtility.wsf) as well and even edit to to your liking (ie. reducing the number of retries), you find it at https://github.com/monosoul/MS-Deployment-toolkit-scripts/tree/master/Scripts
The result is the deployment may take some time but you have a fully updated machine and don’t need to bother about managing drivers afterwards.
Also, allowing Dual Scan will update drivers as well keeping that part of updating the device as well…