Windows Server 系统意外升级至 2025，原因竟是安全补丁变操作系统升级

上周，不少系统管理员遇到了这样一个让人崩溃又无语的问题——他们的 系统在一次原本应该只是安全更新的过程中，意外地升级到了 2025。

这个问题最早是由网络应用安全公司 的一位客户报告的。当他们在 11 月 5 日早上抵达办公室时，发现每一台 2022 系统要么已经自动升级到了 2025，要么正在进行升级。

后来发现，问题的根源在于，一项原本应该是安全补丁的更新，竟然变成了一个完整的操作系统升级。 据了解， 提供的补丁管理服务依赖于微软准确地标记每一个补丁，确保将更新应用到相应的软件上。

无论如何，对于通常谨慎行事的系统管理员来说，未经计划的操作系统升级，尤其是升级到全新的操作系统，这绝不是一次简单的“虚惊一场”。甚至有批评声音认为：更新机制出问题了，其严重性不亚于恶意代码注入。

追踪问题

当有客户报告问题时， 团队就迅速开始调查这一问题，但由于初期问题牵涉的范围较小，根源并不容易追踪。根据 发布在 上的帖子，他们直到当天 18:05 才确认问题背后的猫腻： 更新 API 错误地将 2025 的升级标记为安全更新 。

在 的补丁仓库中，他们发现该更新的 GUID 与通常关联 11 的 条目并不匹配。这个不一致导致他们得出结论：微软错误地将该更新分类，影响了更新的发布速度和分类方式。经过与微软知识库（KB）的进一步对比， 确认 号确实是与 11 相关，而不是 2025。

彼时预估大约有 7% 的客户受到了这次意外升级的影响。为了应对这一问题，其马上在所有服务器组策略中封锁了 。但是，这对于那些已经遇到升级问题的管理员来说，安慰有限。

而对于未及时发现问题的用户来说，后果可能会更为复杂。回滚到之前的配置将是一个挑战，受影响的用户将不得不依赖备份恢复，或者支付 2025 的许可费用。

截图源自 社区

此外，用户还需要应对新版本操作系统带来的各种变化，包括新的功能、可能的兼容性问题以及与 2025 相关的其他变动。

微软已“解决”问题

此次事件最引人注目的问题之一是， 2025 作为一项付费许可选项，竟然通过本应是安全更新的渠道进行了发布。这让部分业内人士质疑，在常规安全更新中混入重大的操作系统升级是否明智。

微软在前几天也已经更新了其公告板，明确了确实有设备被自动升级的事实。但微软表示：“这一问题出现在使用第三方产品来管理客户端和服务器更新的环境中。”

根据微软的说法：“ 2025 功能更新作为可选更新发布，属于升级分类：‘=’。”——“功能更新的元数据应被视为可选的，而非推荐的，补丁管理工具应按此解释。”

然而，微软的解释与一些第三方机构和用户的实际经历略有出入。根据 上周的报告，更新被错误分类，随后，微软将其“撤回”。此外，The 援引一位读者的说法表示，一台未运行任何第三方更新服务的独立服务器也遭遇了突如其来的隔夜更新。

目前，微软将这一问题描述为“已缓解”，但至今尚未提供任何回滚工具来帮助受影响的管理员。这意味着许多管理员只能依赖备份恢复，或者可能需要支付升级费用。微软还承认了与此相关的另一个问题：一些用户在 中看到的升级 ，可能加剧了混淆。

虽然微软表示正在与第三方供应商合作优化最佳实践，但大家可能会期待微软能够做出更加全面的回应，其中包括提供回滚工具，或者至少提供某种方式来解决由标签错误带来的问题。

自动化管理的漏洞

有分析指出，此次 2025 更新错误不仅仅是一个简单的标签错误问题。

尽管微软的更新系统为全球用户提供了无数安全补丁和功能升级，但此次事件暴露了其在处理关键更新时的漏洞，尤其是在自动化和更新标记管理机制上的不足。

作为全球最大的技术公司之一，微软理应拥有完善的错误检测和自动化审核机制。The 指出，自动化应当是避免此类错误的关键，而微软本应通过多重检查机制来防止更新标签错误的传播。然而，这些显然措施未能发挥应有作用。

此外， 更新系统过时，仍然根植于“帝国时代”的计算理念，这导致其更新和补丁管理效率低下。

不过，软件更新、补丁和升级管理的普遍问题并非微软独有，整个行业都面临类似挑战，尤其是在开源软件的更新管理中，软件包管理的复杂性也是一个难以解决的痛点。尽管开源系统提供了更多定制化和灵活性，但在大规模部署和企业环境中，仍面临更新管理和系统兼容性的挑战。

或许，这次事件为行业敲响了警钟，提醒各方应更加重视更新机制的设计、测试和管理，确保每一次操作系统更新都不会打乱用户的业务流程。此外，也有声音呼吁，行业应构建一个开放、统一、透明的更新框架，在提升操作系统与应用程序兼容性的同时，增强更新管理的可靠性。

参考链接：

本文来自微信公众号“InfoQ”，编译：燕珊，36氪经授权发布。