Enable Windows 10 Extended Security Updates

原文：Enable Windows 10 Extended Security Updates — theDXT (Daniel Keer)

On October 14, 2025, Windows 10 reached end of life and no longer receives updates. To keep getting updates, you must upgrade to Windows 11 or enroll in the Windows 10 ESU (Extended Security Updates) program.

In this post, I will show you step by step how to enable the commercial Windows 10 Extended Security Updates and how to mange ESU in non-persistent VDI setups.

What the ESU Program Actually Gives You

Extended Security Updates are a paid entitlement, not a free reprieve. Windows 10 22H2 stopped receiving mainstream and extended support on 14 October 2025, and ESU is the only way to keep receiving security fixes for the operating system after that date. The entitlement is sold in yearly increments, and Microsoft supports up to three years of coverage, which means the last ESU window closes in October 2028.

The important architectural detail is that ESU delivers security updates only. You will not receive feature updates, non-security quality fixes, or changes to the servicing stack beyond what is strictly needed to install the security patches. In practice that means an ESU-enrolled Windows 10 22H2 machine is a frozen platform that still gets its monthly vulnerability patches - which is exactly what a validated line-of-business application or a widely deployed VDI base image needs.

Two flavours of ESU exist, and mixing them up is a common source of wasted time:

• Commercial ESU - purchased through a volume licensing agreement or a cloud solution provider, activated with a Multiple Activation Key (MAK) and the activation IDs used in this guide. This is the path for organisations with an active volume licence.
• Consumer ESU - a free or low-cost one-year enrolment for individuals, delivered through Windows Update on a Microsoft account and, on some SKUs, linked to Windows Backup settings. It is not activated with slmgr.vbs at all.

This guide covers the commercial path, because that is the one you can deploy at scale with MDM, Group Policy or a task sequence - and the one that requires the VDI housekeeping described further down.

Perquisites

• Windows 10 ESU MAK.

Once you have purchased Windows 10 ESU, you will receive a MAK (Multiple Activation Key).

• Windows 10 version 22H2.

  • Windows 10 LTSB or LTSC are not eligible for ESU.

• The following updates must be installed.

  • 2025-10 Cumulative Update for Windows 10 Version 22H2 (KB5066791) or newer.
    • 2025-11 Security Update for Windows 10 Version 22H2 (KB5072653) installed after KB5066791.

Verify the build before you start. The ESU enrolment is applied to the operating system's licensing subsystem, and a machine that has not yet installed the prerequisite servicing stack updates will either fail activation outright or appear to succeed and then never offer an ESU-category update. Check the version and build from an elevated prompt:

winver
# or, for scripted checks:
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v DisplayVersion

A healthy target is Windows 10 Pro, Enterprise or Education, version 22H2, build 19045. Anything reporting 21H2, 21H1, or an LTSC/LTSB SKU needs to be remediated or upgraded first; ESU keys simply will not activate against those editions.

The Process

• Open Command Prompt or PowerShell as admin.

We will use slmgr.vbs which you can use directly or call it from csript. I will call it from csript to keep everything in the command line window. To use csript with slmgr.vbs we just need to prefix the slmgr.vbs command with cscript C:\Windows\System32\.

If you want to read more about slmgr.vbs, my blog post slmgr.vbs goes into detail.

• First, we need to install the Windows 10 ESU MAK product key. We will do this with the following command slmgr.vbs /ipk YOUR_ESU_PRODUCT_KEY replace YOUR_ESU_PRODUCT_KEY with your Windows 10 ESU MAK product key.

cscript C:\Windows\System32\slmgr.vbs /ipk YOUR_ESU_PRODUCT_KEY

Next, we need to activate the specific ESU component by using its Activation ID.

• For Windows 10 ESU, there are 3 Activation IDs available.

  • The Windows 10 ESU Year 1 Activation ID is f520e45e-7413-4a34-a497-d2765967d094.
  • The Windows 10 ESU Year 2 Activation ID is 1043add5-23b1-4afb-9a0f-64343c8f3f8d.
  • The Windows 10 ESU Year 3 Activation ID is 83d49986-add3-41d7-ba33-87c7bfb5c0fb.

• To activate the ESU, we will use the following command slmgr.vbs /ato ESU_ACTIVATION_ID replacing ESU_ACTIVATION_ID with the Activation ID that applies to your situation.

cscript C:\Windows\System32\slmgr.vbs /ato f520e45e-7413-4a34-a497-d2765967d094

Activation binds the ESU entitlement to that specific device ID and consumes one activation from your MAK allowance. That single fact drives every deployment decision that follows: a physical machine activates once and stays activated, while a non-persistent VDI pool could burn hundreds of activations in a day if the golden image ships pre-activated.

• To confirm everything worked, run the following command slmgr.vbs /dlv ESU_ACTIVATION_ID replacing ESU_ACTIVATION_ID with the Activation ID you just activated.

cscript C:\Windows\System32\slmgr.vbs /dlv f520e45e-7413-4a34-a497-d2765967d094

In the detail output, look at the licence status and the remaining activation count. A successful activation reports the ESU licence as licensed, with an expiry that tracks the year you activated. A failure to activate almost always traces back to one of four causes: the MAK is exhausted, the machine is not 22H2, the prerequisite KBs are missing, or the device cannot reach the Microsoft activation servers because of a proxy or firewall rule.

• You can now update your Windows 10 system.

