如果我pipe理一个现场WSUS实例，我负责根据一些策略准则向已join域的PC发布更新。 是否有某种元数据或技术可用于在决定何时发布更新之前评估对最终用户的影响。
我试图解决的具体情况是需要重新启动的明显更小的更新的发生，并花费了一个荒唐的时间来完成。 有几次，我看到电脑试图从下午5点开始菜单“closures并应用更新”，并坐了半个多小时，而他们在硬盘上碾压。 这些是具有固态硬盘和8Gb或更高内存的现代化快速机器。 我唯一的理论是，这些更新必须扫描整个磁盘出于某种原因。 如果这些更新以某种方式被标记，我想阻止它们，直到计划停机的一天。
除了单独应用这些选项并使用秒表计时外，还有其他select吗？
除了单独应用它们并测量负载或时间之外没有更多的select。 您可以使用虚拟机场来testing它们，但是有太多的variables甚至无法控制。
自Vista以来，许多更新需要很长时间的原因是它们被封装为“差异”。 这些更新实际上只是为了生成修补文件而必须与原始文件结合的修改列表。 更新或原始文件越大或越复杂，需要的时间越长。 这可能在CPU，RAM和磁盘I / O中密集。
如果在白天应用更新成为问题，您可能需要考虑另一种策略。