☰

背景

tag-icon • tag-icon windows wsus sccm
背景

背景

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

问题

在我们将最新和最好的补丁应用到 Windows Server 2016 VM 的维护时段内，我们注意到偶尔（随着时间的推移，这种情况会越来越频繁），Cumulative Update（CU）补丁要么卡住，要么需要几个小时才能应用。我们认为，这些时间较长的原因是服务器上存在被取代的更新以及它们的数量。

那么问题来了：为什么这些被取代的更新会不断积累，却没有被清理？我们又该如何清理它们呢？

答案1

TL:DR

简而言之，被取代的更新是由 Windows Owned 计划任务失败导致的。此计划任务负责清理被取代的更新。要解决此问题，您可以运行命令来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 Owned 计划任务失败导致的。此计划任务负责清理被取代的更新。要解决此问题，您可以运行命令来Dism.exe手动清理这些被取代的更新。这允许在维护时段内更快、更可靠地修补。

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

下面是一篇讨论 Microsoft 修补操作系统的机制的文章。它提供了有关 Windows 1607 版本修补时间比其他版本更长的原因和方式的信息。如果您使用的是这个版本，可能值得一看。

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

相关内容