Deploying ESU at Scale

Nothing stops you from running the two slmgr.vbs commands by hand on a lab machine, but across a fleet you want them wrapped in something idempotent. A short script that checks the current edition, installs the key, activates the correct year and then verifies the result is usually all you need. The logic is worth writing defensively because re-running /ipk against a machine that is already enrolled is harmless, whereas re-running /ato against an exhausted MAK wastes an activation attempt.

$key = "YOUR_ESU_PRODUCT_KEY"
$year1 = "f520e45e-7413-4a34-a497-d2765967d094"
cscript C:\Windows\System32\slmgr.vbs /ipk $key
cscript C:\Windows\System32\slmgr.vbs /ato $year1
cscript C:\Windows\System32\slmgr.vbs /dlv $year1

If you manage endpoints with Intune, Configuration Manager or a golden-image pipeline, treat ESU activation as a distinct, last step that runs after the image is otherwise finalised and sysprep has completed. Activation state is written into the licensing database and, in some configurations, into the machine's digital entitlement - capturing it into an image before deactivation is precisely the mistake described in the next section. Companion reading for the surrounding endpoint plumbing: Disable auto Windows updates if you need to control the servicing window rather than let Windows Update run freely, and Deploying Windows LAPS for the local-administrator password rotation that should accompany any fleet-wide script you deploy.

Non-Persistent VDI

When using Windows 10 ESU with non-persistent VDI, you'll need to deactivate your Windows 10 ESU product key on your golden image before publishing it, or else non-persistent systems may consume all your ESU activations.

• Open Command Prompt or PowerShell as admin.

• Remove the Windows 10 ESU activation with the following command slmgr.vbs /upk ESU_ACTIVATION_ID replacing ESU_ACTIVATION_ID with the Activation ID you used.

cscript C:\Windows\System32\slmgr.vbs /upk f520e45e-7413-4a34-a497-d2765967d094

The workflow in practice: activate inside the golden image so that Windows Update pulls the ESU-month updates and the image ends up fully patched, then deactivate before publishing. Each non-persistent instance must re-activate its own ESU component at first boot, which is why the enrolment step belongs in a first-logon script or in the pool's provisioning task rather than in the image itself. If you reverse the order - publish first, deactivate later - every clone consumes an activation and your MAK allowance disappears far faster than the number of devices you own.

Also verify how your broker behaves around instant clones. With VMware Horizon and similar platforms, an instant clone's first boot is where machine identity, domain join and licensing are all finalised; an ESU activation that fires before the clone's identity is set can attach to the parent VM's device ID, which produces the confusing symptom of some clones reporting as licensed and others not. Related infrastructure reading: VMware Horizon GPO templates for pushing the enrolment script through policy, and deploying an application on non-persistent VDI for the general pattern of getting a per-user or per-machine agent to survive a fresh clone.

Known Issues

There are a few known issues with Windows 10 ESU that you should be aware of.

• It's common after activating the Windows 10 ESU that Windows Updates says your device is no longer receiving security updates. This is just a visual bug, as checking and installing updates works. The update that resolves the issue is available after enrolling in Windows 10 ESU.

• On some systems, after all Windows 10 ESU updates are installed, Windows Updates may keep saying You're not up to date and/or Your device is missing important security and quality fixes. But when you check for updates, no new updates are available. This is another visual bug. In my testing, it typically clears up in about 24 hours.

Both bugs are cosmetic, and the way to tell them apart from a real servicing failure is the update history. If Windows Update reports an error code, offers no updates at all, or the history shows a failed install, that is a genuine problem: check the prerequisite KBs, the activation state with slmgr.vbs /dlv, and the WindowsUpdate.log / event log entries around the failure. If the history shows installed updates and the Settings page simply disagrees, give it a day.

Common Error Codes and What They Mean

When slmgr.vbs refuses to co-operate, the code it prints is more useful than the message. A few you are likely to meet on this path:

• 0xC004F050 - the product key was rejected as invalid for this edition. Usually the key is a Windows 11 or LTSC key rather than the Windows 10 ESU MAK.
• 0xC004F069 - the requested activation ID is not present on the machine. This is the signature of a missing prerequisite update or a non-22H2 build, so re-check the version before touching the key again.
• 0xC004FC03 - the activation service could not be reached. Almost always a proxy, TLS inspection, or firewall rule blocking the Microsoft activation endpoints; VPNs and locked-down VDI networks are the usual culprits.
• An activation that reports success but produces no ESU-category updates - the licence is bound but Windows Update is pointed at an internal WSUS or Configuration Manager site that has not been told to sync the ESU classification. Approve the ESU product there, or the client will keep polling a source that has nothing to offer it.

Planning the Exit, Not Just the Enrolment

ESU is a bridge, not a destination. Every year of coverage is separately purchased and separately activated, so the sensible plan is to decide now what replaces the Windows 10 estate before the third year runs out. In practice that means three tracks running in parallel: rewrite or repackage applications that block an in-place upgrade to Windows 11, validate the hardware compatibility list against your existing fleet, and treat any machine that cannot be upgraded as either a VDI candidate or a decommissioning target. Enrolling in ESU buys the time to do that work - it does not remove the work itself.

Summary

That's all it takes to enable the commercial Windows 10 Extended Security Updates and manage it in non-persistent VDI setups.

If you want to learn more about Windows 10 ESU, here is the Microsoft documentation.