InvokeSystems.UpdateRepair: The Dance Everyone Knows

(but nobody wants to perform manually)

Windows Update fails. Not occasionally. Regularly. Predictably. Error 0x80070002. Error 0x800f0922. The cryptic codes that mean “something is broken and you’re about to spend the next hour fixing it.”

Every Windows administrator knows the fix. Stop the update services. Clear the SoftwareDistribution cache. Clear the catroot2 cache. Reset BITS. Run DISM. Run SFC. Restart the services. Trigger a new scan. Hope it works this time.

This isn’t secret knowledge. Microsoft publishes the steps. Third-party scripts and tools automate them. Enterprise patch management vendors build this remediation into their products.

The problem is doing it consistently. Manually executing the steps is tedious and error-prone. Pre-existing scripts often have dependencies on external tools, assume specific directory structures, or fail silently when steps don’t complete.

InvokeSystems.UpdateRepair is the systematized version of the manual dance. Seven phases, deterministic execution, clear logging, no external dependencies, idempotent by design.

What It Does

The module performs the Windows Update remediation sequence in seven phases:

Phase 1: Stop Update Services Stops wuauserv, bits, cryptsvc, and msiserver in dependency order. Services that are already stopped are skipped. Hung services are handled gracefully rather than causing the entire process to stall.

Phase 2: Clear Update Caches Removes the contents of %SystemRoot%\SoftwareDistribution and %SystemRoot%\System32\catroot2. These directories hold cached update metadata and cryptographic catalogs that frequently become corrupted. Clearing them forces Windows Update to rebuild from scratch.

Phase 3: Reset BITS Jobs Cancels all Background Intelligent Transfer Service jobs for all users. Stuck BITS transfers often block new updates. Resetting them clears the queue.

Phase 4: DISM RestoreHealth Runs DISM /Online /Cleanup-Image /RestoreHealth to repair the Windows component store. This fixes corrupted system files that prevent updates from installing. It’s slow (5-30 minutes depending on system state) but necessary for deep remediation.

Phase 5: SFC VerifyOnly Runs SFC /VerifyOnly to check system file integrity without making changes. The verification results are logged. This doesn’t fix corruption but confirms whether DISM succeeded and whether further investigation is needed.

Phase 6: Restart Services Restarts the update services in reverse order: msiserver, cryptsvc, bits, wuauserv. Services that fail to start are logged but don’t abort the entire process.

Phase 7: Trigger Update Scan Runs UsoClient StartScan to initiate update detection. If UsoClient is unavailable (Windows 10 before version 1703), it falls back to wuauclt /resetauthorization /detectnow.

Each phase logs its actions verbosely. Success, failure, and warnings are recorded both to console output (respecting -Verbose) and to log files on disk.

Why These Seven Phases

The sequence is based on Microsoft’s published troubleshooting guidance and field experience across thousands of remediation attempts. Stopping services before clearing caches prevents file locks. Clearing caches before running DISM prevents the tool from using corrupted local sources. Running SFC after DISM validates the repairs. Restarting services and triggering a scan ensures the update system is functional before declaring success.

Alternative approaches exist. Some scripts skip DISM and SFC because they’re slow. Some clear additional cache directories. Some attempt in-place repairs with setup media. Those approaches trade speed for thoroughness or add dependencies on external tools.

InvokeSystems.UpdateRepair favors thoroughness and self-containment. DISM and SFC are slow but effective and don’t require external binaries. They’re included by default with the option to skip them via -SkipDism and -SkipSfc if time is critical.

Idempotency and Safety

The module is designed to be safe for repeated execution. Services already stopped are skipped. Empty cache directories don’t cause errors. BITS job cancellation handles missing jobs gracefully. Services already running are skipped during restart.

This means you can run Invoke-InvUpdateRepair multiple times without side effects. If the first run fails partway through, rerunning it picks up where it left off without duplicating successful steps.

Idempotency matters for automation. Scheduled tasks, configuration management tools, and monitoring systems need to invoke remediation without worrying about partial completion causing inconsistent state.

The module doesn’t make irreversible changes. It doesn’t uninstall updates, modify registry keys outside the update subsystem, or alter security settings. The most destructive action is deleting cache directories, which Windows Update recreates automatically.

Logging and Observability

Every operation is logged to %ProgramData%\InvokeSystems\UpdateRepair\ by default. The main log (UpdateRepair.log) records phase execution, errors, and warnings. DISM and SFC output is captured separately (dism_stdout.log, dism_stderr.log, sfc_stdout.log, sfc_stderr.log) for detailed review.

When -EnableEventLog is specified, the module writes events to the Windows Application event log with source InvokeSystems-UpdateRepair. Event IDs correspond to severity: 1000/1001 for info and success, 2000 for warnings, 3000 for errors.

This supports both interactive troubleshooting (reviewing logs directly) and automated monitoring (querying event logs or parsing log files).

The output object returned by Invoke-InvUpdateRepair includes success status, exit code, per-phase results, timing information, and log file paths. Scripts invoking the module can inspect this object to determine whether remediation succeeded and which phases failed.

Exit Codes and Automation

The module returns structured exit codes for scripted invocation:

  • 0: Success - all phases completed without errors
  • 1: Partial remediation - some phases failed but critical steps succeeded
  • 2: Fatal failure - critical steps failed, manual intervention required

