In our previous blog post we talked about the state of UEFI firmware running on Windows laptops attached to one of our research networks.
In case you don't recall the conclusion: We were surprised that many of the devices were running out-of-date firmware and decided to investigate ways in which automated UEFI firmware updates could be scaled to meet the needs of an Enterprise. This blog tells the story of what happened next.
We set ourselves a simple initial goal - To test successful deployment of UEFI firmware updates in an enterprise-like lab environment, one that could scale to meet the needs of a large organisation. We decided our initial tests would cover Dell, HP and Lenovo laptops as well as Microsoft Surface devices.
The first thing we found is that Surface firmware is exposed as a device driver and Microsoft take advantage of this to deliver firmware patches via Windows Update. So all you have to do on the Surface is use Windows Update and you automatically get the latest firmware versions installed.
Unfortunately, Dell, HP and Lenovo don’t currently update UEFI firmware through Windows Update. Instead, they all offer their own enterprise management tools for UEFI firmware. HP and Dell also publish catalogues of UEFI firmware updates for their platforms.
In our testing, we found it easiest to take advantage of these catalogues by using Microsoft System Center Update Publisher (SCUP) in conjunction with System Center Configuration Manager (SCCM) to push out updates to client machines. This allowed us to target the Dell and HP devices at the same time, without having to run multiple client management solutions. The SCCM client also offered the ability to automatically suspend BitLocker during a restart, something which is critical to many organisations when deploying a UEFI firmware update.
For Lenovo, we had to take a different approach. Lenovo’s System Update and Update Retriever tools can be used to deploy UEFI firmware updates, but they do not provide the capability to suspend BitLocker. Lenovo do offer a plugin to SCCM as a paid for service, but we opted to take advantage of a custom task sequence in SCCM. This provided the necessary steps to target the update, suspend BitLocker, stage the firmware update, and restart the device to perform the update.
Testing was successful and firmware updates have since been reliably installed on a wide range of devices, not just in the lab but also with live deployments at other government departments.
So, as a result of this work, we are updating our Windows 10 EUD guidance to explain how you can automate your own UEFI firmware updates. Look out for the guidance later this month and let us know if you find our approach useful.