Windows - Configuration - Install Out-Of-Band Patch (MSU)

What the out-of-band patch deployer does

This Automox Worklet™ deploys out-of-band Microsoft Update Standalone (MSU) patches to Windows endpoints without waiting for the next Patch Tuesday window. You set the target KB identifier and MSU download URL directly in the Worklet scripts (the $kb and $UpdateURL variables), and the Worklet checks each endpoint with Get-HotFix, downloads the MSU file to a staging directory under C:\Temp\UpdateStaging\, and hands the file to wusa.exe for silent installation. Endpoints that already report the KB through Get-HotFix are skipped, so the policy is safe to re-run on the same group.

Out-of-band releases are Microsoft's response to actively exploited zero-day vulnerabilities, kernel privilege escalations, and patches that misbehaved in the previous monthly rollup. The Worklet covers the moment between the KB article going live on the Microsoft Update Catalog and the next scheduled patch cycle picking it up. Point it at a specific KB number, target the affected Windows builds, and wusa.exe lands the MSU before the next Patch Tuesday cycle catches up.

The script targets MSU-format patches specifically. CAB and EXE-formatted updates need a different deployment path, because wusa.exe only accepts .msu input. The Worklet supports Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022, and Windows Server 2025 endpoints. Both workstation SKUs and Server Core installs are in scope, because wusa.exe ships on every supported Windows release.

Why patch zero-day Windows vulnerabilities out of band

Out-of-band KB releases land because the bug under remediation is being exploited in the wild. Recent examples include kernel-mode driver elevation-of-privilege CVEs, Print Spooler remote code execution chains, and Outlook NTLM hash leakage. The window between Microsoft posting the MSU on the Update Catalog and the fleet picking it up through the regular WSUS or Intune cycle is the exact window attackers target. Running the manual wusa.exe /quiet /norestart command across a fleet through RDP or PowerShell remoting does not scale past a handful of servers, and it leaves no audit trail.

Target the Windows workstation and server groups in scope for the advisory, and the wusa.exe install lands on every endpoint once Microsoft publishes the MSU. Workstations and Windows Server endpoints run through the same policy, and each result is logged in the Automox activity stream as audit evidence. Remediation speed stops depending on operator availability for ad-hoc RDP sessions.

How out-of-band MSU patching works

1. Evaluation phase: The Worklet reads the target KB identifier from the $kb variable defined at the top of evaluation.ps1, then runs Get-HotFix -Id $kb against the endpoint. If Get-HotFix returns a matching record, the evaluation exits 0 and the endpoint is treated as compliant. If the cmdlet returns no rows, the evaluation exits 1 and remediation is scheduled. The evaluation pass is read-only, so a recurring policy can sit alongside the patch policy without operational impact.

2. Remediation phase: The Worklet creates C:\Temp\UpdateStaging\ if it does not already exist, sets [Net.ServicePointManager]::SecurityProtocol to Tls12, and uses System.Net.WebClient.DownloadFile to pull the MSU from the URL set in $UpdateURL. The script then invokes wusa.exe <path-to-msu> /quiet /norestart and waits for the process to exit. C:\Temp\UpdateStaging\ is removed recursively, and Get-HotFix -Id $kb is queried one more time. If the KB now resolves, the Worklet exits 0; otherwise it exits 1 so the failure surfaces in Automox activity logs.

Out-of-band patch deployment requirements

• Windows 10, Windows 11, or Windows Server 2016 / 2019 / 2022 / 2025 endpoint with PowerShell 5.1 or later and wusa.exe available (default on all supported Windows builds)

• Administrator context for the Automox agent so wusa.exe can write into the component store and register the hotfix with the Trusted Installer service

• Outbound HTTPS reachability from the endpoint to catalog.update.microsoft.com (or to an internal mirror that stages the MSU file)

• TLS 1.2 enabled in the .NET ServicePointManager; the remediation script forces this for the download even when the Windows default is older

• The KB identifier (for example KB5028166) and the matching MSU download URL set in the $kb and $UpdateURL variables in both evaluation.ps1 and remediation.ps1 before deploying the Worklet

• MSU-format file; CAB updates need DISM /Online /Add-Package and EXE updates need their own installer wrapper, so neither path is in scope for this Worklet

• Free disk space on the C: volume sufficient to stage the MSU (cumulative updates can exceed 1.5 GB) plus the temporary expansion footprint wusa.exe writes during install

Expected endpoint state after MSU installation

After a successful remediation, Get-HotFix -Id KBxxxxxxx returns a row with the install date, source name, and HotFixID matching the deployed patch. The same KB appears under Settings → Windows Update → Update history, and wmic qfe list brief lists it alongside earlier cumulative updates. wusa.exe records exit code 0x0 in the Setup event log under Microsoft-Windows-WUSA, and CBS.log under C:\Windows\Logs\CBS\ captures the component store transaction for forensics. Some KB articles require a reboot to fully activate the kernel or driver changes; the Worklet runs with /norestart so the timing stays with the admin, but Restart-Computer can be chained from a follow-up Worklet or the policy's native reboot option.

If the install fails, the Worklet exits non-zero and the wusa.exe return code surfaces in Automox activity logs. Common failure modes are 0x80240017 (update not applicable to this OS build), 0x80070643 (a previous install left a pending operation), and 0x800f0922 (component store corruption that needs DISM /Online /Cleanup-Image /RestoreHealth before retry). Validate compliance fleet-wide by re-running the evaluation phase or by querying Get-HotFix across the policy group from the Automox console; both views feed the same audit evidence that CIS Critical Security Controls 7.3 and NIST 800-53 SI-2 expect for timely patch deployment.