Azure 更新管理器评估所有 Azure 虚拟机（VM）和已启用 Azure Arc 的服务器（适用于 Windows 和 Linux）的更新并应用更新。
更新管理器 VM 扩展
在 Azure VM 或已启用 Azure Arc 的服务器上启用或触发更新管理器作时，更新管理器会在计算机上安装 Azure 扩展 或 已启用 Azure Arc 的服务器扩展 （分别）来管理更新。
首次在计算机上启动任何更新管理器作时，会自动安装扩展。 这些作包括 检查更新、 安装一次性更新和 定期评估。 首次在计算机上运行计划的更新部署时，也会自动安装扩展。
无需显式安装扩展及其生命周期。 更新管理器使用以下代理管理安装和配置。 更新管理器需要这些代理才能在计算机上安装。
- 对于 Azure VM： Azure Windows VM 代理 或 Azure Linux VM 代理
- 对于已启用 Azure Arc 的服务器： Azure Connected Machine 代理
注意
Azure Arc 连接是更新管理器和非 Azure 计算机的先决条件，包括已启用 Azure Arc 的 VMware vSphere 和已启用 Azure Arc 的 System Center Virtual Machine Manager。
对于 Azure 计算机，更新管理器安装单个扩展。 对于已启用 Azure Arc 的计算机，更新管理器将安装两个扩展。 以下选项卡提供有关扩展的详细信息：
| 操作系统 | 分机 |
|---|---|
| Windows | Microsoft.CPlat.Core.WindowsPatchExtension |
| Linux | Microsoft.CPlat.Core.LinuxPatchExtension |
在 Azure 门户中查看 VM 的可用扩展：
- 转到 Azure 门户并选择一个 VM。
- 在 VM 主页的 “设置”下，选择“ 扩展 + 应用程序”。
- 在“扩展”选项卡上，可以查看可用的扩展。
更新源
更新管理器遵循计算机上的更新源设置，并相应地提取更新。 更新管理器不会发布或提供更新。
如果Windows 更新代理（WUA）被配置为从 Windows 更新存储库、Microsoft 更新存储库或Windows Server Update Services（WSUS）提取更新，更新管理器会遵循这些设置。 有关详细信息，请参阅 配置 Azure 更新管理器的 Windows 更新设置。 默认情况下， WUA 配置为从 Windows 更新存储库中提取更新。
更新过程
更新管理器执行以下步骤：
- 检索有关 Windows 更新客户端或 Linux 包管理器指定的系统更新状态的评估信息。
- 使用 Windows 更新客户端或 Linux 包管理器启动更新的下载和安装。
机器根据与它们同步的配置源报告其更新状态。 如果 Windows 更新服务配置为向 WSUS 报告，则更新管理器中的结果可能与 Microsoft 更新所显示的内容不同，具体取决于 WSUS 上次与 Microsoft 更新同步的时间。 对于配置为向本地存储库（而不是公共包存储库）报告的 Linux 计算机来说，此行为也是如此。
更新管理器仅查找 Windows 更新服务在本地 Windows 系统上选择 “检查更新 ”按钮时查找的更新。 在 Linux 系统上，更新管理器仅发现本地存储库中的更新。
更新管理器使用 WUA API 安装更新。 通过 WUA API 安装的更新不会显示在计算机上的“设置”应用中的 Windows 更新页面上。 因此，通过更新管理器安装的更新在“设置”应用中的 Windows 更新页上不可见。 “设置”应用中的 Windows 更新页显示 Windows 更新业务流程协调程序工作流管理的更新的进度和历史记录。 了解详细信息。
Azure Resource Graph 中存储的与更新相关的数据
更新管理器扩展会将所有挂起的更新信息和更新安装结果推送到 Azure Resource Graph。 Resource Graph 在以下时间段内保留数据：
| Data | Resource Graph 中的保留期 |
|---|---|
挂起的更新（Resource Graph 表名称：patchassessmentresources） |
7 天 |
更新安装结果（资源图表表名称：patchinstallationresources） |
30 天 |
有关详细信息，请参阅 Azure Resource Graph 的日志结构和示例查询。
在更新管理器中安装修补程序
更新管理器按以下方式安装修补程序：
更新管理器对 VM 上的可用更新进行新的评估。
对于 Windows，将逐个安装符合客户条件的所选更新。 对于 Linux，它们以批处理方式安装。
在更新安装过程中，更新管理器会在多个步骤中检查维护时段利用率。
对于 Windows 和 Linux，维护时段中的 10 分钟和 15 分钟分别被保留用于在任意时点重新启动。 在更新管理器继续安装剩余更新之前，它会检查预期的重新启动时间加上平均更新安装时间（对于下一个更新或下一组更新），不会超过维护时段。
对于 Windows，除 Service Pack 更新外，所有类型的更新的平均更新安装时间为 10 分钟。 对于 Service Pack 更新，更新时间为 15 分钟。
持续进行的更新安装（根据上述计算启动后）不会被强行停止，即使超过维护时段，也是为了避免将计算机置于可能出现不确定状态。 但是，更新管理器不会在维护时段结束后安装剩余的更新，并显示“超出维护时段”错误。
仅当安装所有选定的更新以及涉及的所有作（包括重新启动和评估）成功时，更新管理器才会将安装标记为成功。 否则，安装将标记为 “失败 ”或“ 已完成”，并显示警告。 例如：
场景 更新安装状态 其中一个所选更新的安装失败。 Failed 重启不会因任何原因而发生，重新启动的等待时间会超时。 Failed 计算机在重新启动期间无法启动。 Failed 初始或最终评估失败。 Failed 更新需要重新启动，但已选择 “永不重启 ”选项。 已完成并显示警告 如果 Ubuntu Pro 许可证不存在，ESM 包已跳过 Ubuntu 18 或更早版本中的修补。 已完成并显示警告 结束时进行评估。 有时，不会进行重新启动和评估;例如，如果维护时段结束或更新安装失败。