Windows 11 24H2 KB5063878: WSUS Delivery Failure and KIR Rollback

Microsoft and community reports confirm that the August 12, 2025 cumulative update for Windows 11, version 24H2 (KB5063878, OS build 26100.4946) experienced delivery failures when distributed through on‑premises update infrastructure—principally Windows Server Update Services (WSUS) and SCCM/MECM—causing clients to error out with 0x80240069 and related symptoms; Microsoft published a Known Issue Rollback (KIR) and re‑released the package for WSUS to remediate the issue, and administrators must resynchronize and, where appropriate, deploy the KIR or use targeted workarounds to recover managed fleets. (learn.microsoft.com) (support.microsoft.com)

---

Background / Overview​

Windows servicing continues to evolve: Microsoft frequently ships combined Servicing Stack Updates (SSU) and Latest Cumulative Updates (LCU) as single packages to minimize dependency errors and installation order problems. The August 12, 2025 rollup, KB5063878, followed that model and included both servicing‑stack changes and cumulative fixes for Windows 11 24H2. Soon after publication, enterprise administrators began reporting a consistent failure pattern when distribution was handled via on‑premises channels. (support.microsoft.com)
The observable symptoms reported across multiple administrators and community trackers were remarkably consistent:

• Update attempts delivered via WSUS/SCCM would abort or show “Download error” with an install error code 0x80240069 as visible in Software Center, WSUS, or Windows Update logs.
• Event Viewer often recorded an entry such as “Unexpected HRESULT while download in progress: 0x80240069 WUAHandler”, sometimes accompanied by the Windows Update host (wuauserv) crashing (svchost.exe_wuauserv) and faulting module references to ntdll.dll.
• Many endpoints that failed when pulling the update from WSUS succeeded when the identical package was downloaded manually from the Microsoft Update Catalog or when clients contacted Microsoft Update directly—pointing to a delivery‑channel specific problem rather than universal corruption of the update payload.

Microsoft acknowledged the problem on its Release Health/Support pages and marked the WSUS delivery issue as resolved after deploying mitigations and reissuing a corrected WSUS distribution; administrators were advised to refresh and resynchronize WSUS catalogs to obtain the corrected package. (learn.microsoft.com)

---

What BornCity reported — concise summary​

The German blog BornCity (Born’s IT and Windows Blog) covered the incident in multiple posts: the initial reporting of the 0x80240069 failure for KB5063878, the announcement that Microsoft provided a KIR mitigation for managed environments, and the follow‑up that Microsoft re‑released the update for WSUS on August 14, 2025. BornCity’s coverage emphasized that the issue primarily affected WSUS‑mediated deployments and noted community feedback confirming the re‑release and practical remediation steps. (borncity.com)
That reporting aligns with Microsoft’s own Release Health notes and with broader community troubleshooting: BornCity documented the KIR artifact availability, the need to re‑sync WSUS, and recommended alternative paths such as manual installation from the Catalog where immediate remediation was necessary. (borncity.com)

---

Technical analysis: why WSUS deployments were singled out​

The enterprise delivery path diverges from consumer update flows​

WSUS and System Center introduce an approval and metadata negotiation path that consumer clients do not exercise. When an update carries variant payloads, feature gating, or conditional components (for example, selective AI component updates or optional servicing‑stack variants), the enterprise delivery stack exercises code paths that touch metadata and variant selection logic more heavily. If there’s a defect in that negotiation layer, it can manifest only—or most severely—on managed endpoints. This delivery‑channel divergence is the most plausible root cause of the KB5063878 failures.

Failure fingerprint suggests a handler/negotiation regression​

The recurring Event Viewer string (“Unexpected HRESULT while download in progress: 0x80240069 WUAHandler”) and the documented crashes of the wuauserv host indicate the bug triggered during the download/handler phase of the Windows Update Agent process. Crash traces referencing ntdll.dll and exception codes such as 0xc0000005 imply an access violation or memory safety fault within the path exercised by WSUS/SCCM delivery—again consistent with a metadata/variant-handling regression rather than a corrupt binary payload.

Interaction effects with combined SSU+LCU packages​

