Get Windows Update Events

What the Windows Update event auditor does

This Automox Worklet™ collects Windows Update and System event entries from each endpoint and writes the filtered results to the Automox Activity Log. The Worklet calls Get-WinEvent against the System and Application logs, filters by a configurable list of event IDs, and applies a lookback window in days so the output stays focused on the most recent patch cycle.

The default $systemEventIDs array is 12, 13, 19, 21, 43, 1074, 1040, 1033. Those IDs cover service-control, Windows Update Client, and shutdown lifecycle: service start (12) and stop (13), update installation success (19), update reboot required (21), update installation started (43), planned shutdown initiation (1074), and MSI installer activity (1040, 1033). The combined set surfaces unexpected reboots and installer events alongside the Windows Update entries, which helps you correlate a failed update with a service restart or a forced reboot inside the same time window. Common alternate IDs to add when troubleshooting include 20 (installation failure), 25 (restart pending), 31 (scan failure), and 44 (download started).

Because the evaluation script always flags for remediation, the Worklet behaves as an on-demand audit job. Schedule it to run after Patch Tuesday, after a known-bad KB withdrawal, or on an ad-hoc basis from FixNow when a single endpoint is misbehaving. The output is the raw TimeCreated, Id, and Message fields from each event, so downstream parsing in a SIEM or spreadsheet stays straightforward.

Why audit Windows Update event logs across managed endpoints

Windows Update Client failures are quiet by default. A patch that needs a reboot writes Event ID 21 or System Event ID 1074 to the System log, and the endpoint sits on a half-applied update until someone restarts it. Scan-time failures land separately as Event ID 31 in the Microsoft-Windows-WindowsUpdateClient/Operational channel, which only surfaces through a manual Event Viewer walk on every machine: Applications and Services Logs > WindowsUpdateClient > Operational, then scroll. Across hundreds of endpoints, that approach turns into a backlog. The same evidence is what auditors ask for under PCI-DSS 6.3.3, CIS Control 7, and NIST 800-53 SI-2 when they want proof of patching cadence.

Windows Update failures rarely surface as a single visible error. They show up as Event ID 19, 20, 31, or 43 entries in the WindowsUpdateClient log on individual endpoints, and the standard answer is to RDP into each host and run Get-WinEvent by hand. This Worklet runs Get-WinEvent against the WindowsUpdateClient channel on every endpoint in scope and surfaces the same parseable output into the Automox Activity Log, where you can search, sort, and export it without RDP, WinRM, or a separate log-shipping agent.

How Windows Update event retrieval works

1. Evaluation phase: The evaluation script exits with code 1 to flag every endpoint for remediation, because the Worklet is a read-only audit job and the value is in collecting the events on each run. There is no idempotency check; the script is intentionally a one-shot collector that you point at the time window you care about.

2. Remediation phase: The remediation script builds a TimeSpan from the configured $daysOflogs value and the current Get-Date, then calls Get-WinEvent -FilterHashtable @{logname = 'System','Application'}. The result is filtered by the $systemEventIDs array (default 12, 13, 19, 21, 43, 1074, 1040, 1033) and any TimeCreated newer than the lookback window. Output is formatted with Format-Table TimeCreated, Id, Message -Wrap and written to stdout, which the Automox agent forwards to the Activity Log. The script exits 0 on success.

Windows Update event retrieval requirements

• Windows 7 or later, Windows Server 2008 R2 or later. Workstation and Server SKUs are both supported by the source metadata.

• PowerShell 2.0 or later. Get-WinEvent is part of the in-box PowerShell on every supported Windows release.

• The Automox agent runs as SYSTEM, which already has Read access to the System log, the Application log, and the Microsoft-Windows-WindowsUpdateClient/Operational channel. No additional permissions are required to query the default IDs from the System and Application logs.

• Set $systemEventIDs in remediation.ps1 to the comma-separated list of event IDs you want returned. The script queries the System and Application logs and ships with a default of 12, 13, 19, 21, 43, 1074, 1040, 1033. Add 20 (installation failure), 25 (restart pending), 31 (scan failure), 41 (unexpected shutdown), or 44 (download started) when you need a broader view; the Worklet will return any of those IDs that appear in the System or Application logs within the lookback window.

• Set $daysOflogs to the lookback window in days. The default of 1 returns the last 24 hours; raise it to 7 or 30 when you are gathering audit evidence across a patch cycle.

• Endpoints with aggressive log rotation may not retain WU events beyond the default 20 MB cap on each channel. If your audit window is longer than the local retention, plan to run the Worklet more frequently or raise the maximum log size with wevtutil sl Microsoft-Windows-WindowsUpdateClient/Operational /ms:104857600.

Expected state after the audit runs

The Automox Activity Log for each endpoint shows a Format-Table block with three columns: TimeCreated, Id, and Message. A clean patch cycle returns rows similar to 2026-05-15 03:14:08, 43, Installation Started: Windows has started installing the following update: Cumulative Update for Windows 11 (KB5037771), followed by 2026-05-15 03:18:42, 19, Installation Successful, and 2026-05-15 03:18:43, 25, Restart Required. A failed cycle returns Event ID 20 with the wuauclt error code in the Message field, which you can decode against the Windows Update error reference.

To verify the Worklet against the raw source on an endpoint, run Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50 in an elevated PowerShell session. Compare the timestamps and IDs to the Worklet output for the same window. For a longer historical view, run Get-WindowsUpdateLog to merge the ETW traces under %SystemRoot%\Logs\WindowsUpdate into a readable %SystemRoot%\WindowsUpdate.log on the desktop, then grep for the KB you care about. On Windows 7 and 8.1 the legacy %SystemRoot%\WindowsUpdate.log is written directly without the Get-WindowsUpdateLog conversion step.

Pair this Worklet with a Worklet that resets the Windows Update components or revokes a problematic KB when the audit surfaces a recurring Event ID 20 or 31. The audit Worklet identifies the affected endpoints, the remediation Worklet acts on them, and the two together close the loop between detection and fix on the same policy cadence as the rest of your patch program.