Compartir a través de

更新管理器的工作原理

更新管理器评估和应用适用于 Windows 与 Linux 的所有 Azure 计算机和已启用 Azure Arc 的服务器的更新。

显示更新管理器工作流的关系图。

更新管理器 VM 扩展

在已启用 Azure 或 Arc 的服务器上启用或触发 Azure 更新管理器操作 (AUM) 时,AUM 将分别在计算机上安装 Azure 扩展已启用 Arc 的服务器扩展来管理更新。

首次在计算机上启动任何更新管理器操作(例如检查更新、安装一次性更新、定期评估或首次在计算机上运行计划的更新部署)时,将自动在计算机上安装扩展。

客户不必显式安装扩展及其生命周期,因为它由 Azure 更新管理器管理,包括安装和配置。 更新管理器扩展是使用以下代理安装和管理的,更新管理器在计算机上工作需要这些代理:

注意

Arc 连接是更新管理器、非 Azure 计算机(包括已启用 Arc 的 VMWare、SCVMM 等)的先决条件。

对于 Azure 计算机,将安装单一扩展,而对于已启用 Azure Arc 的计算机,则需要安装两个扩展。 下面是安装的扩展的详细信息:

操作系统 分机
Windows Microsoft.CPlat.Core.WindowsPatchExtension
Linux Microsoft.CPlat.Core.LinuxPatchExtension

更新源

Azure 更新管理器遵循计算机上的更新源设置,并相应地提取更新。 AUM 不会发布或提供更新。

如果将 Windows 更新代理 (WUA) 配置为从 Windows 更新存储库或 Microsoft 更新存储库或 Windows Server Update Services (WSUS) 提取更新,则 AUM 将遵循这些设置。 有关详细信息,请参阅如何配置 Windows 更新客户端。 默认情况下,它配置为从 Windows 更新存储库中提取更新

AUM 执行以下步骤:

  • 检索 Windows 更新客户端或 Linux 包管理器为操作系统指定的系统更新的状态评估信息。
  • 启动通过 Windows 更新客户端或 Linux 包管理器下载和安装更新的过程。

注意

  1. 计算机将根据配置为与其同步的源报告其更新状态。 如果 Windows 更新服务配置为向 WSUS 报告,则更新管理器中的结果可能与 Microsoft 更新所显示的内容不同,具体取决于 WSUS 上次与 Microsoft 更新同步的时间。 对于配置为向本地存储库(而不是公共包存储库)报告的 Linux 计算机来说,此行为也是如此。
  2. 更新管理器将仅查找 Windows 更新服务在你选择本地 Windows 系统上的本地“检查更新”按钮时找到的更新。 在 Linux 系统上,只会发现本地存储库上的更新。

Azure Resource Graph 中存储的更新数据

更新管理器扩展将所有挂起的更新信息和更新安装结果推送到 Azure Resource Graph,其中保留以下时间段的数据:

Data Azure Resource Graph 中的保持期
挂起的更新(ARG 表名称:patchassessmentresources) 七天
更新安装结果(ARG 表名称:patchinstallationresources) 30 天

有关详细信息,请参阅 Azure Resource Graph 的日志结构,以及示例查询

如何在 Azure 更新管理器中安装修补程序

在 Azure 更新管理器中,以以下方式安装修补程序:

  1. 它首先对 VM 上的可用更新进行新的评估。

  2. 更新安装遵循评估。

    • 在 Windows 中,符合客户条件的所选更新将逐个安装,
    • 而在 Linux 中,它们分批安装。
  3. 在更新安装期间,系统会通过多个步骤检查维护时段的使用。 对于 Windows 和 Linux,将在维护时段中分别留出 10 分钟和 15 时间以便随时重新启动。 在继续安装剩余更新之前,它会检查预期的重新启动时间加上平均更新安装时间(对于下一个更新或下一组更新)是否不会超过维护时段。 对于 Windows,除 Service Pack 更新外,所有类型的更新的平均更新安装时间为 10 分钟。 对于 Service Pack 更新,时间为 15 分钟。

  4. 请注意,即使更新安装超过维护时段,也不会强行停止正在进行的更新安装(一旦根据上述计算启动),以避免计算机处于可能不确定的状态。 但是,在超过维护时段后,它不会继续安装剩余的更新,在这种情况下会引发维护时段超时错误。

  5. 仅当安装了所有所选更新并且涉及的所有操作(包括重新启动和评估)都成功时,修补/更新安装才会标记为“成功”。 否则,它会标记为“失败”或“已完成”,并显示警告。 例如,

    场景 更新安装状态
    所选更新之一无法安装。 已失败
    重新启动不会因任何原因而发生且重新启动等待时间超时。 已失败
    计算机在重新启动期间无法启动。 已失败
    初始或最终评估失败 已失败
    更新需要重新启动,但“从不重新启动”选项处于选中状态。 已完成但出现警告
    如果 Ubuntu pro 许可证不存在,则 ESM 包会跳过 ubuntu 18 或更低版本的修补。 已完成但出现警告
  6. 系统会在结束时进行评估。 请注意,在某些情况下,更新安装结束时可能不会发生重新启动和评估过程,例如,超出维护时段的情况,更新安装因某些原因而失败的情况等等。

后续步骤