Windows 10 ESU: KB5068781 fails with 0x800f0922 for some orgs

Microsoft’s first Windows 10 Extended Security Update, KB5068781, is not installing cleanly everywhere. On some Windows 10 22H2 devices enrolled in ESU, the update appears to install, reboots, reaches the configuration phase, and then rolls back with error 0x800f0922 (CBS_E_INSTALLERS_FAILED). Admins see the update reported as failed in Windows Update history with that code.

The problem affects commercial ESU customers rather than home users. Microsoft’s own release notes now list a known issue: the KB5068781 ESU update might fail with 0x800f0922 on some devices that use Windows subscription activation via the Microsoft 365 Admin Center.

𝐖𝐡𝐲 𝐭𝐡𝐢𝐬 𝐦𝐚𝐭𝐭𝐞𝐫𝐬 𝐟𝐨𝐫 𝐖𝐢𝐧𝐝𝐨𝐰𝐬 𝟏𝟎 𝐄𝐒𝐔 𝐜𝐮𝐬𝐭𝐨𝐦𝐞𝐫𝐬

Windows 10 reached end of support on October 14, 2025. After that date, the operating system stopped receiving free security updates. Organizations that still rely on Windows 10 enrolled in Extended Security Updates (ESU) to keep getting monthly security fixes.

KB5068781 is the first of those ESU releases. It brings Windows 10 22H2 ESU devices to build 19045.6575 and Windows 10 Enterprise LTSC 2021 to 19044.6575, and it includes November 2025 Patch Tuesday security fixes, including one actively exploited vulnerability. If this update fails, those devices miss the first post-EoS security baseline.

For critical environments that chose ESU as a “bridge” before a full Windows 11 migration, repeated 0x800f0922 failures mean a growing gap between what the security team believes is patched and what actually runs on the endpoints.

𝐖𝐡𝐚𝐭 𝐌𝐢𝐜𝐫𝐨𝐬𝐨𝐟𝐭 𝐡𝐚𝐬 𝐜𝐨𝐧𝐟𝐢𝐫𝐦𝐞𝐝 𝐬𝐨 𝐟𝐚𝐫

Microsoft’s KB5068781 support article and Windows 10 release-health notes now include an explicit entry for this failure. The description matches what administrators see in the field:

• The issue affects some Windows 10 devices enrolled in ESU for commercial customers.
• The update fails to install with 0x800f0922 (CBS_E_INSTALLERS_FAILED).
• The bug is isolated to devices activated via Windows subscription activation through the Microsoft 365 Admin Center.
• Microsoft lists the status as under investigation and, at the time of writing, offers no official workaround beyond monitoring for future updates.

Admins also report two related symptoms on ESU fleets: some properly licensed devices do not show KB5068781 as applicable yet, and some attempts to apply the .msu package manually end in the same rollback with 0x800f0922.

𝐖𝐡𝐚𝐭 𝟎𝐱𝟖𝟎𝟎𝐟𝟎𝟗𝟐𝟐 𝐮𝐬𝐮𝐚𝐥𝐥𝐲 𝐦𝐞𝐚𝐧𝐬 (𝐚𝐧𝐝 𝐰𝐡𝐲 𝐭𝐡𝐢𝐬 𝐜𝐚𝐬𝐞 𝐢𝐬 𝐝𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐭)

Historically, 0x800f0922 appears in a few Windows update scenarios:

It can indicate a general CBS_E_INSTALLERS_FAILED condition in the component-based servicing stack. In practice, administrators often see it when the update engine cannot apply changes at the very end of the process.

On older Windows 10 builds, 0x800f0922 sometimes pointed to insufficient space in the System Reserved partition or a blocked connection to update services. Troubleshooting usually involved expanding the System Reserved partition, freeing disk space, repairing .NET, or disabling VPN and firewall temporarily.

In the KB5068781 ESU case, Microsoft’s documentation and customer reports do not blame storage or connectivity. Instead, they link the error specifically to Windows subscription activation for ESU through the Microsoft 365 Admin Center. That points toward a licensing or activation interaction inside the servicing stack rather than a typical disk or network issue.

𝐒𝐡𝐨𝐫𝐭-𝐭𝐞𝐫𝐦 𝐩𝐥𝐚𝐧 𝐟𝐨𝐫 𝐩𝐚𝐭𝐜𝐡 𝐦𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐭𝐞𝐚𝐦𝐬

Because Microsoft has acknowledged the bug and tied it to a specific activation path, administrators should treat this as a known upstream issue, not a misconfiguration of their own patch tooling. That said, patching teams still need a structured response so the ESU rollout does not stall quietly.