Combined SSU + LCU deliveries reduce installation complexity for the majority of customers, but they also enlarge the surface where a regression can interact with the servicing stack. When the LCU introduces a subtle behavioral change and the SSU binds that change into the installation path, a problematic interaction may appear only when enterprise metadata handling triggers a particular variant—making reproduction dependent on delivery topology. That pattern is repeated across similar incidents earlier in the same year.

---

Mitigations and practical workarounds​

Microsoft and the community provided a small catalogue of mitigations—some more suitable for large enterprises, others intended for small shops or single‑host recovery.

• Known Issue Rollback (KIR)
  • Microsoft published a KIR artifact (GPO/ADMX/MSI) that flips back the problematic behavior without uninstalling the cumulative update. This is the recommended containment path for managed environments because it is centrally deployable, auditable, and reversible. (learn.microsoft.com)
• Re‑synchronize WSUS catalogs
  • Once Microsoft corrected the server‑side distribution, administrators were instructed to refresh and re‑sync WSUS so downstream clients would obtain the re‑released package. In many cases this action caused previously failing clients to recover.
• Manual installation (Catalog / MSU)
  • For high‑priority hosts, bypass WSUS and install the package directly from the Microsoft Update Catalog (or download the MSU/CAB and apply with DISM/WUSA). The consumer delivery path avoids the enterprise negotiation code paths that triggered the failure.
• Copy .msu locally when using WUSA
  • Installing an .msu from a network share—especially if multiple .msu files are present—was implicated in a separate but related ERROR_BAD_PATHNAME symptom. Copying the .msu locally and installing from a local path reliably avoided that failure.
• Temporary registry / policy overrides
  • Community‑documented registry edits and PowerShell feature‑flag overrides were circulating as stopgap measures where KIR deployment was not feasible; these should be used cautiously and only with appropriate testing because they alter runtime feature gating.

Administrators must weigh the trade‑offs: KIR is safer at scale than registry hacks; manual installs mitigate individual cases but do not scale; and resynchronization is low‑risk and should be performed as soon as Microsoft confirms the re‑release. (learn.microsoft.com)

---

Operational impact and risks for enterprise IT​

Immediate operational costs​

• Patch compliance and audit gaps: failing WSUS installs can leave management consoles showing non‑compliant states while devices may actually be patched via alternate means—this creates audit noise and complicates reporting.
• Increased helpdesk load: manual remediations (copying MSUs, local installs, targeted KIR rollouts) require time and coordination across reboot windows.
• Monitoring and false positives: residual “restart required” indications or repeated errors in centralized logging can mask real incidents, increasing triage time for administrators.

Strategic and security risks​

• Recurring regressions: the same 0x80240069 syndrome had appeared earlier in the year for a different update, demonstrating the operational risk of regressions reappearing when servicing pipelines change. Recurrent regressions erode confidence in on‑premises update pipelines for critical months.
• Dependency on legacy paths: enterprises that rely on complex WSUS topologies, especially when some servers are retained for backward compatibility, may unintentionally mask or amplify such regressions. A hierarchical topology can be used as a short‑term mitigation (downstreams retaining older binaries), but it is operationally complex and brittle.

---

Step‑by‑step guidance for administrators (priority checklist)​

1. Confirm the symptom set on affected devices: look for 0x80240069 errors, WUAHandler Event Log entries, and svchost.exe_wuauserv crash events.
2. Check Microsoft Release Health / support documentation for the specific KB entry to determine whether a KIR or re‑release has been published and marked Resolved. If marked resolved, plan a WSUS catalog refresh. (learn.microsoft.com)
3. Resynchronize WSUS:
   • On the WSUS server, run a manual synchronization with Microsoft Update and confirm that the updated KB is available.
   • Approve/redeploy the re‑released package to affected groups.
4. Deploy KIR selectively:
   • If the KIR artifact is available, deploy it to affected OUs via Group Policy or Intune ADMX ingestion. Test first in a pilot OU before bed‑rolling widely. (support.microsoft.com)