Scheduled tasks can use the exit code to determine whether to retry, escalate, or proceed. Configuration management tools can treat exit code 0 as success and 2 as a failure requiring notification.

This allows remediation to integrate into broader automation workflows without requiring bespoke error handling for every phase.

What This Doesn’t Do

InvokeSystems.UpdateRepair doesn’t replace comprehensive Windows Update troubleshooting. If the remediation sequence doesn’t fix the problem, deeper investigation is required: inspecting WindowsUpdate.log, reviewing CBS logs, checking for driver conflicts, verifying disk space and file system integrity.

It doesn’t install updates. It repairs the update infrastructure so Windows Update can install updates. After running the module, you still need to check for and install pending updates through Windows Update or your patch management system.

It doesn’t handle scenarios that require external media: in-place upgrade repairs, offline servicing, or restoring component store from installation media. Those scenarios are beyond the scope of automated remediation.

It doesn’t provide per-update troubleshooting. If a specific update fails repeatedly due to a known bug or compatibility issue, excluding that update or applying a hotfix is a separate problem. This module fixes the infrastructure, not individual update failures.

Comparison to Enterprise Tools

Enterprise patch management solutions (SCCM, Intune, third-party vendors) often include prerequisite remediation or update health checks that perform similar functions. Those tools have advantages: integration with the broader patch management workflow, centralized reporting, support contracts.

InvokeSystems.UpdateRepair fills a different niche. It’s a standalone PowerShell module with no licensing cost, no server infrastructure, and no dependencies beyond Windows itself. It runs on workstations and servers that aren’t managed by enterprise tools. It provides a standardized remediation script for help desk teams and field technicians.

It achieves approximately 80-90% of what enterprise prerequisite handlers do without native binaries or external dependencies. That’s sufficient for most environments. For complex scenarios requiring advanced diagnostics or automated remediation orchestration, enterprise tools provide more capability at higher cost and complexity.

Scheduled Remediation

For proactive maintenance, deploy the module as a scheduled task:

$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument @"
-NoProfile -ExecutionPolicy Bypass -Command "Import-Module InvokeSystems.UpdateRepair; `$result = Invoke-InvUpdateRepair -EnableEventLog; exit `$result.ExitCode"
"@

$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At '02:00'
$principal = New-ScheduledTaskPrincipal -UserId 'SYSTEM' -LogonType ServiceAccount -RunLevel Highest

Register-ScheduledTask -TaskName 'Windows Update Remediation' -Action $action -Trigger $trigger -Principal $principal

This runs remediation weekly during maintenance windows. Event logs and exit codes provide visibility into execution success. Adjust frequency based on update failure rates and environment size.

Weekly remediation is conservative. Some environments run this daily. Others only trigger it on-demand after detecting update failures through monitoring. The module supports both patterns.

Tradeoffs and Limitations

DISM and SFC are slow, especially on systems with significant corruption or on Windows Server with large component stores. A full remediation can take 30-60 minutes. The -SkipDism and -SkipSfc flags allow faster execution when time is critical, but thoroughness suffers.

Clearing SoftwareDistribution forces Windows Update to re-download update metadata. On metered connections or bandwidth-constrained environments, this has cost implications. The module doesn’t check for metered connections before clearing caches.

The module requires administrator privileges and typically runs as SYSTEM. Running it in a user context fails at the first privilege-requiring step (stopping services). This is expected but means interactive execution requires an elevated PowerShell session.

Event log initialization requires admin privileges. If the module can’t create the event source, event logging is disabled with a warning. Remediation continues, but you lose event log integration.

Why This Exists

The manual remediation dance works, but it’s tedious, error-prone, and inconsistently applied. Some technicians skip steps. Some use outdated procedures. Some follow different troubleshooting guides.

Automating the sequence ensures consistency. Every remediation attempt follows the same steps in the same order. Logging provides evidence of what was attempted. Exit codes allow automation to react appropriately.

The module also serves as documentation. The seven phases are clearly delineated. Each phase is self-contained. Reviewing the code shows exactly what remediation entails without parsing Microsoft KB articles.

This isn’t groundbreaking engineering. It’s codifying institutional knowledge and making it repeatable.

Where This Fits

Use InvokeSystems.UpdateRepair for reactive troubleshooting when Windows Update fails. Run it manually in elevated sessions or through remote PowerShell. Use it as a scheduled task for proactive remediation. Integrate it into monitoring systems to automatically remediate detected failures.

Pair it with InvokeSystems.RestrictedTask to let help desk technicians trigger remediation without granting full admin rights. Pair it with monitoring that detects update failures and automatically initiates remediation before users report issues.

Don’t use it as a substitute for understanding why updates are failing repeatedly. Remediation fixes symptoms. Root cause analysis fixes problems. Both matter.

The Real Point

Windows Update breaks often enough that the fix is muscle memory. Automating muscle memory makes sense. Especially when the automation can log, report, integrate with other systems, and execute consistently across thousands of machines.

InvokeSystems.UpdateRepair doesn’t solve the fundamental problem: Windows Update is fragile and fails regularly. Microsoft owns that problem. This module makes the consequences less painful.

That’s the entire value proposition: reducing the operational cost of a problem you can’t eliminate.

The module is boring, mechanical, and deterministic. For remediation infrastructure, that’s exactly right.