slmgr.vbs commands can now fail with error 0x80041008, which stops provisioning jobs that worked fine last month.
What Microsoft confirmed
Microsoft describes the symptom as follows: "Affected devices might encounter error 0x80041008, Invalid parameter (SWbemObjectEx), when running commands to activate Windows, configure Key Management Service (KMS), or manage product keys," and "The failure has been observed while executing the command 'slmgr.vbs /skms-domain' and 'slmgr.vbs /ipk'."
BleepingComputer first reported the problem, citing a Microsoft service alert from Wednesday, November 11. Microsoft's own release notes back that up. The change log for the Windows 10 update shows that on November 11, 2026, Microsoft added a known issue for Windows activation and licensing commands that might fail with error 0x80041008 after installing the November 2026 Windows security update.
The Register says the issue primarily affects organizations that use command-line tools or automated processes to manage Windows activation and licensing. Home users who never open an elevated prompt to type slmgr can mostly ignore it.
Affected versions and updates
According to The Register, the notice (WI1549486) currently lists Windows 11 23H2, Windows 10 22H2 and 21H2, and Windows Server 2025, 2022, and 2019 as affected. That matches BleepingComputer's list.
The original report gave no KB numbers. Microsoft's release notes and patch trackers fill some of that gap:
| Platform | November update | Notes |
|---|---|---|
| Windows 10 21H2 / 22H2 | KB5131096 | OS Builds 19045.7846 and 19044.7846 |
| Windows 11 23H2 | KB5131087 | Microsoft documents 1 known issue with this update. Windows activation and licensing commands might fail with error 0x80041008 |
| Windows Server 2022 | KB5131090 | OS Build 20348.5870, released November 10, 2026 |
AdminSignal, a patch-tracking site, says KB5131087, KB5131096, KB5131080, KB5131090 and KB5131085 list the issue (added 11 November 2026), and that KB5131085 covers Server 2019. The sources here don't show which platform KB5131080 belongs to, so check the release notes for your own builds before you assume anything.
On Server 2022 there's a second item to read before deploying. Microsoft lists two known issues for KB5131090: the activation failure and Windows Server Update Services (WSUS) not displaying error details.
Who's actually at risk
Microsoft drew a clear line around the problem:
- Devices that are already activated stay activated. Microsoft told BleepingComputer that devices with the correct KMS client key and KMS configuration, which don't need to run the affected commands, should not be affected.
- Images that already have the KMS key are fine. Microsoft's known-issue text says customers who have the KMS client key already installed in their image and do not use slmgr for further configurations are unaffected.
- New or reconfigured KMS clients are exposed. Per Microsoft, devices that are being configured to use KMS activation might encounter errors when attempting to initiate their activation.
Microsoft also notes that KMS-activated devices typically remain activated for up to 180 days following successful activation. That buys time for machines that were already activated. It doesn't help a new device that fails to activate in the first place.
Think of it like a building's key-card system breaking only when someone programs a new card. Everyone already holding a card gets in. The new hire waits in the lobby, and the IT team that automated card programming gets the angry calls.
A note on the two commands
Microsoft's SLMGR documentation explains why these two commands matter so much:
/ipk <ProductKey>tries to install a product key. It checks that the key is valid for the installed OS, and if a key is already installed, it is silently replaced. Volume deployments use it all the time, for example to swap a GVLK into a freshly imaged machine./skms-domain <FQDN>sets the DNS domain where all KMS SRV records can be found. It is used especially in disjoint namespace environments, where KMS discovery can't rely on the normal DNS suffix search list. It has no effect if a specific KMS host was already set with/skms.
Shops that run these commands in task sequences, golden-image builds, or post-deployment scripts are the ones most likely to see the error.
Possible VDI connection
Before Microsoft published its known issue, Citrix specialist Daniel Deyda reported a related problem: Citrix MCS master images updated with the November patches could not be deployed successfully. He said it remains unclear whether this is caused by changes to the Windows Software Protection Service, Windows activation mechanisms, or the interaction between Windows and Citrix MCS. A commenter on his post suggested the Microsoft known issue might be behind it.
That link is unconfirmed. Microsoft's known issue names /skms-domain and /ipk, not /rearm. Deyda advised that he would also avoid manually modifying slmgr /rearm or Windows activation settings until the underlying cause has been identified. If you run non-persistent VDI, test updated master images before your next big rollout.
What to do now
Microsoft hasn't published a public workaround. Here's an approach based on the scope Microsoft has confirmed:
- Find exposure. Search deployment scripts, MDT/ConfigMgr task sequences, Autopilot follow-up scripts, and image-build pipelines for
slmgr.vbs /ipkandslmgr.vbs /skms-domain. - Match against patched builds. If those scripts target Windows 10 21H2/22H2, Windows 11 23H2, or Server 2019/2022/2025 machines with the November update installed, expect failures.
- Read the error correctly. On these builds, 0x80041008 alongside "SWbemObjectEx" points to this known issue, not necessarily a bad product key. Don't burn keys or rebuild KMS hosts chasing a ghost.
- Check status without changing anything. Microsoft documents
slmgr.vbs /dli,/dlv, and/xprfor viewing license details and KMS activation expiry, and none of them needs elevation. These are diagnostic tools, not a fix. - Escalate if it's urgent. Microsoft has a mitigation for organizations that need it immediately, available through Microsoft Support for business. AdminSignal and other trackers say a permanent fix is pending.
- Keep the security update installed. Some of these packages fix a lot. Senserva's tracker says KB5131087 closes 575 CVEs with a maximum CVSS of 9.8. At least one of them is actively exploited (CISA KEV). Removing the update to fix a scripting problem trades one headache for a much worse one.
Bottom line: if your activation is a set-and-forget KMS key in the image, you're probably fine. If scripts run slmgr, check them now.
Analysis: a niche bug, but not a trivial one
This is a narrow bug, and The Register fairly called it a little more niche, but it could be a headache for affected administrators. But the people it hits are the ones who build machines in bulk, so one failed /ipk call can stall a whole wave of rollouts.
It's also part of a rough month. Microsoft has separately confirmed that November Windows 11 security updates fail to install on systems that have the October 2026 preview update. It also confirmed that Windows updates released since October's Patch Tuesday are causing SQL Server performance and stability problems. Those are separate bugs, not causes of this one. Together they make a good case for testing updates in a pilot ring first.
Microsoft says a fix is coming "in the coming days." Until it arrives, admins have a scoped problem, a support-channel mitigation, and a good reason to keep a pilot ring.