Microsoft released out-of-band updates on November 13 that repair a licensing bug introduced by the November 2026 Patch Tuesday across Windows 10, Windows 11, and Windows Server. The bug breaks slmgr.vbs activation commands like /ipk and /skms-domain, failing with error 0x80041008. Most PCs won't notice, since already-activated devices stay activated, but IT admins running automated deployment and re-key scripts take the hit. The fixes are non-security and cumulative, available only through the Microsoft Update Catalog, and they don't sync to WSUS or Configuration Manager.

Microsoft rolls out out-of-band fixes for a Patch Tuesday activation bug

A Windows licensing regression is patched as of November 13. Most PCs won't even notice.

Microsoft shipped a coordinated set of out-of-band updates on November 13 to repair a licensing bug that was only three days old. The updates address problems introduced by the November 2026 Patch Tuesday across Windows 10, Windows 11, and Windows Server. Here's the part that should let most readers move on: if your machine was already activated, it stayed activated.

The damage was narrowly pinned to a single operation: Windows licensing.

Once a device installs the November security update and you run a specific command through the Software Licensing Management Tool, things start to go sideways. Microsoft lists the resulting error as 0x80041008. It surfaces through WMI as "Invalid parameter," sometimes reported as "Invalid parameter (SWbemObjectEx)."

Two commands specifically break. There's slmgr.vbs /skms-domain, which directs a client at a DNS domain so it can find your internal KMS activation server. Then comes slmgr.vbs /ipk, which installs a product key. Both sit near the center of enterprise imaging and deployment automation. Break them, and entire machine rollouts stall.

Who actually broke

This isn't the kind of bug that bricks your laptop. Microsoft is clear that already-activated devices keep their activation, and it caps the pain at the moment of activation itself. A KMS-licensed machine remains valid for up to 180 days after a successful check-in. Images that already contain the KMS client key are untouched too, provided they don't re-run the affected commands.

So who lands in the crosshairs? Organizations and MSPs that fire off slmgr.vbs /ipk or /skms-domain inside deployment scripts such as MDT, SCCM/Intune task sequences, or unattended setup. Then come admins who re-key a machine, repoint it at a different KMS domain, or rerun activation config after the November update. Basically any fleet that applies the KMS client key through a script instead of baking it into the reference image.

The timeline kept the window tight. Patch Tuesday shipped on November 10. By November 11 Microsoft had already posted a service alert, confirming the regression with a fix promised "in the coming days." The out-of-band updates landed three days later, on November 13. That's from disclosure to fix.

The fix itself

The November 13 packages are non-security and cumulative, so each one also carries the month's security content. Organizations can jump straight to them without first applying the originating monthly update. Microsoft phrased the fix this way, identically across the KB articles: devices that were already activated remained activated, and devices with existing KMS configurations that didn't require additional slmgr commands were not affected.

Known issues at launch are thin. For Windows 11 23H2 (KB5136483), Microsoft says it isn't aware of any problems with the update. The only noted quirk across the Server builds is that WSUS doesn't display error details for these packages.

For admins, the deployment side has a few catches. These updates are catalog-only. They don't sync to WSUS or Configuration Manager, so you have to download, validate applicability, stage, approve, and deploy by hand. Windows 11 23H2 (KB5136483) shows up in the Microsoft Update Catalog and also under Windows Update, Settings, Advanced options, then Optional updates. The rest live in the Catalog alone.

Keep in mind the dynamic-update catch. If you're rolling these out to an existing image, make sure the boot.stl file is in the install media. A missing or mismatched boot.stl can stop the machine from booting and throw error 0xc0430001. The Update WinPE script is the recommended route, or you copy Windows\Boot\EFI\boot.stl in manually.

Not everything is affected, and the exclusions matter. Windows 11 24H2, 25H2, 26H1, and 26H2 are safe. Windows 10 2016 LTSC is clear. Reported to include Windows Server 2026 and 23H2, the newer Server builds aren't on the list either.

The timing bites especially hard for Windows 11 23H2, since that November update was effectively the last one for the Enterprise and Education editions. Those fleets were already lined up to migrate to a newer build.

This activation bug didn't arrive in isolation. The November 2026 Patch Tuesday came with its own clutter. Some Windows 11 PCs hit KB5132061 install failures, reportedly tied to SQL Server connections left open. There were also SQL Server performance and stability problems attributed to updates rolling out since October's Patch Tuesday. It's the same familiar pattern: back-to-back patch days surface overlapping regressions, and IT teams end up juggling several advisories at once.

Licensing regressions like this aren't new, either. Microsoft has issued non-security out-of-band fixes for activation subsystem problems before. The license-migration bugs came even earlier. In January 2026 the company fixed a defect that stopped devices from registering for digital licenses during upgrades, leaving them unable to reach the Windows Activation server. The licensing layer has proven sensitive to changes in underlying system components all through late 2025 and 2026.

Three days from disclosure to fix is fast, but the story here is really about who got burned. Your PC is likely fine. The pain ran from around November 10 to November 13 for the admins scripting new activations at scale, and it ends now that the out-of-band packages are live.

Head here to the KB5136483 article for Windows 11 23H2, and here for the Windows 10 and Server packages. If you manage a fleet, match the build against the affected list before deploying, install the latest Servicing Stack Update first, and re-run any failed slmgr commands once the update lands. Microsoft's own KB articles and the Windows Learn OOB page hold the full deployment guidance.