更新管理概述

注意

本文引用了 CentOS,这是一个处于生命周期结束 (EOL) 状态的 Linux 发行版。 请相应地考虑你的使用和规划。

重要

自动化更新管理已于 2024 年 8 月 31 日停用,我们建议使用 Azure 更新管理器。 请遵循从自动化更新管理迁移到 Azure 更新管理器的指南。

重要

Azure Log Analytics 代理(也称为 Microsoft Monitoring Agent,MMA)已于 2024 年 8 月 停用。 Azure 自动化更新管理解决方案依赖于此代理,并且在代理停用后可能会遇到问题,因为它不适用于 Azure Monitoring Agent (AMA)。 因此,如果使用 Azure 自动化更新管理解决方案,建议迁移到 Azure 更新管理器以满足软件更新需求。 Azure 自动化更新管理解决方案的所有功能将在停用日期之前在 Azure 更新管理器上提供。

可以使用 Azure 自动化中的更新管理来管理 Azure 中的 Windows 和 Linux 虚拟机、本地环境和其他云环境中的物理或虚拟机的操作系统更新 。 可以快速评估可用更新的状态,并管理安装所需更新的过程,使计算机能够向更新管理报告。

在部署更新管理并启用计算机进行管理之前,请确保你了解以下部分中的信息。

关于更新管理

下图说明了更新管理如何评估安全更新并将其应用于所有连接的 Windows 服务器和 Linux 服务器。

更新管理工作流

更新管理集成了 Azure Monitor 日志,以日志数据的形式存储已分配的 Azure 计算机和非 Azure 计算机中的更新评估和更新部署结果。 若要收集此数据,需将自动化帐户和 Log Analytics 工作区链接在一起,在计算机上安装适用于 Windows 和 Linux 的 Log Analytics 代理,并将此代理配置为向此工作区报告。

不支持在多个 Log Analytics 工作区(也称为多宿主)中对计算机注册更新管理。

下表汇总了具有更新管理的受支持的已连接源。

连接的源 支持 说明
Windows 更新管理通过使用 Log Analytics 代理并安装所需的更新,从 Windows 计算机收集有关系统更新的信息。
计算机需要向 Microsoft 更新或 Windows Server Update Services (WSUS) 报告。
Linux 更新管理通过使用 Log Analytics 代理并在受支持的发行版上安装所需的更新,从 Linux 计算机收集有关系统更新的信息。
计算机需要向本地或远程存储库报告。

分配给更新管理的计算机根据将其配置为与之同步的源报告其最新状态。 Windows 计算机需要配置为向 Windows Server Update ServicesMicrosoft 更新报告,Linux 计算机需要配置为向本地或公共存储库报告。 还可以将更新管理与 Microsoft Configuration Manager 配合使用。有关详细信息,请参阅将更新管理与 Windows Configuration Manager 集成

如果将 Windows 计算机上的 Windows Update Agent (WUA) 配置为向 WSUS 报告,则结果可能不同于 Microsoft 更新所显示的内容,具体取决于 WSUS 上次与 Microsoft 更新同步的时间。 对于配置为向本地存储库(而非公共存储库)报告的 Linux 计算机来说,情况亦是如此。 在 Windows 计算机上,符合性扫描默认情况下每 12 小时运行一次。 对于 Linux 计算机,符合性扫描默认情况下每小时执行一次。 如果 Log Analytics 代理重启,则会在 15 分钟内启动符合性扫描。 当计算机完成更新合规性扫描时,代理会将信息批量转发到 Azure Monitor 日志。

可以创建计划的部署,在需要更新的计算机上部署和安装软件更新。 归类为“可选”的更新不包括在 Windows 计算机的部署范围内。 只有必需的更新会包括在部署范围内。

计划的部署定义哪些目标计算机接收适用的更新。 它通过以下某种方式来实现此目的:明确指定特定的计算机,或选择基于特定计算机集的日志搜索(或基于根据指定条件动态选择 Azure VM 的 Azure 查询)的计算机组。 这些组与范围配置不同,后者用于控制接收配置以启用更新管理的目标计算机。 这会阻止它们执行和报告更新符合性,并安装已批准的所需更新。

定义部署时,还可以指定要批准的计划,并设置可以安装更新的一个时段。 此时段称为维护时段。 假设需要重启,并选择了相应的重启选项,则会预留 10 分钟的维护时段进行重启。 如果修补时间比预期时间长且维护时段少于 10 分钟,则不会进行重启。

为部署安排更新包后,Linux 计算机需要 2-3 小时才会显示更新以供评估。 对于 Windows 计算机,发布后,需要 12-15 小时才会显示更新以供评估。 在更新安装之前和之后,会执行更新符合性扫描,日志数据结果将转发到工作区。

通过 Azure 自动化中的 runbook 安装更新。 无法查看这些 runbook,它们不需要任何配置。 创建更新部署时,会创建一个在指定的时间为所包含的计算机启动主更新 runbook 的计划。 主 Runbook 在每个代理上启动子 Runbook,该子 Runbook 使用 Windows 上的 Windows 更新代理或受支持的 Linux 发行版上的适用命令启动所需更新的安装。

目标计算机会按更新部署中指定的日期和时间,以并行方式执行部署。 在安装之前,会运行扫描来验证更新是否仍然是必需的。 对于 WSUS 客户端计算机,如果更新未在 WSUS 中获得批准,则更新部署会失败。

限制

以下是适用于更新管理的限制:

资源 限制 备注
每个更新部署的计算机数 1000
每个更新部署的动态组数 500

权限

若要创建和管理更新部署,需要特定的权限。 若要了解这些权限,请参阅基于角色的访问 - 更新管理

更新管理组件

更新管理使用本部分中所述的资源。 启用更新管理时,这些资源会自动添加到自动化帐户。