First, separate monitoring from remediation. Update your compliance dashboards and reports so KB5068781 installation failures with 0x800f0922 stand out. Tag affected devices by ESU activation method and tenant. That distinction helps when Microsoft ships a fix or publishes a mitigation.

Next, verify ESU enrollment and activation states. For corporate fleets, check subscription activation status in the Microsoft 365 Admin Center and ensure devices show as properly licensed and eligible. Cross-check with any existing documentation for your ESU rollout, especially if you previously dealt with the separate ESU enrollment wizard bug that required an emergency fix earlier in November.

Then, avoid aggressive manual workarounds that could complicate future servicing. For example, repeatedly forcing manual .msu installs on devices already known to fail with 0x800f0922 will not fix the root cause and may create confusion in logs and change records. Focus on collecting clean telemetry and keeping your ESU inventory accurate while Microsoft works on the servicing issue.

𝐖𝐡𝐚𝐭 𝐲𝐨𝐮 𝐜𝐚𝐧 𝐝𝐨 𝐰𝐢𝐭𝐡 𝐰𝐨𝐫𝐤𝐬𝐭𝐚𝐭𝐢𝐨𝐧𝐬 𝐫𝐢𝐠𝐡𝐭 𝐧𝐨𝐰

While you wait for an official fix, you still have room to reduce risk.

You can confirm that affected Windows 10 ESU devices remain enrolled and continue to receive other updates, where applicable. You can also re-check servicing stack prerequisites such as installing the bundled SSU/LCU combination that ships with KB5068781 (the servicing stack update component is listed as KB5068780 in Microsoft’s documentation). Ensuring that SSUs are current reduces the chance of unrelated installation failures when Microsoft ships a corrective patch.

You can also plan for out-of-band testing. Keep a small pilot ring of ESU devices where you apply any future hotfix or revised cumulative update quickly, and validate the behavior before you roll changes to larger rings. That pattern prevents a second wave of surprises if the fix carries its own side effects.

Finally, you can review update-channel configuration across WSUS, ConfigMgr, Intune, or other patch-management platforms, and confirm that your targeting logic for KB5068781 lines up correctly with ESU eligibility and Windows 10 22H2 build baselines. That process does not repair 0x800f0922, yet it ensures that any eventual fix actually reaches the machines you care about.

𝐀 𝐬𝐡𝐨𝐫𝐭 𝐄𝐒𝐔 𝐜𝐡𝐞𝐜𝐤𝐥𝐢𝐬𝐭 𝐟𝐨𝐫 𝐭𝐡𝐢𝐬 𝐨𝐮𝐭𝐚𝐠𝐞

For most organizations, a practical checklist looks like this:

Confirm which Windows 10 22H2 devices are enrolled in ESU and how they activate. Tag devices that use Windows subscription activation via Microsoft 365 separately from those that use MAK keys or other mechanisms.

Record every device that fails KB5068781 with 0x800f0922, including date, time, activation method, and patching tool. That evidence helps if you open a support case or need to justify risk acceptance.

Document your current risk posture: note that KB5068781 contains November 2025 security fixes, and catalogue any business-critical systems that remain on pre-KB5068781 builds while the bug persists.

Maintain transparent communication with stakeholders. Explain that Microsoft has documented the issue, published it as a known problem with KB5068781, and is working on a fix, while you continue to track affected devices and test any updates Microsoft releases.

𝐒𝐭𝐫𝐚𝐭𝐞𝐠𝐢𝐜 𝐭𝐚𝐤𝐞𝐚𝐰𝐚𝐲, 𝐤𝐧𝐨𝐰 𝐲𝐨𝐮𝐫 𝐄𝐒𝐔 𝐦𝐞𝐜𝐡𝐚𝐧𝐢𝐬𝐦𝐬

The 0x800f0922 failures with KB5068781 do not just create noise in your patch dashboard. They highlight how much complexity sits underneath ESU licensing, Windows subscription activation, and cumulative update servicing.

If your Windows 10 strategy treats “ESU on 22H2” as one undifferentiated pool, you may miss subtle but important differences between devices activated via MAK, devices activated through Microsoft 365 subscription, and devices that never enrolled correctly. This bug lands specifically on one of those paths.

Longer term, you reduce surprises by mapping exactly how each segment of your Windows 10 estate receives ESU, documenting those flows as carefully as you document Windows 11 servicing, and building monitoring that understands those nuances instead of treating all Windows 10 ESU endpoints as interchangeable.