首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >为什么Windows累积更新要花费这么长时间,以及为什么我的服务器上有那么多替代更新?

问为什么Windows累积更新要花费这么长时间,以及为什么我的服务器上有那么多替代更新?
EN

Server Fault用户
提问于 2021-05-13 14:08:59
回答 1查看 3.6K关注 0票数 3

背景

  • 我们的服务器是Server 2016版本1607
  • 我们的服务器是在不同的时间创建的,一些已经运行了几个月,另一些已经运行了几年。
  • 我们通过SCCM部署修补程序。

The Issue

在我们的维护窗口中,当我们向WindowsServer2016VM应用最新和最优秀的修补程序时,我们注意到,偶尔(随着时间的推移),Cumulative Update (CU)补丁有时会卡住,或者要花上几个小时才能应用。我们认为,这么长时间的原因是服务器上出现的替换更新的数量和数量。

这就留下了一个问题--为什么这些被取代的更新在不断积累,而没有被清理掉?我们怎么才能把它们清理干净?

EN

回答 1

Server Fault用户

回答已采纳

发布于 2021-05-13 14:08:59

TL:

博士

简而言之,被取代的更新是由Windows拥有的计划任务失败造成的。此计划任务负责清除已取代的更新。要解决这个问题,您可以运行一个Dism.exe命令来手动清除这些替代的更新。这允许在维护窗口期间进行更快、更可靠的修补。查找有关这些计划任务和Dism.exe命令这里的更多信息。

取代了事件日志

中的更新

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

当我们在维护窗口期间开始修补时,这些事件总是发生在正确的位置。这意味着我们花在补丁上的大部分时间实际上花在了处理这些被取代的更新上,导致我们的补丁比我们计划的要花更长的时间。

那么,为什么这些被取代的更新仍然存在,并且只在修补过程中才被清理?

Windows任务调度器StartComponentCleanup

在研究这个问题时,我看到了一篇文章,详细介绍了Windows内置的清理过时组件的能力。原来这正是我要找的。本文讨论的清理是清理旧组件,这与删除取代的更新有关。

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

本文提供了有关内置任务调度器任务的信息:Library\Microsoft\Windows\Servicing\StartComponentCleanup。

StartComponentCleanup任务是在Windows 8中创建的,用于在系统不使用时定期自动清理组件。此任务被设置为在操作系统触发时自动运行。当自动运行时,该任务将在安装了更新的组件后至少30天才卸载该组件的以前版本。如果您选择运行此任务,则该任务将有1个小时的超时时间,并且可能不会完全清除所有文件。

在我们的服务器上查看此任务时,我发现这个任务的许多实例要么无法运行,要么在它能够完成之前被停止。我认为这是由于微软在上面的摘录中讨论的时间限制造成的,而且我认为这一任务在我们的许多服务器上失败是我们正经历过多的替代更新的原因。当此任务无法运行时,无法定期清除取代的更新。

Dism.exe

然后,前面提到的这篇文章将继续讨论可用于执行这种手动清理的Dism.exe命令。

Dism.exe -清理WinSxS文件夹

实际上,您可以运行与调度任务运行的相同的命令来清理过时的组件,尽管不受计划任务的限制。

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

Dism.exe /online /Cleanup-Image /AnalyzeComponentStore

代码语言:javascript
复制
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命令来手动清除这些替代的更新。这允许在维护窗口期间进行更快、更可靠的修补。

关于修补WindowsServerVersion1607

的附加信息

下面是一篇关于Microsoft用于修补操作系统的机制的文章。它提供了有关1607版本Windows修补程序比其他版本要花费更长时间的信息。如果你在这个版本,它可能值得一看。

如何提高Windows累积更新安装时间

票数 4
EN
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://serverfault.com/questions/1063448

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档