Deploy MSP Based KB

What the Microsoft KB MSP deployer does

This Automox Worklet™ installs a Microsoft KB security patch that ships as a Windows Installer Patch (.msp) file. You upload the vendor-supplied MSP to the Automox policy, set the KB identifier the patch will register under, and the Worklet handles detection, installation, and post-install verification on every targeted Windows endpoint.

The Worklet opens both the 64-bit and 32-bit Windows registry views under Software\Microsoft\Windows\CurrentVersion\Uninstall and scans every subkey for a DisplayName that matches the configured KB (for example, KB5000871). On 64-bit Windows it queries the native Registry64 hive and the Wow6432Node Registry32 hive, so patches that register under either architecture are detected the same way Programs and Features would see them.

When the KB is missing, the Worklet calls msiexec.exe /update against the uploaded MSP with /qn for a silent install and /norestart so a server is never rebooted unexpectedly. A verbose installer log is written next to the MSP file (the .log extension is appended automatically) so failed installs leave a usable trace. After msiexec exits, the registry sweep runs a second time to confirm the KB now appears in the uninstall keys, which is what determines the Worklet's exit code.

Two policy variables drive the run: $kb is the KB identifier (case insensitive, include the "KB" prefix) and $mspFile is the filename of the uploaded .msp. The Worklet resolves the MSP path from the script's own directory using Split-Path, so you never hand-edit absolute paths. The companion software – Exchange Server, SharePoint, Microsoft Office, Visual Studio, or another Microsoft product the vendor ships .msp patches for – must already be installed on the endpoint; MSP files patch existing installations, they do not create them.

Why patch Microsoft KBs out-of-band with MSP files

Microsoft ships urgent out-of-band patches for Exchange Server, SharePoint, and on-premises server products as MSP packages that never enter the standard Windows Update channel. The ProxyLogon Exchange chain (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065), the ProxyShell follow-on (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207), and recurring SharePoint deserialization patches all landed first as vendor MSPs. WSUS and SCCM admins routinely need 24 to 72 hours to ingest, approve, pilot, and roll out one of these patches, and active exploitation is typically observed inside that window. Manual MSP rollout across more than a handful of servers turns into a spreadsheet of hostnames, RDP sessions, and verification calls that does not finish before the next ring is due.

This Worklet collapses that timeline. You upload the vendor .msp file, set the KB number in the script, and target the relevant server group; the same msiexec /update /qn /norestart install then runs against every Exchange, SharePoint, or RDS host in scope on its next check-in. Each remediation re-scans the uninstall registry hives for the configured KB and only reports success when a matching DisplayName appears, so the activity log produces audit-ready evidence per host. For CVE-coded patches such as the ProxyLogon and ProxyShell series, that telemetry lines up with the SOC's compensating-control window and shortens the exposure interval against the underlying remote code execution chain.

How Microsoft KB MSP deployment works

1. Evaluation phase: The Worklet opens Software\Microsoft\Windows\CurrentVersion\Uninstall in both Registry64 and Registry32 views (on 32-bit Windows only the Registry32 view is opened), enumerates every subkey, and reads the DisplayName value. If any DisplayName contains the configured KB string (matched with -like "*$kb*", case insensitive), the endpoint exits 0 with the message "$kb found. No remediation required." If neither view contains the KB, the endpoint exits 1 with "$kb Not found. Flagging for remediation" and Automox schedules the remediation script.

2. Remediation phase: The remediation script resolves the MSP path with Split-Path $Script:MyInvocation.MyCommand.Path -Parent, then runs Start-Process msiexec.exe -ArgumentList "/update <path>\<file>.msp /qn /norestart /l*v <path>\<file>.msp.log" -Wait -PassThru. The /update flag is what tells Windows Installer to apply an MSP against an existing product, /qn suppresses UI, /norestart prevents an automatic reboot of production servers, and /l*v writes a verbose installer log beside the MSP. Any msiexec exception is caught and the Worklet exits 1 with a pointer to the log. On success, the same registry sweep from the evaluation phase runs again; if the KB now appears, the Worklet exits 0 with "$kb Installation Successful", otherwise it exits 1 and references the log for triage.

Microsoft KB MSP deployment requirements

• Windows 7, Windows Server 2008 R2, or newer (workstation and server SKUs both supported; same script path runs on 32-bit and 64-bit Windows)

• Administrator context for the Automox agent so msiexec can write to HKLM and the product install directory (the default agent context already satisfies this)

• The target Microsoft product already installed on the endpoint – Exchange Server, SharePoint, Office, Visual Studio, SQL Server, or another product whose patches Microsoft ships as .msp

• The vendor-supplied .msp file uploaded to the policy via the Upload File button in the Automox console (one MSP per policy)

• $kb set in both evaluation.ps1 and remediation.ps1 to the KB identifier the patch registers under (include the KB prefix, for example KB5000871)

• $mspFile set in remediation.ps1 to the exact filename of the uploaded patch, including the .msp extension (for example Exchange2019-KB5000871-x64-en.msp); pathing is resolved automatically

• Sufficient free disk space for the installer to stage the patch and write the verbose log file (Microsoft server patches commonly need several hundred megabytes of working space)

Expected state after Microsoft KB MSP installation

The configured KB appears as an installed update in Windows. You can read it back from the registry with Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" | Where-Object { $_.DisplayName -like "*KB5000871*" }, swapping in the relevant KB string, and on 64-bit Windows you can also query "HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" for patches that register under the 32-bit view. Programs and Features (appwiz.cpl) shows the same entry under Installed Updates, and Get-HotFix surfaces it when the vendor packages the patch as a hotfix record (not every MSP does). The Worklet itself returns exit code 0 and the activity log records "$kb Installation Successful" so the policy run shows green in the console.

If the install fails, the verbose log beside the MSP (for example C:\Program Files (x86)\Automox\axhandler\<run-id>\Exchange2019-KB5000871-x64-en.msp.log) captures the msiexec output and is the first place to look. Common failures: the target product is not installed (msiexec returns 1642 "This patch package could not be opened"), the MSP is the wrong architecture for the installed product, or a previous patch dependency is missing. Microsoft server patches frequently require a reboot to finish loading patched binaries even when msiexec returns success; the Worklet deliberately suppresses the automatic reboot to keep production hosts available, so plan a separate reboot policy for the patch ring once verification is complete.