Windows Update readiness and repair evidence pack

A patch readiness and repair evidence pack for reboot state, servicing health, update logs, and approved repair actions.

Good For

  • patch readiness
  • Windows Update failures
  • maintenance windows
  • server health evidence
  • repair validation

How to Use It

  1. Capture read-only service state, pending reboot signals, update history, and recent Windows Update events first.
  2. Run `DISM /ScanHealth` before repair commands so the starting servicing state is documented.
  3. Confirm a maintenance window, backup posture, and rollback owner before running `DISM /RestoreHealth` or `sfc /scannow`.
  4. Run repair commands one host or pilot group at a time and save console output.
  5. Reboot only when approved and when application owners understand the impact.
  6. After repair, rerun update scan and capture logs that prove whether the original error changed.

Execution Modes

  • local
  • remote-single-host

Inputs and Outputs

Inputs

  • computer name
  • KB number
  • error code
  • maintenance window
  • backup or restore owner

Outputs

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

Command Starter

Changes system state: review before running

Get-Service wuauserv,bits,cryptsvc,TrustedInstaller | Select-Object Name, Status, StartType
Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 80 | Select-Object TimeCreated, Id, LevelDisplayName, Message
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Validation

  • Starting service, reboot, update, and servicing state is captured.
  • Repair output completes without unresolved corruption or records the exact failure code.
  • The target update scan or install can be attempted again with new evidence.

Reporting

  • attach before and after servicing evidence to patch tickets
  • record DISM, SFC, reboot, and update scan results
  • promote repeated use into a patch readiness report

Safety Notes

  • Repair commands can change component store and protected system files.
  • Do not run repair or reboot steps outside an approved maintenance window.
  • Keep before-state logs and backup or restore notes with the ticket.