为什么 Windows 累积更新需要这么长时间以及为什么我的服务器上有这么多被取代的更新？

Question

背景

• 我们的服务器是Server 2016 Version 1607
• 我们的服务器是在不同时间创建的，有些已经运行了几个月，有些则运行了几年
• 我们通过 SCCM 部署补丁

问题

在维护时段内，当我们向 Windows Server 2016 虚拟机应用最新、最好的补丁时，我们注意到，偶尔（随着时间的推移，这种情况会更常见）Cumulative Update（CU）补丁最终会被卡住，或者需要几个小时才能应用。我们认为，这些长时间的原因是服务器上被取代的更新的存在和数量。

那么这就留下了一个问题 - 为什么这些被取代的更新会累积并且没有被清理？我们如何清理它们？

Answer 1

翻译：博士

简而言之，被取代的更新是由 Windows 拥有的计划任务失败引起的。此计划任务负责清理被取代的更新。要解决此问题，您可以运行Dism.exe命令来手动清理这些被取代的更新。这样可以在维护时段内进行更快、更可靠的修补。在此处Dism.exe查找有关这些计划任务和命令的更多信息。

事件日志中的取代更新

首先我们来谈谈我们如何知道有 CU 和其他更新正在被清理并延迟补丁安装。对于刚开始研究 Windows Server 修补程序的人来说，有一个名为 的 Windows 事件查看器日志Setup，其中包含与修补程序安装相关的事件。在此事件查看器日志中，我们可以看到一个事件，表示 KB 被标记为已取代并将被删除。下面是此类事件的样子。

当我们在维护时段开始修补时，这些事件总是会发生。这意味着我们花在打补丁上的大部分时间实际上都花在了处理这些被取代的更新上，导致我们的补丁花费的时间比我们计划的要长得多。

那么，为什么这些被取代的更新会一直存在，并且只有在打补丁时才会被清理掉呢？

Windows 任务计划程序StartComponentCleanup

在研究这个问题时，我发现了一篇文章，详细介绍了 Windows 内置的清理过时组件的功能。事实证明这正是我一直在寻找的东西。本文讨论的清理是清理旧组件，这与删除被取代的更新相关。

清理 WinSxS 文件夹 - 任务计划程序

本文提供有关内置任务计划程序任务的信息：Library\Microsoft\Windows\Servicing\StartComponentCleanup

StartComponentCleanup任务是在Windows 8中创建的，用于在系统不使用时定期自动清理组件。该任务设置为由操作系统触发时自动运行。自动运行时，该任务将在安装更新的组件后至少等待 30 天，然后再卸载该组件的早期版本。如果您选择运行此任务，该任务将有 1 小时超时，并且可能无法完全清理所有文件。

在我们的服务器上查看此任务后，我发现此任务的许多实例要么无法运行，要么在完成之前被停止。我认为这是由于上面 Microsoft 摘录中讨论的时间限制造成的，并且我相信此任务在我们的许多服务器上失败是我们遇到被取代更新过剩的原因。当此任务无法运行时，无法定期清理被取代的更新。

解构程序

前面提到的文章接着讨论了Dism.exe可用于执行此手动清理的命令。

清理 WinSxS 文件夹 - Dism.exe

实际上，您可以运行计划任务正在运行的相同命令来清理过时的组件，但不受计划任务所施加的限制。

我发现首先运行Dism.exe带有AnalyzeComponentStore标志的命令是有益的。这将返回是否存在任何过时的组件以及是否应该运行清理命令。

Dism.exe /online /Cleanup-Image /AnalyzeComponentStore

C:\Users\StackOverflow>"%SystemRoot%\System32\Dism.exe" /online /Cleanup-Image /AnalyzeComponentStore
Deployment Image Servicing and Management tool
Version: 10.0.14393.4169
Image Version: 10.0.14393.4169
[==========================100.0%==========================]
Component Store (WinSxS) information:
Windows Explorer Reported Size of Component Store : 9.52 GB
Actual Size of Component Store : 9.12 GB
    Shared with Windows : 5.29 GB
    Backups and Disabled Features : 3.15 GB
    Cache and Temporary Data : 672.30 MB
Date of Last Cleanup : 2019-04-10 08:58:06
Number of Reclaimable Packages : 3
Component Store Cleanup Recommended : Yes
The operation completed successfully.

如果您在结果中看到这一点：Component Store Cleanup Recommended : Yes那么您可能可以使用以下命令继续进行组件清理。请注意，这可能需要相当长的时间才能运行。

Dism.exe /online /Cleanup-Image /StartComponentCleanup

运行这个命令正是我想要的！运行此命令启动了 Windows 删除被取代的更新的过程（如下面的屏幕截图所示）。这很重要，因为它使我们能够在维护窗口之前主动删除被取代的更新。这使得我们的维护窗口更加可预测，超出窗口或陷入困境的可能性更小。

结论

简而言之，被取代的更新是由 Windows 拥有的计划任务失败引起的。此计划任务负责清理被取代的更新。要解决此问题，您可以运行Dism.exe命令来手动清理这些被取代的更新。这样可以在维护时段内进行更快、更可靠的修补。

有关修补 Windows Server 版本 1607 的额外信息

下面有一篇文章讨论了微软用于修补操作系统的机制。它提供了有关 Windows 1607 版本如何以及为何需要比其他版本更长的修补时间的信息。如果您使用的是这个版本，可能值得一看。

如何缩短 Windows 累积更新安装时间