5. For critical hosts that cannot wait, apply manual installation from the Microsoft Update Catalog (download MSU/CAB and apply with DISM or WUSA). Always copy MSUs locally before executing WUSA if the share contains multiple MSU files.
6. Monitor logs and update history:
   • Confirm Update History reflects successful installs after a 15‑minute post‑reboot stabilization window.
   • Correlate WSUS/ConfigMgr compliance reports with endpoint telemetry to ensure reconciled state.
7. Document and communicate:
   • Record remediation steps, affected device counts, and the chosen mitigation in change‑control and compliance documentation.

These steps prioritize minimal disruption while restoring centralized update control and auditability.

---

Larger lessons and recommended long‑term actions​

Harden your update pipeline and test rings​

• Maintain small, fast‑failing test rings that exercise the WSUS/SCCM metadata paths and variant selection logic for each monthly rollup.
• Use a staging WSUS server that mirrors production but is used exclusively for validation to catch delivery‑channel regressions before broad approval.

Consider hybrid/cloud update management​

• Microsoft has been nudging customers toward cloud‑centric update management (e.g., Windows Update for Business, Intune). Cloud services reduce reliance on legacy WSUS binaries and can contain server‑side mitigations that reduce the blast radius for enterprise metadata regressions.
• However, migration planning must consider compliance and network constraints; hybrid approaches can balance centralized control with Microsoft’s cloud-based delivery advantages.

Improve telemetry and runbooks​

• Standardize collection of Windows Update logs and crash dumps and integrate them into SIEM so patterns like WUAHandler failures are detected automatically.
• Keep runbooks updated with pre‑tested KIR deployment steps, manual install commands, and WSUS re‑sync steps.

---

What remains uncertain and cautionary notes​

• While Microsoft’s Release Health entry marks the WSUS delivery problem for KB5063878 as resolved, there is always a non‑zero chance of follow‑on regressions in subsequent monthly updates. Administrators should not assume a single re‑release eliminates operational risk—ongoing validation is necessary. (learn.microsoft.com)
• Community‑shared registry and PowerShell workarounds were circulated widely; these are pragmatic but can carry unintended side effects and should be evaluated in test environments before use at scale. Treat such fixes as temporary mitigations until a supported KIR or servicing fix is deployed.
• Some anecdotal reports extended the symptom set beyond 0x80240069 to errors such as 0x80240031 and 0x800f0922; these appear to be environment‑specific and not universally reproducible, so they require investigation on a case‑by‑case basis.

---

Quick reference: common commands and actions​

• WSUS resync (server, PowerShell):
  • Use the WSUS console or run the synchronization task; verify in the WSUS console that the corrected KB is present.
• Manual MSU install (example):
  • Download MSU from Microsoft Update Catalog, copy locally, run:
  • wusa C:\Temp\windows10.0-kb5063878-x64.msu /quiet /norestart
  • Or apply CAB with DISM if appropriate.
• KIR deployment:
  • Obtain the Microsoft KIR MSI/ADMX artifact (published in Release Health/support note) and import via Group Policy or Intune. Test before broad deployment. (support.microsoft.com)

---

Conclusion​

The WSUS delivery failure that affected Windows 11, version 24H2 (KB5063878) surfaced as a wake‑up call for administrators: the enterprise update path exercises distinct code paths that require explicit validation. Microsoft acknowledged the problem, published a Known Issue Rollback and re‑released the update for WSUS, and administrators who followed the remediation guidance—resynchronizing WSUS, deploying KIR where necessary, or performing targeted manual installs—were able to restore patching continuity. BornCity’s coverage tracked the community and Microsoft response in near‑real time, echoing the technical fingerprints and the suggested mitigation approaches. (borncity.com)
Operationally, this event reinforces three imperatives for IT teams: test delivery channels (not just content), maintain clear runbooks for KIR and emergency manual installs, and accelerate plans to reduce reliance on brittle legacy WSUS topologies where feasible. Administrators should treat the immediate action items—WSUS resync, KIR evaluation, and prioritized manual remediation for critical hosts—as high priority, while using the incident to harden update verification and telemetry for the months ahead.

---

Source: BornCity Windows 11 24H2/Windows Server 2025 is not receiving updates from WSUS | Born's Tech and Windows World