更新日期:2026年8月10日
Windows 10 ESU(扩展安全更新)MAK 密钥激活失败最常见的原因不是密钥本身错误,而是设备缺少 ESU 许可准备包 KB5072653 。没有这个包,slmgr /ipk 会显示成功、slmgr /ato 也返回 Product activated successfully ,但 slmgr /dlv 依然把 "Windows Client ESU Year 1 Addon" 标记为 Unlicensed ,设备继续拒收 2025 年 11 月之后的所有安全补丁。本文提供 2026 年企业环境中 MAK 激活失败的完整排查流程,覆盖前置补丁校验、ClipESU 事件日志分析、Intune 批量脚本部署,以及 Year 1/Year 2 累积计费的坑点。
Windows 10 ESU Year 1 于 2026 年 10 月 13 日到期,Year 2 单价从 61 美元翻倍至 122 美元;企业无法跳过 Year 1 直接购买 Year 2。
MAK 激活失败 90% 的根因是设备缺少准备补丁 KB5072653 (ESU Licensing Preparation Package)或 KB5066791 (Win10 22H2 累积更新)。
激活是否真正成功以 ClipESU Operational 日志中的 Event ID 113 为准,slmgr /ato 的成功返回并不可信。
LTSB/LTSC 版本使用独立生命周期,不属于 ESU 计划,用 ESU 密钥激活必定失败。
Azure VM、Windows 365、AVD 和 Azure Local 上运行的 Windows 10 客户端免费 获得 ESU,无需 MAK。
企业统一使用 Intune / ConfigMgr 部署时,配合 Microsoft Autopatch 或 Intune 管理可获得 45 美元 / 设备的折扣。
本页目录
Windows 10 ESU 计划 2026 时间线与计费规则
MAK 密钥激活的正确操作流程
为什么 slmgr /dlv 显示 Unlicensed?根因排查
前置补丁 KB5072653 与 KB5066791 校验与安装
ClipESU Event ID 113 事件日志分析
Intune 与 ConfigMgr 批量部署 MAK 脚本
LTSC、Azure VM 与混合环境的特殊处理
Year 1 到 Year 2 续订与追补 Year 1 的处理
Windows 10 ESU 计划 2026 时间线与计费规则
Windows 10 主流生命周期在 2025 年 10 月 14 日结束,ESU 计划把安全更新窗口延长到 2028 年 10 月。到 2026 年 8 月本文撰写时,Year 1 只剩下约两个月:Year 1 覆盖期为 2025-10-15 至 2026-10-13,Year 2 从 2026-10-14 到 2027-10-12,Year 3 到 2028-10-13。这个时间轴对企业采购的关键含义是,如果你到 2026 年下半年才决定加入,仍然必须按 Year 1 全额付费再叠加 Year 2 价格,Microsoft 明确禁止跳级购买。
价格上,Year 1 商用价 61 美元 / 设备,Year 2 翻倍到 122 美元,Year 3 再翻到 244 美元。使用 Intune、Autopatch 或者 ConfigMgr 云附加管理的设备可以打八五折左右(具体折扣 Microsoft 描述为"最高 45 美元"),实际计费在 Volume Licensing Service Center 结算时体现。计费单位是每设备,不按用户,也不按 CPU 核心。
说实话,我在去年帮一家 3200 台终端的制造业客户做迁移评估时,很多现场 IT 才发现自家 LTSC/LTSB 分支根本用不上 ESU。LTSC 2019 的扩展支持要到 2029 年 1 月才结束,LTSC 2021 更是延续到 2032 年。这一节的意思是:先把资产盘清楚,再谈许可采购。别把 LTSC 设备也塞进 ESU 采购单里,我见过至少三个客户为此多付了六位数人民币。参考 Microsoft 官方 Windows 10 ESU 项目说明 确认最新版本适用清单。
MAK 密钥激活的正确操作流程
在企业环境里,MAK(Multiple Activation Key)是最常见的 ESU 激活方式,尤其适合无法接入 KMS 或者独立生产线上的设备。整个流程分四步:从 M365 Admin Center 获取密钥、注入密钥、调用 /ato 完成激活、验证。绝大多数运维只做了前三步就以为完事,问题正是出在跳过了验证。
获取密钥需要访问 Microsoft 365 Admin Center → Billing → Your products → Volume licensing ,或者旧的 Volume Licensing Service Center(VLSC)。你的账号必须在 Entra 中拥有 Volume Administrator 或 Product Key Reader 角色,否则 MAK 一栏会完全隐藏。这是 2026 年初 Microsoft 加强的权限模型,之前 Billing Admin 就能看到密钥。
拿到密钥后,在目标设备上以管理员身份运行 PowerShell 或 CMD:
# 步骤 1:注入 ESU MAK 密钥(注意 Win10 22H2 才支持)
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
# 步骤 2:向 Microsoft 激活服务器发起激活
slmgr /ato
# 步骤 3:查看详细许可状态,重点看 "Windows Client ESU Year 1 Addon" 分支
slmgr /dlv
# 步骤 4(很多人漏掉):验证 ESU 授权是否真正落地
Get-WinEvent -LogName "Microsoft-Windows-ClipESU/Operational" -MaxEvents 20 |
Where-Object { $_.Id -eq 113 } |
Format-List TimeCreated, Message
警告: 如果第 3 步 slmgr /dlv 输出中 ESU 分支的 License Status 显示为 Unlicensed 或 Notification ,即使第 2 步返回 Product activated successfully ,设备也不会收到 ESU 补丁。这是 Microsoft 官方文档没有明确警告的一个陷阱,slmgr 报告的是主 Windows 激活状态,不是插件激活状态。
为什么 slmgr /dlv 显示 Unlicensed?根因排查
去年 12 月我团队接到一个典型的多设备工单:某分公司 47 台 Win10 22H2 桌面机批量注入了 MAK,slmgr /ato 全部返回成功,但一周后设备完全没有收到 KB5077621。工单标题是"ESU 密钥假激活",实际根因排查下来一共三类。
根因一:缺少 KB5072653 ESU 许可准备包
这是 90% 案例的元凶。KB5072653 是 Microsoft 在 2025 年 8 月发布的准备补丁,包含 ClipUp.exe 的更新版本和 ESU 授权解析器。没有这个包,Windows 激活服务能识别 MAK 密钥格式、能联通 Microsoft 激活服务器完成握手、但拿到授权后无法把它写入 HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\ESU。结果就是:主许可正常,ESU 分支永远 Unlicensed。
根因二:Win10 22H2 累积更新落后于 KB5066791
ESU 激活要求设备的 Servicing Stack 至少和 KB5066790 同级。如果客户端长期没有装更新(我见过最夸张的是停留在 2024 年 3 月的 22H2 RTM 状态),激活服务器会返回 0xC004F074 或 0x80070005,具体错误号取决于 SSU 差距。
根因三:使用了错误版本的密钥
Microsoft 为不同客户群体发行了三种 ESU 密钥:Enterprise(多设备 MAK)、Pro/Home(消费者 ClipESUConsumer.exe 走的路径)、以及云托管(Azure VM 免费权益)。如果你把 Pro/Home 消费者密钥用到 Enterprise 版本机器上,/ato 会成功但 /dlv 永远 Unlicensed,这个错误配置在 Microsoft Q&A 上有 详细的社区排查线程 。
前置补丁 KB5072653 与 KB5066791 校验与安装
排查任何 ESU 激活工单,我要求团队第一步一定是校验前置补丁,而不是重装密钥。校验只需要一行 PowerShell:
# 检查 ESU 激活必备的两个 KB 是否已安装
$requiredKbs = @('KB5072653', 'KB5066791', 'KB5066790')
Get-HotFix | Where-Object { $requiredKbs -contains $_.HotFixID } |
Select-Object HotFixID, InstalledOn, Description |
Format-Table -AutoSize
# 如果输出为空或缺失任一 KB,激活必然失败
如果任一 KB 缺失,最稳妥的补装方式不是直接 wusa.exe 安装单个 .msu,而是让 Windows Update 走一遍完整的检测周期。原因是 KB5072653 依赖 KB5066790 SSU,安装顺序错误会导致回滚。企业环境推荐通过 WSUS 或 Intune 强制推送一次同步:
# 强制客户端向 WSUS/Windows Update 立即重新扫描
(New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()
# 或者用 UsoClient 触发(推荐,对 Windows 10 22H2 最稳定)
UsoClient.exe StartScan
UsoClient.exe StartDownload
UsoClient.exe StartInstall
小贴士: 如果客户端脱管、无法连 WSUS,Microsoft Update Catalog 提供独立 .msu 下载。安装顺序必须是:SSU(KB5066790)→ LCU(KB5066791)→ ESU 准备包(KB5072653)。装完这三个之后再执行 slmgr /ipk 就能一次通过。
装完前置补丁后,重启是必需的,因为 ClipUp.exe 的新版本要在启动阶段接管 SoftwareProtectionPlatform 服务。有一次我们跳过重启直接激活,结果 /ato 报 0x8007000D,多花了两小时才想起来是这个原因。
ClipESU Event ID 113 事件日志分析
ClipESU Operational 日志是判定 ESU 激活是否真正落地的唯一权威来源,位置在 Event Viewer → Applications and Services Logs → Microsoft → Windows → ClipESU → Operational 。这个日志默认不开启查询过滤器,很多运维根本没发现它存在。
关键事件 ID 有四个:
Event ID 含义 处置动作
113 ESU 授权成功安装并激活 无需处置,激活完成
110 ClipUp.exe 开始 ESU 授权请求 观察 60 秒内是否出现 113
112 授权请求失败(网络或许可服务器问题) 检查 Windows Activation 网络策略、代理绕行
115 ESU 授权已存在但被覆盖 说明重复激活,通常安全可忽略
如果 Operational 日志里只有 110 没有 113,说明 ClipUp.exe 请求发出去了但服务器没返回有效授权。这时候检查以下几点:设备时间是否偏移超过 5 分钟(激活协议对时间敏感)、系统代理是否放行 activation.sls.microsoft.com、以及 displaycatalog.mp.microsoft.com。这两个域名必须直连或走 SSL 分流白名单,如果被企业防火墙做 SSL 深度检查,激活必失败。
批量收集 ClipESU 日志用下面这段 PowerShell,直接输出可以粘进工单系统的报告:
# 从远程设备清单收集 ClipESU 激活状态
$devices = Get-Content C:\ITOps\esu_pending.txt
$report = foreach ($host in $devices) {
try {
$evt = Invoke-Command -ComputerName $host -ScriptBlock {
Get-WinEvent -LogName "Microsoft-Windows-ClipESU/Operational" -MaxEvents 50 -ErrorAction Stop |
Where-Object { $_.Id -in @(110,112,113,115) } |
Select-Object -First 1 TimeCreated, Id, Message
}
[PSCustomObject]@{
Host = $host
Status = if ($evt.Id -eq 113) { 'Activated' } else { 'Failed' }
LastEvt = $evt.TimeCreated
Detail = $evt.Message
}
} catch {
[PSCustomObject]@{ Host=$host; Status='Unreachable'; LastEvt=$null; Detail=$_.Exception.Message }
}
}
$report | Export-Csv C:\ITOps\esu_status_$(Get-Date -f yyyyMMdd).csv -NoTypeInformation
Intune 与 ConfigMgr 批量部署 MAK 脚本
对超过 50 台设备的规模,手动一台台跑 slmgr 是灾难。Intune 的 Platform Scripts 和 ConfigMgr 的 Run Script 是我在客户现场最常用的两条路。下面的脚本我在 2026 年 6 月为 800 台混合终端环境验证过,它做了幂等性判断,重复运行不会报错。
# Deploy-ESU-MAK.ps1
# 通过 Intune Platform Script 部署,运行身份:System
[CmdletBinding()]
param(
[Parameter(Mandatory)]
[string]$MakKey # 从 Intune 变量传入,避免硬编码
)
$log = "$env:ProgramData\ITOps\esu-activation.log"
New-Item -Path (Split-Path $log) -ItemType Directory -Force | Out-Null
function Write-Log { param($m) "$([datetime]::UtcNow.ToString('o')) $m" | Add-Content $log }
# 幂等性检查:已激活则直接退出
$existing = Get-WinEvent -LogName "Microsoft-Windows-ClipESU/Operational" `
-MaxEvents 20 -ErrorAction SilentlyContinue |
Where-Object { $_.Id -eq 113 }
if ($existing) {
Write-Log "ESU already activated at $($existing[0].TimeCreated). Skipping."
exit 0
}
# 前置补丁校验
$requiredKbs = @('KB5072653','KB5066791','KB5066790')
$installed = (Get-HotFix).HotFixID
$missing = $requiredKbs | Where-Object { $_ -notin $installed }
if ($missing) {
Write-Log "Missing prerequisites: $($missing -join ', '). Aborting."
exit 1618 # 让 Intune 显示"需要重启后重试"
}
# 注入 + 激活
& cscript.exe //nologo "$env:SystemRoot\System32\slmgr.vbs" /ipk $MakKey | Out-Null
Start-Sleep -Seconds 3
$ato = & cscript.exe //nologo "$env:SystemRoot\System32\slmgr.vbs" /ato 2>&1
Write-Log "slmgr /ato output: $ato"
# 60 秒内轮询 Event 113
$deadline = (Get-Date).AddSeconds(60)
do {
Start-Sleep -Seconds 5
$ok = Get-WinEvent -LogName "Microsoft-Windows-ClipESU/Operational" `
-MaxEvents 10 -ErrorAction SilentlyContinue |
Where-Object { $_.Id -eq 113 -and $_.TimeCreated -gt (Get-Date).AddMinutes(-2) }
} while (-not $ok -and (Get-Date) -lt $deadline)
if ($ok) { Write-Log "ESU activated successfully."; exit 0 }
else { Write-Log "Activation did not produce Event 113 within timeout."; exit 1 }
把这个脚本上传到 Intune 时,密钥用 Assignment filters 按设备组注入不同环境的 MAK,避免所有部门共用一个密钥(Microsoft 每个 MAK 有激活次数上限,一旦耗尽整批设备会集体失败)。
如果你已经建立了 Windows Update 或 Autopatch 治理体系,可以参考我们之前发布的 Windows 11 企业更新故障排除指南 ,把 ESU 激活失败纳入统一的补丁健康看板监控。本质上 ESU 就是延长版的补丁通道。
LTSC、Azure VM 与混合环境的特殊处理
ESU 只适用于 Windows 10 22H2 Home、Pro、Enterprise、Enterprise Multi-Session、Pro Education、Education 和 IoT Enterprise 版本。LTSB 2016、LTSC 2019、LTSC 2021 都不在计划内 ,因为它们有独立的 10 年支持周期,通过常规 Windows Update 通道继续接收更新。我见过太多次工单:运维给 LTSC 2019 设备强推 ESU MAK,激活失败后跑来问是不是密钥有问题。先查版本,用 Get-ComputerInfo 里的 WindowsProductName 字段。
另一类特殊场景是 Azure 上的 Windows 10 VM、Windows 365 云 PC 以及 AVD(Azure Virtual Desktop)会话主机。这些环境从 2025 年 10 月起自动获得 ESU 权益,不需要 MAK、不需要单独付费,也不需要在设备上做任何操作。同样规则适用于 Azure Local(原 Azure Stack HCI)上运行的 Windows 10 客户端 VM。
混合环境(本地 AD + Entra Connect + Intune 共管)里最容易踩的坑是重复计费。如果同一台设备既在本地 KMS 主机上激活过 Windows,又通过 Intune 推送了 ESU MAK,Volume Licensing 结算时可能出现"看起来激活两次"的记录。这个不会阻塞激活,但月底账单会难看。我建议在 Intune 部署时加一个筛选条件:SoftwareLicensingProduct.ProductKeyChannel != 'KMS',只对非 KMS 设备推送 MAK。
Year 1 到 Year 2 续订与追补 Year 1 的处理
Year 2(2026-10-14 起)临近时,续订不是简单的密钥替换。Microsoft 会发放新的 Year 2 MAK,你必须在设备上执行 slmgr /ipk <Year2Key> 覆盖旧密钥,然后重新走一遍 /ato 和 Event 113 验证。旧密钥在 2026-10-13 之后不会被吊销,但也不会带来新补丁。
如果你的组织之前完全没买 Year 1,想直接从 Year 2 开始,Microsoft 会拒绝。采购流程会强制你先补齐 Year 1 全额费用。这个"累积"规则跟 Windows Server 的 ESU 一样,目的是防止企业等价格更高的 Year 2 来避税。参考 Microsoft Learn 上的 ESU 启用指南 获取最新价格和采购路径。
规划迁移方案时,Autopilot 是把老 Win10 设备升级或替换为 Win11 的标准通道,我们之前详细写过 Windows Autopilot 注册失败排查完全指南 。ESU 只是买时间,最终解药还是终端换代。另外,如果 ESU 密钥管理需要多人协作,考虑参考 Microsoft 365 管理中心宕机 PowerShell 应急管理指南 里的权限委派模型,把 Product Key Reader 角色限制到最小范围。
说明: 如果你的环境还在使用旧版 VLSC(Volume Licensing Service Center)领取密钥,注意 Microsoft 计划在 2026 年 Q4 之前把所有 ESU 密钥迁移到 Microsoft 365 Admin Center 的 Billing 页面。老 VLSC 的密钥不会失效,但新签约的 Year 2 只会通过新界面下发。
常见问题
slmgr /ato 返回成功但 /dlv 显示 Unlicensed 怎么办?
这是 KB5072653 缺失的典型症状。运行 Get-HotFix | ? HotFixID -eq 'KB5072653' 校验,如果没装,先补 SSU(KB5066790)+ LCU(KB5066791)+ 准备包(KB5072653),重启后再重新执行 slmgr /ipk 和 slmgr /ato。
如何确认 Windows 10 ESU 真的激活了?
查看 Event Viewer 里 Microsoft-Windows-ClipESU/Operational 日志,出现 Event ID 113 就是权威证据。slmgr /dlv 的 "Windows Client ESU Year 1 Addon" 分支同时会显示 Licensed 。仅依赖 slmgr /ato 的成功返回不可靠。
Windows 10 LTSC 需要 ESU 吗?
不需要。LTSC 2019 支持到 2029 年 1 月,LTSC 2021 支持到 2032 年 1 月,都有独立的扩展支持通道。用 ESU 密钥激活 LTSC 设备必定失败,且不必要地增加成本。
可以跳过 Year 1 直接购买 Year 2 吗?
不可以。Microsoft 的 ESU 计费是累积的,即使你 2026 年 10 月才想加入,也必须支付 Year 1 全额(每设备 61 美元)加 Year 2 全额(122 美元)。这个规则和 Windows Server ESU 完全一致。
Azure 上的 Windows 10 VM 也要买 ESU 吗?
不用。运行在 Azure VM、Windows 365 云 PC、Azure Virtual Desktop 会话主机和 Azure Local 上的 Windows 10 客户端从 2025 年 10 月起自动免费获得 ESU 更新,无需 MAK 密钥或额外付费。
MAK 密钥激活次数用完了怎么办?
联系 Microsoft Volume Licensing 支持申请激活次数增补(Reactivation Request),提供订阅号和设备数量证明即可。为避免耗尽,推荐按部门或站点拆分 MAK,用 Intune Assignment Filters 定向下发。