Windows Server update failure evidence-first runbook

Good For

• one Windows Server fails a cumulative update

• WSUS or Azure Update Manager troubleshooting

• servicing-stack and component-store failures

• proxy and Windows Update network-path validation

• production patch incident evidence

How to Use It

1. Capture the exact KB, error code, install phase, update source, and whether the same update repeatedly fails.

2. Select a known-good Windows Server peer with comparable OS/build, update source, policy, and network path that successfully installed the same update.

3. Compare pending reboot state, free disk, component-store health, update-service state, policy, and installed/build evidence between failing and known-good servers.

4. Validate WinHTTP proxy configuration and the network path to the actual update source such as WSUS/SUP, Microsoft Update, or Azure Update Manager prerequisites.

5. Confirm update applicability for the current build, architecture, servicing state, and supersedence chain.

6. Preserve Windows Update Client events plus relevant CBS.log and DISM.log timestamps before repair.

7. Run read-only DISM CheckHealth/ScanHealth before state-changing repair; do not begin by deleting SoftwareDistribution or clearing caches.

8. Under an approved maintenance window, perform the least-invasive repair justified by the evidence.

9. Retry the same update through the same intended source and compare the result with the known-good peer.

10. If the failure persists, retain and escalate the evidence rather than chaining destructive resets without a new hypothesis.

Execution Modes

• local
• remote-single-host

Inputs and Outputs

Inputs

• failing Windows Server
• known-good patched Windows Server
• failed KB and error code
• intended update source
• maintenance window
• change or incident record

Outputs

• verbose-console
• operator-notes
• log-file

Command Starter

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15
Get-PSDrive -PSProvider FileSystem
Get-Service wuauserv,bits,cryptsvc,TrustedInstaller
netsh winhttp show proxy

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WindowsUpdateClient'} -MaxEvents 50 -ErrorAction SilentlyContinue
# Approved maintenance-window repair examples; not part of the evidence pass.

Validation

• The failing server is compared against a known-good successfully patched peer.

• Pending reboot, disk, services, policy, applicability, component store, WinHTTP proxy, update-source reachability, and servicing logs are covered.

• Read-only diagnostics precede state-changing repair.

• The same update is retried after remediation and final install/build evidence is recorded.

• Before/after evidence explains what changed and whether it resolved the failure.

Reporting

• Attach failed KB/error, peer comparison, proxy/update-source checks, and servicing-log timestamps to the incident.

• Record every state-changing remediation separately from evidence collection.

• Close only after the same update succeeds or a documented exception/escalation is approved.

Safety Notes

• DISM RestoreHealth and SFC can change system state; use them only under an approved maintenance/change context.

• Do not delete SoftwareDistribution, catroot2, or servicing state as a first response.

• Preserve logs before resets or service changes so the original failure remains explainable.

• If an approved repair worsens service health or the update path, stop and use the change's documented restore or rollback path rather than stacking additional repairs.