更新记录(仅首版,2026年08月01日 发布)
- 首次发布
引用本文(DOI(已登记存档): 10.5281/zenodo.22175522)
以下 DOI 指向先前登记的存档,内容可能与当前正文不同。引用当前正文时,请使用本页网址。
Go Komura(2026)。《WSUS 弃用后的 Windows Update 管理——WUfB、Autopatch、Intune 该怎么选》。小村软件有限公司。 https://comcomponent.com/zh-CN/blog/wsus-deprecation-windows-update-management/
- DOI(已登记存档)
- 10.5281/zenodo.22175522
- DOI(上次登记版本)
- 10.5281/zenodo.22175523
“听说 WSUS 已经被弃用了,我们的 WSUS 服务器还能用到什么时候?”“趁着更换服务器的时机,WSUS 是该重建还是该放弃?”“我们现在既没有 WSUS 也没有别的东西,各台电脑的更新都交给 Windows Update 自己处理,这样下去可以吗?”——在承接Windows 10 停止支持的应对咨询的过程中,被一并问到的就是这类问题,而且越来越多。
2024 年 9 月,Microsoft 宣布 WSUS(Windows Server Update Services)弃用。不过,“弃用(deprecated)”这个词很容易被误解:既不必急着断定“已经不能用了”而慌张,也不能因为“反正还在跑,跟我无关”而不管。准确的说法是“不再开发新功能,但短期内会继续运行”,真正要回答的不是撤除的期限,而是下一代更新管理放在哪里这个设计判断。
本文面向一直用 WSUS 管理公司内部电脑更新(或者干脆没人管、任由 Windows Update 处理)的中小企业信息系统负责人,把(1)继续用 WSUS、(2)Windows Update for Business(WUfB)、(3)Windows Autopatch、(4)基于 Intune 的云端管理这四个选项整理成判断表。内容依据截至 2026 年 8 月的一手资料。作为承接业务应用开发的公司,本文也会用一节篇幅讲如何为更新引发的应用故障做准备。
1. 先说结论
- WSUS 已在 2024 年 9 月 20 日被宣布弃用。其含义是“终止新功能的开发与新功能需求的受理”。现有功能仍然保留,更新程序也继续通过 WSUS 通道发布。12
- 弃用不等于立刻停摆。Windows Server 2025 同样内置 WSUS 角色,生产环境的支持以及安全更新、质量更新会按照产品生命周期继续提供。删除日期尚未公布。32
- 驱动程序同步曾被预告“2025 年 4 月 18 日终止”,但在 2025 年 4 月 4 日被撤回。原因是收到封闭网络等断网环境的反馈,目前同步仍在继续。45
- 后继者的首选是 WUfB。它现在的正式名称是 Windows Update client policies,只要是 Pro、Education、Enterprise 系列版本就无需额外费用。既能从 GPO 配置也能从 Intune 配置,不需要分发服务器(Home 不在范围内)。6
- WUfB 的实质是“推迟与更新环”。用策略配置质量更新最长 30 天、功能更新最长 365 天的推迟以及最长 35 天的暂停,组成从试点到全公司的分波次推送。67
- 对带宽的担忧,答案是传递优化(Delivery Optimization)。它让同一网络内的电脑之间以 P2P 方式共享更新,在 Pro/Enterprise/Education 上默认启用。8
- Windows Autopatch 是在 WUfB 之上把审批、排期、保护自动化的云服务。截至 2026 年,Microsoft 365 Business Premium 也能使用,前提是 Entra ID P1/P2 和 Intune。9
- 在封闭、离线环境中 WSUS 仍是现实的解法。但要划出“继续用,但不再新增投资”这条线,并写进资产台账和未来规划。25
图中实线表示始终成立的关系,虚线表示带条件的关系(成立条件写在详情页各关系的说明中)。关系的完整列表(共 36 条,附依据与确信度)以及主要概念的定义,汇总在知识地图详情页(日文)。数据:JSON-LD / Turtle
2. WSUS 到底发生了什么——“弃用”的准确含义
先按时间顺序把事实理清。
- 2024 年 6 月:预告 WSUS 的驱动程序同步将于 2025 年 4 月 18 日终止。4
- 2024 年 9 月 20 日:在 Windows IT Pro Blog 上宣布 WSUS 本体弃用。停止开发新功能,也不再受理新的功能需求。但明确表示保留现有功能,继续通过 WSUS 通道发布更新,并继续支持已发布的内容。1
- 2025 年 4 月 4 日:撤回驱动程序同步的终止预告。在收到在断网环境(封闭网络)中运维的组织的反馈后,宣布继续从 Windows Update/Microsoft 更新目录同步驱动程序。5
Microsoft Learn 的现行文档把 WSUS 的状态描述为“已弃用、不会再增加新功能,但生产环境的支持继续有效,并按照产品生命周期获得安全更新和质量更新”。2 另外,WSUS 确实出现在 Windows Server 2025 的弃用功能清单里,但那里的定义也是“已弃用的组件仍会随 Windows Server 一同提供,并在生产部署中获得支持”。实际上 Windows Server 2025 里仍有 WSUS 角色,文档写明“现有的功能和内容仍可继续使用”。3
也就是说,截至 2026 年 8 月的实际情况是,同步和分发都没有停。另一方面,也有一些周边动向值得留意。WSUS 默认使用的数据库 Windows Internal Database(WID)也在 Windows Server 2025 中被明确标为已弃用、将来会删除。3 意思是兼容性的前提有可能先从配套组件那一侧崩掉,而不是从本体开始。
从这里能引出的实务界线很清楚:不必按“明天就停”的前提慌张,但不要再做以 WSUS 为中心的新增投资(服务器更新换代、增设副本、定制开发)。服务器的更换周期,正好是重新审视更新管理的天然截止时间。
3. 选项的全貌——四条路各自的位置
考虑“WSUS 之后”时,角色不同的选项很容易被混在一起。先梳理清楚。
| 选项 | 实质 | 分发路径 | 额外费用 | 与本地 AD 的 GPO 运维的延续性 |
|---|---|---|---|---|
| 继续用 WSUS | 本地的同步与分发服务器 | 由 WSUS 服务器分发 | 服务器维护费用 | 原样不动(维持现状) |
| WUfB | 用策略控制推迟与更新环 | 由 Windows Update 直接分发 | 无(Pro 以上)6 | 高(只用 GPO 就能迁移)7 |
| Windows Autopatch | 把更新的审批、部署、保护自动化的云服务 | 由 Windows Update 直接分发 | 包含在对应许可中9 | 低(以 Entra ID + Intune 为前提)9 |
| Intune(云端管理) | 设备管理平台,更新环是它的一项功能 | 由 Windows Update 直接分发 | Intune 许可 | 低(连管理平台一起迁移) |
可以看出,WUfB、Autopatch、Intune 这三者不是互相对立的选项,而是层层叠加的。底座是 WUfB 的那批策略,用 GPO 来写就是“单用 WUfB”,用 Intune 的更新环来写就是“Intune 管理”,再把审批、排期、暂停部署也交给服务去做就是“Autopatch”。实际上,Microsoft 就把 Autopatch 定位为“与 WUfB(Windows Update client policies)协同工作的云服务”。6
flowchart TB
AP["Windows Autopatch<br/>自动完成环的编排、部署监控与暂停判断"] --> WUFB
WUFB["WUfB 的那批策略(推迟、暂停、期限)<br/>= Windows Update client policies"] --> WU["由 Windows Update 直接分发<br/>(无分发服务器)"]
GPO["用 GPO 配置<br/>(本地 AD)"] -.->|"写法一"| WUFB
INTUNE["用 Intune 的更新环配置<br/>(云端管理)"] -.->|"写法二"| WUFB
所以,中小企业的判断实际上可以拆成两步。(1)要不要把分发从 WSUS 换成 Windows Update 直接分发。(2)策略放在本地 AD(GPO)不动,还是搬到 Intune。如果公司仍在本地 AD 上做 GPO 运维,那么只先推进(1)——也就是用 GPO 配置 WUfB——延续性最好。
另外,WSUS 覆盖过的Windows Server 自身的更新管理是另一个问题。Windows Server 不从 Windows Update 接收功能更新,因此 WUfB 的策略只对质量更新起作用。7 服务器台数不多的中小企业,现实做法是服务器部分继续用 WSUS 或手工处理,先把客户端电脑迁到云端分发。
4. Windows Update for Business——无额外费用的首选
WUfB 的机制一句话就能说清:“不自建分发服务器,用策略驯服来自 Windows Update 的直接分发。”
- 适用版本:Windows 10/11 的 Pro(含 Pro for Workstations)、Education、Enterprise(含 LTSC、IoT Enterprise)。Home 不在范围内。不收额外费用。6
- 配置手段:组策略和 MDM(例如 Intune)都支持。GPO 的位置在
计算机配置\管理模板\Windows 组件\Windows 更新下面,质量更新的推迟对应“Select when Quality Updates are received”,功能更新的推迟对应“Select when Preview Builds and feature updates are received”策略。在 Intune/MDM 侧则使用Update/DeferQualityUpdatesPeriodInDays等策略 CSP。7 - 可推迟的天数:质量更新(基本上是每月第二个星期二)最长 30 天,功能更新(每年一次)最长 365 天。此外还有出问题时停下分发的暂停,最长 35 天(从开始日算起,到期后自动恢复)。67
- 可纳入管理的更新种类:除功能更新、质量更新之外,还能控制驱动程序更新(默认启用,可用
ExcludeWUDriversInQualityUpdate排除)以及 Office 等其他 Microsoft 产品的更新(默认关闭,用AllowMUUpdateService启用)。7 - 期限与宽限:除推迟之外,还有一类策略用来规定更新发布后多少天之内必须安装、安装后多少天之内必须重启,即合规期限加宽限期。“永远不重启的电脑”的答案就在这里。6
更新环的设计思路
相当于 WSUS 里“审批”的东西,是推迟天数不同的环(波次)。Microsoft 自己也设想了这种用法:建立推迟期不同的组,先在小范围确认质量,再扩大到全体。7 例如下面这三个环可以作为起点。
| 更新环 | 对象 | 质量更新的推迟 | 目的 |
|---|---|---|---|
| 试点 | 信息部门 + 各部门的代表机(全体的 5~10%) | 0~3 天 | 包含业务应用的实地验证 |
| 先行 | 对影响容忍度较高的部门 | 7 天左右 | 发现试点覆盖不到的配置差异 |
| 全公司 | 其余全部 | 14 天左右 | 出问题时用暂停(最长 35 天)刹住 |
与“不按审批按钮就不会下发”的 WSUS 不同,WUfB 是放着不管也会按期限下发的机制。理解起来最快的说法是:管理的重心从“下发这项工作”变成了“何时刹车的判断”。
flowchart LR
PUB["更新发布<br/>(每月的质量更新等)"] --> P["试点<br/>推迟 0~3 天"]
P -- "无问题" --> S["先行<br/>推迟 7 天左右"]
S -- "无问题" --> A["全公司<br/>推迟 14 天左右"]
P -- "有问题" --> PAUSE["用暂停(最长 35 天)<br/>拦住向全公司的扩大"]
S -- "有问题" --> PAUSE
PAUSE --> FIX["排查是改应用<br/>还是在策略侧排除"]
FIX --> RESUME["解决后恢复"]
带宽的担忧交给传递优化
一旦不用 WSUS,所有电脑都会到互联网上取更新,站点的线路自然让人担心。回答这个问题的是传递优化(Delivery Optimization)。它让同一网络内的电脑之间以 P2P 方式分享已下载的更新包,在 Pro、Education、Enterprise 上默认启用本地网络内的对等共享。适用范围很广,除了 Windows Update 的功能更新、质量更新、驱动程序,还包括商店应用、Microsoft Defender 的定义更新、Microsoft 365 Apps 等。8 Microsoft 内部的部署报告称,超过 76% 的内容是从对等端而不是互联网取得的。8 如果还想进一步收紧,也可以选择部署专用缓存服务器的 Microsoft Connected Cache。8
5. Windows Autopatch——把“更新运维本身”交出去
即使配好了 WUfB,环的设计、部署状况的监控、出问题时的暂停判断仍然是自己的活。把这部分运维也交给服务去做的就是 Windows Autopatch,它把 Windows Update 分发的更新的审批、排期、保护(检测到问题时控制部署)自动化。6 Autopatch 组与更新环的自动编排、质量更新与功能更新以及驱动程序/固件更新的部署管理、部署状况的报表,是它的主要内容。9
截至 2026 年,必要条件如下。9
- 许可:Microsoft 365 Business Premium、Windows 10/11 Education A3/A5、Windows 10/11 Enterprise E3/E5(包含在 Microsoft 365 F3/E3/E5 中)、Enterprise E3/E5 VDA 中的任意一种。已经不像过去那样只限 E3,但不同许可层级能用的功能有差别,向 Microsoft 提交支持请求的功能仅限 E3 以上和 F3。
- 平台:必须有 Microsoft Entra ID P1/P2 和 Microsoft Intune。设备必须是已在 Intune 中注册(也可与 ConfigMgr 共同管理)的公司自有电脑,并且在最近 28 天内与 Intune 通信过。只有本地 AD 的环境无法使用(Entra 混合加入则可以)。
- 适用系统:Windows 10/11 的 Pro、Education、Enterprise 系列版本,正式发布(GA)通道。LTSC 只支持质量更新的管理。
对中小企业来说,现实性可以这样归纳。如果已经在用 Business Premium,并且电脑已由 Intune 管理(或者将要管理),那么 Autopatch 就是一层零额外费用即可加上的自动化。反过来,对只靠本地 AD 和 GPO 运转的公司,引入 Autopatch 就等于一个迁移到 Entra ID 加 Intune 的项目,仅为更新管理而下这个决心是不成比例的。这种情况下自然的顺序是:先用 GPO 迁到 WUfB,等到哪天要转向云端管理时再考虑 Autopatch。
6. 判断表——什么样的公司选什么
把前面的内容汇总到一页。先用流程图确认大的分叉,细节再看表。
flowchart TB
Q1{"是不是封闭或离线网络"} -- "是" --> WSUS["继续用 WSUS<br/>做成有台账加复查期限的受管理例外"]
Q1 -- "不是" --> Q2{"电脑是否由 Intune 管理<br/>(或计划迁移)"}
Q2 -- "不是(本地 AD + GPO)" --> GPO["用 GPO 配置 WUfB<br/>无额外费用、延续性最好"]
Q2 -- "是" --> Q3{"是否有 Business Premium<br/>或 E3 以上的许可"}
Q3 -- "有" --> AP["Windows Autopatch"]
Q3 -- "没有" --> RING["Intune 的更新环(WUfB)"]
| 情况 | 推荐 | 理由与备注 |
|---|---|---|
| 有处于封闭或离线网络的电脑(工厂、检测设备等) | 继续用 WSUS | 云端分发在物理上不成立。驱动程序同步也仍在继续5。要配上台账管理和期限 |
| 本地 AD + GPO 运维,没有转云端管理的计划 | WUfB(用 GPO 配置) | 无额外费用、可以撤掉分发服务器。管理上的延续性最高7 |
| 已签 Microsoft 365 Business Premium,正在或已经迁到 Intune 管理 | Autopatch(或 Intune 更新环) | 已包含在许可里,还能顺带获得运维自动化9 |
| 已签 Enterprise E3/E5(M365 E3/E5) | Autopatch | 可以用上包含向 Microsoft 提交支持请求在内的完整功能9 |
| 电脑只有几台到十几台,实际上没有管理员 | 不要硬建 WSUS。用 Windows Update 默认设置 + 盘点 | 管理的空白才是最大的风险。先从全机升级到 Pro 和清点资产做起 |
| Windows Server 自身的更新管理 | 继续用 WSUS 或单独处理 | WUfB 处理不了功能更新(只有质量更新策略)7 |
补两条注意事项。第一,只要混着 Home 版,就上不了 WUfB 这个台子。6 小企业里“买来时就是 Home”的电脑并不少见,迁移计划的第一项工作其实是盘点版本。第二,留下封闭网络里的 WSUS 这个判断“客观看是合理的”,但已被弃用的事实不会改变。这和已停止支持的 Windows 10 的隔离运维一样,写进台账、定下复查期限之后,才算是受管理的例外。
7. 迁移实务——从 WSUS 搬到 WUfB 的要点
从 WSUS 切换到 WUfB 时,技术上最容易栽跟头的地方是新旧策略混在一起。先给出整体流程。
flowchart TB
A["1. 盘点全部 GPO 的策略<br/>(WSUS 指定、自动更新、推迟类)"] --> B["2-3. 用扫描源策略<br/>按更新种类明确获取来源"]
B --> C["4. 明确功能更新的推迟与目标<br/>版本(避免误升级到 Windows 11)"]
C --> D["5. 从试点开始依次撤掉 WSUS 指定<br/>并应用 WUfB 策略(并行 1~2 个月)"]
D --> E["6. 全部切换后观察一个周期<br/>再关停 WSUS 服务器(封闭网络用的记入台账)"]
步骤的细节如下。
- 盘点当前的策略。把 WSUS 服务器指定(指定 Intranet Microsoft 更新服务位置)、自动更新的配置、过去设过的推迟类策略这三类,从全部 GPO 里翻出来。
- 认清双重扫描这个陷阱。在 Windows 10 上,WSUS 服务器指定和推迟策略共存时,扫描目标会切换到 Windows Update(即所谓双重扫描),而曾经抑制这一行为的旧策略在Windows 11 中不受支持。10
- 用扫描源策略明确指定。现在的正规做法是
计算机配置\管理模板\Windows 组件\Windows 更新\管理从 Windows Server Update Service 提供的更新下的“Specify source service for specific classes of Windows Updates”,按功能更新、质量更新、驱动程序、其他 Microsoft 产品这四个分类,分别指定获取来源是 WSUS 还是 Windows Update(MDM 侧要把SetPolicyDrivenUpdateSourceFor~这四个策略全部设上)。Microsoft 自己也推荐在从本地管理向云端迁移的过渡期采用“先只把驱动程序放到云端”这样的分阶段迁移。10 - 留意 Windows 11 的意外升级。如果保持 WSUS 配置而不设置功能更新的扫描源或提供策略,用户点“联机检查更新程序”时有可能看到升级到 Windows 11 的提示。10 正是在过渡期,要把功能更新的推迟(最长 365 天)和目标版本指定明确写上。
- 建好更新环再切换。准备好第 4 节的三个环,从试点的 OU/组开始依次撤掉 WSUS 指定,应用 WUfB 策略。用 1~2 个月的并行期确认传递优化的效果(对等取得率)和线路负载,再推广到全公司。
- 关停 WSUS 服务器。全部客户端切换完成后,服务器不要马上删掉,观察一个周期(一个月)再停。如果要为封闭网络保留,就把角色限定在那里并记入台账。
8. 业务应用一侧的视角——不让更新拖停业务
站在承接开发的立场,更新管理方式变更时真正要守住的,不只是“补丁打上了”,而是补丁打上之后业务应用还能继续跑。IPA 的《信息安全 10 大威胁》里,修补程序的应用也一直排在基础对策的第一位(“《信息安全 10 大威胁 2026》的正确解读方式”)。不让应用中断的机制,和不被应用打坏的准备,是一对轮子。
- 试点环里一定要放“业务应用的代表机”。Office 版本、报表工具、设备连接等配置各不相同的电脑各挑一台,确认更新后业务能走完一轮。更新环不只是为信息部门服务的,它同时也是应用验证的机制。
- 把应用做成、也运维成能扛住重启的样子。更新的收尾一定是重启。正在使用的文件如何替换、应用如何自动恢复,见“Restart Manager 与自动更新的“文件被占用”问题”;夜间更新与常驻应用、长时间运行应用的关系,见“睡眠、休眠、Modern Standby 与长时间运行应用”。
- 顺便把应用侧的分发也重新审视一遍。既然要把操作系统更新挪到云端分发,那也正是把业务应用和周边工具的分发从手工挪向脚本化、包管理的好时机。用 winget 自动化装机的做法汇总在“用 winget 和 PowerShell 自动化 PC 装机”。
- 事先定好“更新后跑不起来”的排查步骤。先用暂停(最长 35 天)拦住向全公司的扩大,然后在试点机上复现,再判断是改应用还是在策略侧排除(例如排除驱动程序)——把这个流程提前定下来,出故障的当天就不会犯迷糊。
9. 总结
- WSUS 的弃用(2024 年 9 月 20 日发布)意思是“新功能开发终止”,同步和分发在 2026 年 8 月仍然在跑。驱动程序同步经过撤回也仍在继续。不必慌张,但已经到了停止向 WSUS 新增投资的时候。
- 后继者的首选是无额外费用的 WUfB(Windows Update client policies)。用 GPO 或 Intune 配置质量更新 30 天、功能更新 365 天的推迟和 35 天的暂停,再用更新环做分波次推送。Home 版不在范围内。
- 带宽问题由传递优化(默认启用的 P2P 共享)来回答。即便没有 WSUS 的分发服务器,线路也比想象中守得住。
- Autopatch 是 WUfB 的运维自动化。一方面它现在连 Business Premium 也能用,另一方面它以 Entra ID 加 Intune 为前提,对只有本地 AD 的公司是个遥远的选项。用 GPO 迁到 WUfB,才是延续性最好的第一步。
- 迁移在技术上的难关是理清策略的混杂。请用扫描源策略按更新种类明确获取来源,再分阶段切换。
- 在封闭网络中 WSUS 仍是现实的解法。但请把它作为配有台账和复查期限的“受管理的例外”留下来。
- 更新管理的目的不是覆盖率,而是业务连续性。把业务应用的代表机放进试点环,再把能扛住重启的设计与运维也一并做到,才算完成。
相关文章
- Windows 10 停止支持后的现实解法——ESU、LTSC、换机的判断表
- 信息安全 10 大威胁 2026——排行榜的正确解读方式,以及中小企业真正该防的东西
- 正在使用的 exe/DLL 该怎么替换——Restart Manager 与自动更新的“文件被占用”问题
- 用 winget + PowerShell 自动化 PC 装机——让操作手册变得可执行
- 睡眠、休眠、Modern Standby 与长时间运行应用——用设计防住“夜里已经停了”
- VB6 / Access 业务应用的延寿与迁移——保留、封装、替换的判断表
相关咨询领域
小村软件有限公司承接与更新管理“应用侧”相关的技术咨询,包括 Windows Update 应用后业务应用的故障排查、能扛住更新与重启的应用设计(支持 Restart Manager、自动恢复),以及公司内部电脑运维的自动化脚本建设。从“每次更新都替那个应用悬着心”这种阶段的咨询开始也没问题。
参考链接
-
Microsoft Windows IT Pro Blog, Windows Server Update Services (WSUS) deprecation。关于 2024 年 9 月 20 日宣布 WSUS 弃用,以及在终止新功能开发与新功能需求受理的同时,保留现有功能、继续通过 WSUS 通道发布更新程序并继续支持已发布内容。 ↩ ↩2
-
Microsoft Learn, Windows Server Update Services (WSUS) Overview。关于 WSUS 已弃用、不再增加新功能,但生产环境的支持继续有效,并按照产品生命周期获得安全更新和质量更新。 ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Features Removed or No Longer Developed in Windows Server。关于 WSUS 被列入 Windows Server 2025 的弃用功能清单并写明“现有的功能和内容仍可继续使用”,关于已弃用组件仍随 Windows Server 一同提供、在生产部署中获得支持并按产品生命周期获得安全更新与质量更新这一定义,以及关于 WSUS 使用的 Windows Internal Database(WID)同样已弃用、将来会删除。 ↩ ↩2 ↩3
-
Microsoft Windows IT Pro Blog, Deprecation of WSUS driver synchronization。关于 2024 年 6 月曾预告 WSUS 的驱动程序同步将于 2025 年 4 月 18 日终止。 ↩ ↩2
-
Microsoft Windows IT Pro Blog, Continuing WSUS support for driver synchronization。关于 2025 年 4 月 4 日在收到在断网环境(封闭网络)中运维的组织的反馈后,撤回上述终止预告,宣布继续把驱动程序更新同步到 WSUS。 ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Windows Update client policies。关于 Windows Update client policies(旧称 Windows Update for Business)是 Windows 10/11 的 Pro(含 Pro for Workstations)、Education、Enterprise(含 LTSC、IoT Enterprise)可用的免费功能,关于功能更新最长 365 天、质量更新最长 30 天的推迟与 35 天的暂停,关于驱动程序更新默认启用、其他 Microsoft 产品的更新默认关闭,关于合规期限与宽限期的策略,以及关于 Windows Autopatch 被定位为对 Windows Update 分发的更新追加审批、排期、保护控制的云服务。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
Microsoft Learn, Configure Windows Update client policies。关于推迟与暂停的组策略(Windows 更新下的“Select when Quality Updates are received”“Select when Preview Builds and feature updates are received”等)与策略 CSP(DeferQualityUpdatesPeriodInDays、DeferFeatureUpdatesPeriodInDays、ExcludeWUDriversInQualityUpdate、AllowMUUpdateService 等)的对应关系,关于暂停从开始日起 35 天自动到期,关于建立推迟期不同的组、从用于验证的小范围开始分阶段推广的用法,以及关于 Windows Server 不从 Windows Update 接收功能更新、只应用质量更新策略。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
Microsoft Learn, What is Delivery Optimization?。关于传递优化把点对点与 Microsoft Connected Cache 结合到 HTTP 下载器上以抑制带宽消耗的机制,关于 Enterprise、Pro、Education 默认启用同一本地网络(同一 NAT 之下)的对等共享,关于它支持 Windows Update 的功能更新、质量更新、驱动程序以及商店应用、Defender 定义更新、Microsoft 365 Apps 等,关于它可以与 Windows Update、WSUS、Intune、Configuration Manager 并用,以及关于 Microsoft 内部部署中超过 76% 的内容是从对等端取得的。 ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Windows Autopatch Prerequisites。关于 Windows Autopatch 可用于 Microsoft 365 Business Premium、Windows 10/11 Education A3/A5、Windows 10/11 Enterprise E3/E5(包含在 Microsoft 365 F3/E3/E5 中)、Enterprise E3/E5 VDA,关于支持请求功能仅限 E3 以上和 F3,关于必须具备 Microsoft Entra ID P1/P2 和 Microsoft Intune 且设备必须是已在 Intune 中注册(可共同管理)的公司自有设备并在最近 28 天内与 Intune 通信过,以及关于适用对象为 Pro、Education、Enterprise 系列版本的正式发布通道而 LTSC 只支持质量更新的管理。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Microsoft Learn, Use Windows Update client policies and Windows Server Update Services (WSUS) together。关于用扫描源策略“Specify source service for specific classes of Windows Updates”(CSP 中为 SetPolicyDrivenUpdateSourceFor 系列)按分类指定功能更新、质量更新、驱动程序、其他 Microsoft 产品的获取来源是 WSUS 还是 Windows Update,关于抑制双重扫描的旧策略在 Windows 11 中不受支持,关于在 Windows 10 上 WSUS 指定与推迟策略共存时扫描会转向 Windows Update,关于从本地向云端分阶段迁移的推荐,以及关于在 WSUS 配置下不设置扫描源等策略时“联机检查更新程序”有可能显示 Windows 11 升级。 ↩ ↩2 ↩3
相关文章
共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。
BitLocker 实务指南——恢复密钥的查找方法与安全管理
BitLocker 的恢复密钥在哪里。讲解恢复界面中的查找方法、加密百分比与保护状态的区别、Windows 11 的自动加密、公司电脑的密钥管理,以及 BIOS 更新、维修、报废时的注意事项。
从组策略走向 Intune——中小企业的设备管理迁移指南
AD 服务器更新换代之际,是继续用组策略,还是转向 Entra ID+Intune?面向中小企业梳理两者下发机制的差异、许可、用 Group Policy analytics 盘点、五阶段迁移方案以及容易踩坑的地方。
Windows LAPS 实务指南——告别全部 PC 通用的本地管理员密码
全部 PC 通用的本地管理员密码,是一台失陷就波及全部设备的 Pass-the-Hash 攻击温床。本文讲解已成为 OS 标准功能的 Windows LAPS 如何自动轮换,如何配置保存到 AD/Entra ID,以及运维中的陷阱。
组策略(GPO)实务入门——原理、生效确认与 Intune 分工
还不清楚“用 GPO 下发”的含义就在操作 AD 环境吗?本文从实务角度讲解组策略原理与 LSDOU 应用顺序、用 gpupdate、gpresult 确认生效、与 Intune 分工,以及客户方 GPO 改变应用行为的陷阱。
Windows 安全审核策略与事件日志排查实务——成为看得懂 4625 的信息系统负责人
这是一份用于回应“帮忙查一下登录失败日志”的实务指南。讲解基本审核策略与高级审核策略的关系、至少应启用的子类别、事件 ID 4624/4625/4688 的读法、Security 日志的容量设计,以及用 Get-WinEvent 提取日志的方法。
相关主题
与本文相近的主题页面。以本文为起点,可以进一步了解相关服务和其他文章。
Windows 技术主题
汇整 KomuraSoft LLC 关于 Windows 开发、故障调查与既有资产活用文章的主题中心。
常见问题
汇总了咨询这一主题时常见的问题。
- WSUS 还能用到什么时候?
- 终止日期尚未公布。2024 年 9 月 20 日的弃用公告,含义是“停止开发新功能、不再受理新的功能需求”,现有功能仍然保留,更新程序也继续通过 WSUS 通道发布。Windows Server 2025 同样内置 WSUS 角色,生产环境的支持以及安全更新、质量更新会按照产品生命周期继续提供。截至 2026 年 8 月,同步和分发都在正常工作。但今后不会再增加新功能,因此现实的界线是“可以继续用,但不作为新的投资方向”。
- 使用 Windows Update for Business(WUfB)需要额外付费吗?
- 不需要。WUfB(现在的正式名称是 Windows Update client policies)是 Windows 10/11 的 Pro(含 Pro for Workstations)、Education、Enterprise(含 LTSC、IoT Enterprise)可以无额外费用使用的功能。Home 版不在范围内。配置既可以用组策略,也可以用 MDM(例如 Intune),可以配置质量更新最长 30 天、功能更新最长 365 天的推迟,以及最长 35 天的暂停。不需要 WSUS 那样的分发服务器,更新程序本身由 Windows Update 直接分发。
- Windows Autopatch 需要什么许可?
- 按 2026 年的要求,拥有 Microsoft 365 Business Premium、Windows 10/11 Education A3/A5(包含在 Microsoft 365 A3/A5 中)、Windows 10/11 Enterprise E3/E5(包含在 Microsoft 365 F3/E3/E5 中)、Enterprise E3/E5 VDA 中的任意一种即可使用。过去以 Enterprise E3 以上为前提,现在 Business Premium 也能使用更新环以及质量更新、功能更新、驱动程序更新的管理等核心功能(向 Microsoft 提交支持请求的功能仅限 E3 以上和 F3)。此外还必须具备 Microsoft Entra ID P1/P2 和 Microsoft Intune,目标设备必须是已在 Intune 中注册的公司自有电脑。
- 在由 WSUS 管理的电脑上混用 WUfB 的推迟策略会怎样?
- 在 Windows 10 上,同时存在 WSUS 服务器指定和推迟策略时,扫描目标会切换到 Windows Update,也就是所谓的双重扫描行为,可能在无意中装上绕过 WSUS 审批的更新。曾经用来控制这一行为的旧策略(Do not allow update deferral policies to cause scans against Windows Update)在 Windows 11 中不受支持,现在的正规做法是用它的后继者扫描源策略(Specify source service for specific classes of Windows Updates),按功能更新、质量更新、驱动程序、其他产品这四个分类分别明确获取来源是 WSUS 还是 Windows Update。在过渡期,这样也更容易做“先只把驱动程序放到云端”这类分阶段迁移。
- 无法访问互联网的封闭网络里的电脑该怎么办?
- 在封闭、离线环境中,连同用导出/导入实现的离线同步一起算上,WSUS 仍然是现实的解法。WUfB 和 Autopatch 的分发与管理都以云端(Windows Update 服务和 Intune)为前提,本来就无法成立。Microsoft 自己也因为收到断网环境的反馈,把一度预告的 WSUS 驱动程序同步终止(原定 2025 年 4 月 18 日)在 2025 年 4 月 4 日撤回,宣布继续提供。封闭网络里的 WSUS 属于“可以留下的 WSUS”,但它已被弃用这个事实不会改变,建议把它记入台账,为将来的架构调整做好准备。