Windows - System Preferences - Manage Windows Update Driver Updates

What the Windows Update driver manager does

This Automox Worklet™ installs every Windows Update driver that the local Windows Update agent has flagged as pending. The evaluation script connects to the Microsoft.Update.Session COM interface, runs the search query Type='Driver' and IsInstalled=0, and returns exit code 2 when one or more drivers are waiting. Endpoints that are fully current return exit code 0 and the policy does no further work on that host.

The remediation script attaches the Microsoft.Update.ServiceManager service identifier 7971f918-a847-4430-9279-4a52d1efe18d, which adds Microsoft Update as a source so non-OS drivers (firmware, GPU, vendor chipset) are eligible alongside the standard Windows Update catalog. It iterates the pending driver set, calls AcceptEula() on each one, queues uncached drivers into Microsoft.Update.UpdateColl objects, downloads them with CreateUpdateDownloader(), and installs them with CreateUpdateInstaller().

Per-driver results are written to the activity log as Format-Table output: a Title plus Result column for successful installs, and a Title, Result, ErrorCode triple for failures. If any driver fails, the Worklet exits 2 so the Automox console flags the endpoint for follow-up. A successful run exits 0, and any drivers that require a restart leave the endpoint in the Needs Reboot state for the next maintenance window.

The Worklet is the inverse control to the Group Policy setting HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\ExcludeWUDriversInQualityUpdate=1. Where that policy tells Windows Update to skip drivers entirely during quality update scans, this Worklet asks Windows Update to install everything it has. Pick one model per endpoint group: locked-down fleets typically set ExcludeWUDriversInQualityUpdate via GPO and deploy drivers through vendor tooling, while unmanaged or BYOD-style endpoints benefit from this Worklet running on a recurring schedule.

Why centralize Windows Update driver policy

Driver state drifts on every Windows fleet. Some endpoints sit on Microsoft Update's full driver feed and accept whatever Patch Tuesday hands them. Others have ExcludeWUDriversInQualityUpdate set to 1 in HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and rely on Dell Command, Lenovo Vantage, or HP Image Assistant for vendor drivers. A third group has no policy at all and quietly skips months of network and storage driver updates because Windows Update never escalates them. The result is hardware-level inconsistency across what is nominally the same image, with blue screens, NIC throughput regressions, and Wi-Fi disconnects clustered on specific driver versions.

Windows Update driver installs stall quietly when an endpoint sits offline through a delivery window or when group policy disables the optional driver category. This Worklet enumerates pending driver updates through the Windows Update Agent API, installs the ones currently queued, and re-checks for new pending drivers on each evaluation pass. The result is consistent driver coverage across every workstation and server without an admin walking Device Manager on each endpoint.

How Windows Update driver installation works

1. Evaluation phase: The script instantiates Microsoft.Update.ServiceManager with ClientApplicationID = 'Automox', registers the Microsoft Update service (7971f918-a847-4430-9279-4a52d1efe18d), opens a Microsoft.Update.Session with UserLocale 1033, and calls CreateUpdateSearcher().Search("Type='Driver' and IsInstalled=0"). If the resulting Updates collection has any members, the script logs Found N driver updates available and exits 2; otherwise it logs No driver updates available and exits 0.

2. Remediation phase: The script repeats the search, walks the pending driver set, and calls AcceptEula() on any driver where EulaAccepted is 0. It loads uncached drivers into a Microsoft.Update.UpdateColl for download and the full pending set into a second UpdateColl for install. CreateUpdateDownloader() runs the download, checking that ResultCode is 2 (succeeded) or 3 (succeeded with errors). CreateUpdateInstaller() runs the install, and the script enumerates GetUpdateResult(i).ResultCode for each driver, sorting Title entries into a successful or failed Format-Table. Exit 2 if any driver failed; exit 0 once Installation of all drivers from Windows Update was successful is written to stdout.

Windows Update driver policy requirements

• Windows 8, Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or equivalent (workstation or server SKU)

• PowerShell 3.0 or higher (in-box on every supported OS)

• Administrator or SYSTEM context for the Automox agent so the Microsoft.Update.Installer COM object can write driver packages

• Outbound network access to *.windowsupdate.com and *.update.microsoft.com (or to your WSUS / Microsoft Connected Cache origin if Windows Update for Business is in use)

• Free disk space on the system drive for driver download and extraction; firmware and GPU drivers can each exceed 500 MB

• ExcludeWUDriversInQualityUpdate under HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate left unset or set to 0; a value of 1 instructs Windows Update to skip drivers and will cause this Worklet to report zero pending updates regardless of vendor availability

• Enable Auto-Reboot on the Worklet policy if you want the agent to handle restart-required drivers automatically; otherwise schedule reboots in a separate maintenance Worklet

Expected Windows Update driver state after remediation

On a successful run, the activity log shows the count of drivers downloaded, a per-driver Format-Table of successful installs, and the closing line Installation of all drivers from Windows Update was successful. Re-running the evaluation script returns exit 0 with No driver updates available, because the Type='Driver' and IsInstalled=0 query now returns an empty collection. Pending reboots surface in the Automox console as Needs Reboot, so you can target a restart Worklet at exactly the endpoints that need one rather than rebooting the whole policy group.

Validate from PowerShell on a sample endpoint with Get-WindowsUpdateLog (the cmdlet that converts WindowsUpdate.etl into a readable log) and look for the AGENT block listing each driver install with result code 0x00000000. Cross-check Device Manager (devmgmt.msc) for the affected hardware classes; the Driver tab should show the new driver date and version. For audit evidence, export the Automox activity log alongside the registry value HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired and store both with the policy run ID. The Worklet is idempotent: subsequent runs detect the empty pending-driver set and exit clean, holding the configuration in place without reinstalling anything.