Microsoft 已将 WSUS 弃用。本指南结合真实企业案例，教你把 Windows 客户端迁到 Autopatch、服务器迁到 Azure Update Manager，含 PowerShell 清点脚本、部署环配置与错误码修复。
更新时间：2026 年 8 月 24 日
Microsoft 已于 2024 年 9 月 20 日正式将 Windows Server Update Services (WSUS) 标记为已弃用，官方推荐的替代方案是 Windows Autopatch（用于客户端 Windows 更新）、Microsoft Intune（作为策略控制面）以及 Azure Update Manager（用于服务器）。WSUS 仍会随 Windows Server 2025 一起发布并支持到大约 2035 年，所以这是一次有计划的迁移，不是紧急救火。本指南带你走完评估、试点、批量迁移到最终下线 WSUS 的完整企业流程，也会分享我这几年在客户现场踩过的坑。
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 是冲突高发区。先把"弃用 (deprecated)"这个词说清楚。老实说，光是这个词我在服务台被问了不下三十次。弃用 ≠ 立即移除。Microsoft 的原话是"我们将停止对 WSUS 的功能投资"，也就是说 WSUS 依然会：接收安全更新、继续运行现有的同步与审批工作流、随 Windows Server 2025 一起发布。它不会做的事是：新增功能、支持新的更新类别（例如驱动程序策略）、修复非安全类的重大缺陷。
这一点很关键。我看到不少企业 IT 团队被销售话术吓到，急着在几个月内下线 WSUS。实际情况是：你有大约 3–5 年时间做规划迁移。Microsoft 官方在 2025 年 3 月的补充公告中确认，WSUS 的核心 API 至少支持到 2030 年，Windows Server 2025 的 WSUS 角色随主流支持一起延续到 2029 年 10 月，扩展支持到 2034 年 10 月。
不过，弃用意味着几件事会 立即 影响你的日常运维：
0xC1900208 的功能更新阻断。这是最常见的"人们还问什么" (People Also Ask) 问题。先给出一个清晰的时间轴，我把 Microsoft 公开的关键日期整理成一张表：
| 时间 | 事件 | 对你的影响 |
|---|---|---|
| 2024 年 9 月 20 日 | WSUS 正式弃用 | 无新功能投入，规划迁移的起点 |
| 2025 年 4 月 | Windows 11 24H2 驱动更新分类停发 | 驱动必须走 WUfB / Autopatch |
| 2026 年 6 月 | KB5058497 强制 TLS 1.2 通道 | Server 2012 R2 及以下的 WSUS 客户端断连 |
| 2029 年 10 月 | Windows Server 2025 主流支持结束 | WSUS 角色进入扩展支持 |
| 2034 年 10 月 | Windows Server 2025 扩展支持结束 | WSUS 角色事实上的 EOL |
换句话说，2026 年这一年是"温水煮青蛙"的中段：还没到必须迁移的时候，但云端方案已经在功能上明显领先。如果你的组织有超过 500 台 Windows 客户端，或者跨地区分布，我强烈建议今年就启动 Autopatch 试点。别等到 2028 年再动手，那时候你会同时面对硬件淘汰潮和团队人手紧张。
这是我在客户会议上讲得最多的一张幻灯片。先用一个比喻理清关系：Intune 是策略控制面，Autopatch 是自动化引擎，Azure Update Manager 是服务器专用的补丁调度器。三者并不是替代关系，而是分工协作。
| 特性 | Windows Autopatch | Intune 更新环 | Azure Update Manager |
|---|---|---|---|
| 目标设备 | Windows 10/11 客户端 | Windows 10/11 客户端 | Windows Server + Linux |
| 核心功能 | 自动化环、动态分组、发布保护 | WUfB 策略下发、延迟与截止时间 | 服务器补丁调度、评估、合规 |
| 需要许可证 | Windows E3/E5、Business Premium、A3/A5 | Intune P1 / EMS | Azure Arc（本地服务器免费） |
| Windows 11 支持 | 是（含驱动、固件、M365 Apps、Edge、Teams） | 是（仅质量与功能更新） | 否 |
| 手动审批 | 可选（Autopatch Groups） | 无审批概念（时间驱动） | 有维护配置 |
| 报告位置 | Intune 管理中心 | Intune 管理中心 | Azure Portal |
| 与 WSUS 关系 | 取代 WSUS 客户端角色 | 取代 WSUS 客户端角色 | 取代 WSUS 服务器审批 |
关键点：Intune 本身不存储更新二进制文件，它只保存策略分配。当你保存一条策略后，Intune 会把配置发送给 Windows Autopatch，由 Autopatch 决定哪些更新被批准；设备再直接从 Windows Update CDN 拉取二进制，按 Windows Update 客户端策略安装。这跟 WSUS 那种"本地服务器缓存所有更新包"的模型是根本不同的。
如果你负责的是混合基础设施（桌面走 Intune，服务器一直在 SCCM/ConfigMgr 里管理），那么合理的目标架构是：客户端用 Intune + Autopatch 接管，服务器切换到 Azure Update Manager（通过 Azure Arc 覆盖本地），ConfigMgr 的软件更新点 (SUP) 保留给还没接入 Intune 的老终端做过渡。
做迁移之前最容易翻车的地方，是没搞清楚"WSUS 到底承担了多少事"。我给团队定的规矩是：在动手前必须完成一份三页的清单，涵盖客户端目标、服务器角色、审批工作流、带宽拓扑。下面这段 PowerShell 是我们在 Server 2019/2022 上跑的清点脚本，注释针对一线工程师写得比较详细。
# 需要在 WSUS 主服务器上以管理员权限运行
# 目的：导出当前 WSUS 环境的核心指标，用于迁移规划
Import-Module UpdateServices
# 连接本地 WSUS（如果是远程实例，把参数改成 GetUpdateServer("wsus.corp.local", $false, 8530)）
$wsus = Get-WsusServer
# 1. 客户端总数与操作系统分布
$computers = $wsus.GetComputerTargets()
Write-Host "WSUS 客户端总数: $($computers.Count)"
$computers | Group-Object -Property OSDescription |
Sort-Object Count -Descending |
Select-Object Count, Name |
Format-Table -AutoSize
# 2. 目标计算机组（用于映射到 Intune 动态组）
Write-Host "`n目标组列表:"
$wsus.GetComputerTargetGroups() | Select-Object Name, Id
# 3. 每月同步与审批的更新数量（过去 90 天）
$since = (Get-Date).AddDays(-90)
$approvedRecent = $wsus.GetUpdates() |
Where-Object { $_.CreationDate -gt $since -and $_.IsApproved }
Write-Host "`n过去 90 天审批的更新数: $($approvedRecent.Count)"
# 4. WSUS 数据库和内容目录占用空间（用于评估带宽与存储回收）
$content = Get-WsusServerConfig | Select-Object -ExpandProperty LocalContentCachePath
if ($content -and (Test-Path $content)) {
$sizeGB = [math]::Round(((Get-ChildItem $content -Recurse -Force |
Measure-Object -Property Length -Sum).Sum / 1GB), 2)
Write-Host "`nWSUS 内容目录 ($content) 占用: $sizeGB GB"
}拿到这份清单之后，把它跟你的 Intune 现状对照。重点回答四个问题：（1）有多少客户端已经加入 Microsoft Entra 并被 Intune 管理？（2）有多少还在纯本地 AD？（3）目前的 WSUS 计算机组对应的组织单元 (OU) 是否已经在 Entra 里有对应的动态组？（4）现有 GPO 里有多少条 Windows Update 相关设置？最后这条是隐藏地雷。
下面是我在过去 18 个月里带 4 家企业客户走过的标准迁移路径。从签到 Autopatch 到最终关掉 WSUS 一般需要 10–14 周。别指望一个周末就搞定，每个环 (ring) 都需要至少一个完整补丁周期来验证。
Autopatch 需要以下之一：Windows 11/10 Enterprise E3/E5、Windows 365 Enterprise、Microsoft 365 Business Premium、A3/A5 或 F3。你还需要 Intune Plan 1（或 EMS E3+）以及 Microsoft Entra ID（免费层即可）。在 Intune 管理中心访问 Devices → Windows updates → Autopatch groups，如果许可证不足，界面会直接给出错误代码 APT-A0100。
设备必须：由 Intune 作为主要 MDM 管理（或共同管理时把 Windows Update 工作负载切换到 Intune）；企业所有（BYOD 明确被排除）；过去 28 天内至少与 Intune 通信过一次；加入 Microsoft Entra（纯本地 AD 的设备需要走 Autopilot 混合加入）；诊断数据设为 Required；运行 Windows 10 22H2 或 Windows 11 22H2 及以上。
2026 年的注册流程比早期版本简单：在 Intune 管理中心 → Tenant administration → Autopatch → Tenant enrollment，运行准备就绪检查 (readiness check)，通过后一键注册。之后创建 Autopatch Group，把 Entra 动态设备组绑到 Pilot/UAT/Production 三个环。示例动态成员规则（面向 Windows 11 的公司 PC 试点）：
# Entra ID 动态组规则语法
# 目标：企业所有的 Windows 11 设备，且名称以 PILOT- 开头的进入试点环
(device.deviceOSType -eq "Windows") -and
(device.deviceOSVersion -startsWith "10.0.26") -and
(device.deviceOwnership -eq "Company") -and
(device.displayName -startsWith "PILOT-")这一步几乎是 100% 的翻车重灾区。我在上一家客户那里就是被它绊倒的，PowerShell 扫出来 27 条 WU 相关的 GPO 都在悄悄地跟 MDM 打架。任何位于 HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 下的 GPO 会覆盖 MDM 下发的策略。用下面的 PowerShell 快速扫描组策略中央存储里所有 WU 相关的 ADMX：
# 在域控上运行；也可以在带 GPMC 的成员服务器上运行
# 目的：列出所有配置了 Windows Update 设置的 GPO，方便迁移前禁用
Import-Module GroupPolicy
$wuGpos = Get-GPO -All | ForEach-Object {
$report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
if ($report.GPO.Computer.ExtensionData.Extension.Policy.Name |
Where-Object { $_ -match "WindowsUpdate|WUfB|DeliveryOptimization" }) {
[PSCustomObject]@{
GpoName = $_.DisplayName
GpoId = $_.Id
LastMod = $_.ModificationTime
}
}
}
$wuGpos | Format-Table -AutoSize
# 建议：把这些 GPO 的 WU 相关设置改为"未配置"，让 Intune 策略接管不要一上来就删 WSUS 服务器。合理做法是把 GPO 里的 Specify intranet Microsoft update service location 逐环解绑（先从 Pilot 组解绑），让设备回落到 Windows Update CDN。观察一个补丁周期，确认没有出问题，再对下一个环解绑。这种"渐进拆桥"的做法看着慢，但真的能救命。
在 Intune → Reports → Windows updates → Windows Autopatch 观察合规率。目标是 Pilot 环 > 95%、UAT > 90%、Production > 85% 的合规率持续 30 天以上。达标后就可以停止 WSUS 服务、卸载角色、回收内容目录空间。别忘了备份 SUSDB 数据库，万一后面要回溯审批历史（合规审计常会问到），这份备份就是唯一的凭证。
关于部署环，我的信条是"小步慢跑，能回滚"。Autopatch 默认给你四个环（Test、First、Fast、Broad），但对大多数中型企业来说三环够用。下面是我推荐的默认配置：
| 环 | 设备占比 | 质量更新延迟 | 功能更新延迟 | 安装截止时间 | 活动时间 |
|---|---|---|---|---|---|
| Pilot | 1–5% | 0 天 | 0 天 | 2 天 | 07:00–19:00 |
| UAT | 10–15% | 7 天 | 30 天 | 7 天 | 08:00–18:00 |
| Production | 80–85% | 14 天 | 60 天 | 7 天 | 08:00–18:00 |
几条我踩过坑总结出来的经验：
可以，但要小心。共存不是长期方案，是过渡期的桥梁。共存有三种典型模式：
共存时的关键陷阱是 MDM Wins for Update / Windows Update 工作负载切换开关。在共同管理场景下，如果你把 Windows Update 工作负载切到 Intune，那么 WSUS 的审批对这些设备就完全失效了，即使它们仍然在 SCCM 集合里。这个切换只能整台设备做，不能按更新类别做。所以务必先确认哪些设备"归 Intune 管"、哪些"归 SCCM/WSUS 管"，别留中间态。
如果你的服务器补丁流程里还依赖 WSUS 做审批（一个非常常见的场景），可以让 WSUS 继续为服务器工作，同时把客户端切到 Autopatch。两者用不同的 GPO OU 分开就行。
Windows Server 的补丁管理是 WSUS 弃用后最容易被忽略的一块。Microsoft 的官方建议是 Azure Update Manager (AUM)，一个基于 Azure 的原生服务，可以通过 Azure Arc 覆盖本地和其他云上的 Windows Server 与 Linux。
本地服务器要接入 AUM，需要在每台服务器上安装 Azure Connected Machine agent。下面这段命令是我常用的一键部署脚本，可以从任意管理机通过 WinRM 推送：
# 在每台目标 Server 上运行（可用 Invoke-Command 批量下发）
# 目的：把本地 Server 接入 Azure Arc，之后就能被 Azure Update Manager 管理
$tenantId = "<YOUR-TENANT-ID>"
$subId = "<YOUR-SUBSCRIPTION-ID>"
$resGroup = "rg-arc-onprem"
$region = "eastasia"
# 1. 下载并安装 Connected Machine agent
Invoke-WebRequest -Uri "https://aka.ms/AzureConnectedMachineAgent" `
-OutFile "$env:TEMP\AzureConnectedMachineAgent.msi"
Start-Process msiexec.exe -ArgumentList "/i $env:TEMP\AzureConnectedMachineAgent.msi /qn" -Wait
# 2. 使用服务主体注册（比设备代码流更适合自动化）
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect `
--service-principal-id "<SP-APP-ID>" `
--service-principal-secret "<SP-SECRET>" `
--tenant-id $tenantId `
--subscription-id $subId `
--resource-group $resGroup `
--location $region `
--cloud "AzureCloud"
# 3. 验证 agent 状态（Connected 表示成功）
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" show接入后，在 Azure Portal → Update Manager → Machines 里可以看到这台服务器。你可以立即触发一次 Check for updates，之后配置 Maintenance configuration 来定义补丁窗口。AUM 对本地 Windows Server 的补丁评估目前是免费的，只有开启定期评估和维护窗口时按 Arc 定价计费（$5/服务器/月，2026 年 8 月定价）。
无论是 WSUS 时代还是 Autopatch 时代，Windows Update 客户端都会吐一堆神秘的十六进制错误码。下面是我服务台仪表板里 2026 年出现频率最高的几个，附上真人能看懂的解释：
| 错误代码 | 含义 | 典型修复 |
|---|---|---|
| 0x8024401c | 客户端到 WSUS/CDN 的连接超时 | 检查代理、防火墙、TLS 1.2；重启 wuauserv |
| 0x80244022 | 后端返回 HTTP 503/502 | WSUS IIS 应用池 WsusPool 私有内存达上限；调至 > 14 GB |
| 0x80070422 | BITS 或 Windows Update 服务被禁用 | sc config bits start= auto && net start bits |
| 0xC1900208 | 兼容性阻止（含 Copilot+ 硬件不受 WSUS 支持） | 切换到 Autopatch 或 WUfB；查看 setupdiag 报告 |
| 0x800f0922 | 系统保留分区空间不足 | 扩展 System Reserved 到 500 MB+；或临时挂载 EFI 分区清理 |
| APT-A0100 | Autopatch 注册许可证不足 | 确认租户至少一个用户持有 Windows E3+ 或 Business Premium |
| APT-A0300 | 诊断数据级别过低 | 把 Allow Telemetry 设为 Required (1) 或以上 |
对客户端侧的通用排查，我随身带的一段脚本如下（面向一线工程师，注释详细）：
# 在有问题的 Windows 客户端上以管理员运行
# 目的：一次性检查 Windows Update 客户端健康度并给出下一步建议
Write-Host "==== Windows Update 客户端体检 ====" -ForegroundColor Cyan
# 1. 关键服务状态（BITS + wuauserv + UsoSvc）
Get-Service -Name BITS,wuauserv,UsoSvc,cryptsvc |
Format-Table Name,Status,StartType -AutoSize
# 2. 最近 10 次 WU 事件（错误优先）
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" `
-MaxEvents 10 | Select-Object TimeCreated,LevelDisplayName,Id,Message |
Format-Table -AutoSize -Wrap
# 3. 当前 WU 目标源（Autopatch 应该显示 https://* CDN，WSUS 显示内网地址）
$reg = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
if (Test-Path $reg) {
Get-ItemProperty $reg | Select-Object WUServer,WUStatusServer,UseWUServer
} else {
Write-Host "无 WSUS 策略生效，客户端应走 Windows Update CDN"
}
# 4. MDM 通道健康度
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
Where-Object State -eq "Ready" | Measure-Object |
Select-Object @{n="MDM 计划任务数";e={$_.Count}}
# 5. 快速触发一次扫描
Write-Host "`n触发扫描..." -ForegroundColor Yellow
UsoClient StartScan
Start-Sleep 30
Get-WindowsUpdateLog -LogPath "$env:TEMP\WU-$(Get-Date -Format yyyyMMdd-HHmm).log" | Out-Null
Write-Host "日志已导出到 $env:TEMP\WU-*.log" -ForegroundColor Green许可证方面还有两个易忽略的点：（1）如果你混用 Windows 10 E3 加 Business Premium，Autopatch 只对持有正确许可证的用户主账号生效，共享设备场景下要用 Windows Enterprise E3 per Device。（2）Autopatch 的驱动更新与固件更新需要 Windows E5，E3 只有基础的质量与功能更新自动化。我见过太多客户以为买了 E3 就能全用，实际部署时才发现驱动策略不生效。想深入了解 KB 分类和 SSU 打包逻辑，可以参考我之前的 Windows 11 企业更新故障排查指南。
没有。WSUS 于 2024 年 9 月被 Microsoft 声明"已弃用 (deprecated)"，意味着不再有新功能投入，但安全更新与基本工作流会继续。Windows Server 2025 的 WSUS 角色扩展支持到 2034 年 10 月。
Windows 11/10 Enterprise E3 或 E5、Microsoft 365 Business Premium、Windows 365 Enterprise、教育版 A3/A5 或前线员工 F3 之一，加上 Intune Plan 1。驱动和固件更新的自动化要求 Windows E5。
Intune 更新环是 WUfB 策略的直接下发面，你手动定义所有延迟与截止时间。Autopatch 在其上叠加了自动化：动态环分组、发布保护、Microsoft SRE 介入的信号响应，以及对 M365 Apps、Edge、Teams 更新的原生支持。两者不应叠加使用。
可以，但只作为过渡策略。常见做法是按部署环、更新类别或设备类型逐步切换。混合环境要特别注意冲突的 GPO，注册表 HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 下的 GPO 会覆盖 MDM 策略。
企业环境典型周期是 10–14 周，包含许可证与先决条件确认（1–2 周）、Autopatch 注册与 Pilot 环（2 周）、UAT 环验证（3–4 周）、Production 分批切换（4–6 周）。少于 500 台设备的小型环境可以压缩到 6 周。