混合 Runbook 辅助角色组

启用更新管理以后,任何直接连接到 Log Analytics 工作区的 Windows 计算机都会自动配置为系统混合 Runbook 辅助角色,为支持更新管理的 runbook 提供支持。

更新管理托管的每个 Windows 计算机都会作为自动化帐户的一个“系统混合辅助角色组”列在“混合辅助角色组”窗格中。 这些组使用 Hostname FQDN_GUID 命名约定。 不能在帐户中通过 Runbook 将这些组作为目标进行操作。 如果尝试,则尝试会失败。 这些组仅用于为更新管理提供支持。 若要详细了解如何查看配置为混合 Runbook 辅助角色的 Windows 计算机的列表,请参阅查看混合 Runbook 辅助角色

如果对更新管理和混合 Runbook 辅助角色组成员身份使用同一帐户,则可以将 Windows 计算机添加到自动化帐户中的用户混合 Runbook 辅助角色组,为自动化 runbook 提供支持。 此功能是在 7.2.12024.0 版本的混合 Runbook 辅助角色中添加的。

外部依赖关系

Azure 自动化更新管理依赖于以下外部依赖项来提供软件更新。

  • 在基于 Windows 的计算机上,软件更新包和软件更新适用性扫描需要 Windows Server Update Services (WSUS) 或 Microsoft 更新。
  • 在基于 Windows 的计算机上,需要有 Windows 更新代理 (WUA) 客户端,这样这些计算机才能连接到 WSUS 服务器或 Microsoft 更新。
  • 本地或远程存储库,用于检索 OS 更新并在基于 Linux 的计算机上安装这些更新。

管理包

以下管理包将安装在由更新管理所管理的计算机上。 你不需要对这些管理包进行配置或管理。

  • Microsoft System Center Advisor Update Assessment Intelligence Pack (Microsoft.IntelligencePacks.UpdateAssessment)
  • Microsoft.IntelligencePack.UpdateAssessment.Configuration (Microsoft.IntelligencePack.UpdateAssessment.Configuration)
  • 更新部署 MP

数据收集频率

更新管理使用以下规则扫描托管计算机中的数据。 可能需要 30 分钟到 6 小时,仪表板才会显示托管计算机提供的已更新数据。

  • 每个 Windows 计算机 - 更新管理每天对每个计算机扫描两次。

  • 每个 Linux 计算机 - 更新管理每小时执行一次扫描。

使用更新管理的计算机的每月平均 Azure Monitor 日志数据使用情况大约为 25 MB。 此值仅为近似值,且随时可能基于环境而更改。 建议监视环境,以跟踪实际使用情况。 有关如何分析 Azure Monitor 日志数据使用情况的详细信息,请参阅 Azure Monitor 日志定价详细信息

更新分类

下表定义了更新管理支持的 Windows 更新分类。

分类 说明
关键更新 解决关键、非安全相关错误的特定问题的更新。
安全更新 产品特定、安全相关问题的更新。
更新汇总 一起打包以便于部署的一组累积修补程序。
功能包 在产品版本以外发布的新产品功能。
服务包 应用于应用程序的一组累积修补程序。
定义更新 对病毒或其他定义文件的更新。
工具 可帮助完成一个或多个任务的实用工具或功能。
更新 对当前已安装的应用程序或文件的更新。

注意

在中国世纪互联中使用时,Linux 计算机的更新分类不可用。 使用更新管理时,Linux 更新没有分类。

更新没有被分类,而是在“其他更新”类别下报告。

更新管理使用受支持的分发版发布的数据,尤其是其发布的 OVAL(开放式漏洞与评估语言)文件。 由于网络访问受限,更新管理无法访问以上文件。

将更新管理与 Configuration Manager 集成

已经投资购买了 Microsoft Configuration Manager 来管理电脑、服务器和移动设备的客户还依赖 Configuration Manager 的优势和成熟度来帮助他们管理软件更新。 若要了解如何将更新管理与 Configuration Manager 集成,请参阅将更新管理与 Windows Configuration Manager 集成

Windows 上的第三方更新

更新管理依赖于本地配置的更新存储库来更新受支持的 Windows 系统(WSUS 或 Windows 更新)。 借助 System Center Updates Publisher 等工具,可通过 WSUS 导入和发布自定义更新。 在这种情况下,允许更新管理借助第三方软件来更新使用 Configuration Manager 作为其更新存储库的计算机。 若要了解如何配置 Updates Publisher,请参阅安装 Updates Publisher

将 Windows Log Analytics 代理更新到最新版本

更新管理需有 Log Analytics 代理才能正常运行。 建议将 Windows Log Analytics 代理(也称为 Windows Microsoft Monitoring Agent (MMA))更新到最新版本,以减少安全漏洞并从 bug 修复中受益。 10.20.18053(捆绑包)和 1.0.18053.0(扩展)之前的 Log Analytics 代理版本使用较旧的证书处理方法,因此不建议使用它们。 早期的 Windows Log Analytics 代理无法连接到 Azure,更新管理将在其上停止工作。

必须按照以下步骤将 Log Analytics 代理更新到最新版本:

  1. 检查计算机的当前 Log Analytics 代理版本:转到安装路径 C:\ProgramFiles\Microsoft Monitoring Agent\Agent,然后右键单击“HealthService.exe”以检查“属性”。 在“详细信息”选项卡中,字段“产品版本”提供了 Log Analytics 代理的版本号。

  2. 如果你的 Log Analytics 代理版本低于 10.20.18053(捆绑包)和 1.0.18053.0(扩展),请按照这些指导升级到最新的 Windows Log Analytics 代理版本。 

备注

在升级期间,更新管理计划可能会失败。 请确保在执行此操作时没有计划的日程安排。

后续步骤