Win11 24H2开始更新机制再进化:引入检查点累积更新机制
脚本之家
在 Windows 11 24H2 和 Windows Server 2025 及更高版本中,微软引入了全新的检查点累积更新(Checkpoint Cumulative Updates, CCU)机制。这种创新方法通过「增量差异」技术,使更新体积更小、安装更快、更具可持续性,从而节省部署时间、带宽和存储空间,保持系统最新和安全。而且无需你进行任何额外操作。
新机制会创建检查点(Checkpoint)作为未来更新的基准,而不是直接打包所有变更。这种新的更新机制带来了 3 大优势:
- 为 Windows 设备提供更小的补丁包下载。
- 为普通用户和 IT 管理员实现更可持续的更新分发。
- 改善年度功能更新体验,如 23H2、24H2。
原本的 Windows 更新机制
- 传统上,Windows 11 采用累积更新(Cumulative Updates, CU)方式,从操作系统 RTM 时开始累积构建。月度 CU 包含了自 RTM 以来的所有变更,以二进制差异的形式呈现,这些差异是基于 RTM 版本的系统文件计算得出的。
- CU 通常会被打包成一个单一的
.msu
文件,随着时间推移不断增大。无论是个人用户还是在组织中分发,都需要下载或缓存整个文件,从而导致存储和带宽的浪费,并且需要较长时间来下载和安装。 - 在 Windows 11 21H2 版本中,微软引入了「范围读取」技术,来减小补丁的下载量。这种技术只会下载和安装缺失的二进制差异文件,这些差异文件是通过比较当前和 RTM 版本的系统文件计算得出的。
检查点累积更新机制
在 Windows 11 24H2 和 Windows Server 2025 中,微软引入了检查点累积更新(CCU)概念:
- 新机制允许 CU 被标记为「检查点」,作为后续更新的新起点。后续 CU 的二进制差异将与新的「检查点」中的系统文件版本进行比较,而不是与 RTM 比较。系统可以使用文件级去重技术,仅下载后续更新中的增量文件。
- 在 Windows 生命周期内,微软可能会定期将某些 CU 标记为「检查点」。之后的更新将包含两个部分:
- 与检查点相关的更新包文件
- 包含上一个检查点增量的二进制差异更新包文件
- Windows 11 24H2 的 Windows 11 服务堆栈(Servicing Stack)能够智能地合并所有检查点,并且只下载和安装当前设备上缺失的内容。
举个例子:假设你的设备刚安装了一个被标记为检查点的更新。那么下一次更新时,系统只需要下载自该检查点以来发生变化的部分,而不是自 RTM 发布以来的所有变化。这就好比你只需要接着写日记,而不是重写整本日记本。
CCU 机制仅适用于 Windows 11 24H2、Windows Server 2025 及更高版本。Windows 11 或 10 将继续沿用现有的累积更新方式。
如何管理新的累积更新
- 对于使用 Windows 更新、Windows Update for Business、Windows Autopatch 或 WSUS 来管理系统更新的普通用户或 IT 管理员来说,新的 CCU 机制不会影响现有的工具和补丁分发流程,不需要做任何改变。新的更新机制将以改进后的普通月度更新的形式呈现。
- 对于从 Microsoft Update Catalog 获取更新的用户,某个月度更新可能会包含多个可供下载的更新包文件。这是因为每个检查点都会有一个对应的文件,此外还有一个包含自最新检查点以来所有累积变更的文件。你可以使用现有的部署工具按顺序安装这些文件。
- 如果你使用的是 Windows 10 或 Windows 11 24H2 之前的版本,更新过程不会受到影响。
想当初,就是为了简化和统合补丁分发,微软才在 Windows 10 中引入了累积更新机制,一扫「古早」每个 Windows 更新都是独立软件包的繁琐。简单来说,就是通过牺牲体积换复杂度。
好不容易走到现在,又要用复杂度来换体积,又走回去了,这是要搞哪样?这是完美继承了微软「改名逛人」的基因?