When a device vendor provides a driver update, there is often an important and pressing security reason behind it. Every day that goes by without the update being applied across all the relevant endpoints in your estate increases your security risks. The level of increase varies depending on the nature of the risk, but it is elevated, nonetheless. Despite the importance of applying vendor driver updates as quickly as possible, especially those that are patching a security vulnerability, policies and procedures in enterprise organisations can be less than robust. The manual nature of the driver update process is one of the reasons, and there can often be a disconnect between product owners and security teams who request updates and production/operations teams who are responsible for actioning them. Automation is the solution. In this blog, we’ll explore the options for automating vendor driver updates, including the benefits, risks, flaws, and challenges.
The Role of Deployment Systems
Whether you use Config Manager (SCCM) or Endpoint Manager (Intune) will be a key factor in determining how you package, test, and distribute vendor driver updates. With SCCM, the process is almost fully manual. There are configuration settings that let you control the deployment, but vendor driver updates need to be manually reviewed, approved, packaged, and tested.
Automating Vendor Driver Updates in Intune
With Intune, you have more automation options through Microsoft’s Windows Update for Business (WUfB) service. In simple terms, you can automate driver vulnerability patching with WUfB’s driver update service.
In this process, you set the policies, specifying the drivers to automatically update when a new version is released by the vendor. You can also create deployment rings to stagger the automated release of updates. The idea is that problems with an update can be identified and rectified in a small ring of deployment before broader deployment occurs.
You can also manage the process manually through Intune, where all or some drivers are set for manual approval before deployment through WUfB. Then there is the additional Windows Autopatch option. Autopatch enhances WUfB with more automation, including automated remediation.
For drivers configured for automation, the Intune WUfB option (with or without Autopatch) is essentially a set-and-forget approach. But it comes with risks. Updates can cause components to break, for example, application compatibility problems can occur, and other issues can arise. Also, these problems don’t always occur in one of the early deployment rings, so the impact can be large and the remediation effort substantial.
With the WUfB option, you are also handing over vendor driver updates to Microsoft rather than getting drivers directly from vendors. For many IT leaders, this also represents increased security and operational risks above an acceptable level.
It comes down to balancing the risks and rewards of letting Microsoft manage vendor driver updates in your organisation. The rewards are clear, especially for production teams who can largely forget about driver updates once the initial policies and configurations are set. The risks are that problem drivers are deployed to devices and the knock-on effects this can cause.
Vendor Specific Solutions
Most large device vendors provide solutions to help manage driver updates and security patching. Lenovo Vantage, HP Client Management Script Library, and HP Image Assistant are examples. These options offer the benefit of getting driver updates directly from the vendor, but they can also add complexity, especially when an organisation’s fleet is made up of devices from different vendors.
Focusing on Key Priorities
We take a controlled approach to automation at Access IT Automation. We prioritise making massive reductions in manual effort, but we also strive to ensure this doesn’t create additional problems and unintended consequences.
With the Microsoft-Intune-WUfB-driven approach, the massive reduction in manual effort is achieved. But because there is no testing before deployment, devices, networks, and applications can break as a result. Hopefully, those breakages occur in small deployment rings, and, hopefully, the breakages can be quickly rectified. But none of that is guaranteed.
For a more controlled approach to automation, and for organisations using SCCM, packaging and then testing driver updates reduces risks. In other words, the testing step should not be skipped. Deployment, even using a staggered approach, should always follow a testing phase.
Our product, Access Capture, was designed to automate the packaging, testing, and publishing of applications at scale. We are currently updating the product to also handle vendor driver updates with an emphasis not only on automated packaging and publishing ready for deployment, but also testing. We’ll bring you more information soon – follow us on LinkedIn to stay up to date.
