排查 Azure 更新管理器的已知问题

本文介绍部署或使用 Azure 更新管理器时可能会出现的错误、解决方法以及计划修补的已知问题和限制。

常规故障排除

以下故障排除信息适用于与 Windows 和 Linux 计算机上修补程序扩展相关的 Azure 虚拟机（VM）。

未正确设置定期评估

问题

在创建专用、迁移和还原 VM 的资源期间，定期评估未被正确设置。

原因

当前修改策略的设计会影响评估。 创建资源后，策略会在合规性仪表板上将这些资源显示为不符合合规性。

解决方法

为新创建的资源运行修正任务。 有关详细信息，请参阅使用 Azure Policy 修正不合规的资源。

计划修补的先决条件未正确设置

问题

在使用 Azure 更新管理器计划定期更新和设置在 Azure 虚拟机上安排定期更新的先决条件的策略时，进行专用、通用化、迁移和还原 VM 的资源创建：

• 计划修补的先决条件未正确设置。
• 时间表未附加。

原因

部署 If Not Exists 策略的设计会影响计划的修补。 创建资源后，策略会在合规性仪表板上将这些资源显示为不符合合规性。

解决方法

为新创建的资源运行修正任务。 有关详细信息，请参阅使用 Azure Policy 修正不合规的资源。

映像的策略修正任务失败

问题

对于图库映像和具有加密磁盘的映像，策略修正任务发生故障。 VM 在 VM 模式下引用库映像时存在修正失败。 托管标识需要库映像的读取权限，但它目前不属于虚拟机贡献者角色的一部分。

原因

虚拟机贡献者角色权限不足。

解决方法

对于所有新分配，最新的更改为修正任务创建的托管身份授予了参与者角色。

如果您遇到任何以前分配的补救任务失败，我们建议按照 通过定义的角色向托管标识授予权限中的步骤，手动授予托管标识贡献者角色。

在链接资源（库映像或磁盘）位于其他资源组或订阅中时，如果协作者角色不起作用，请手动为托管标识提供适当的角色和权限，以解除对修正过程的阻碍。 请遵循“通过定义的角色向托管身份授予权限”中的步骤。

无法为已启用 Azure Arc 的服务器生成定期评估

问题

已启用 Azure Arc 的服务器加入的订阅不会生成评估数据。

原因

订阅未被注册到正确的资源提供程序。

解决方法

确保将启用 Azure Arc 的服务器订阅注册到 Microsoft.Compute 资源提供程序，以便按预期定期生成评估数据。 了解详细信息。

移动 VM 时，不会应用维护配置

问题

将 VM 移到另一个订阅或资源组时，与 VM 关联的计划维护配置未运行。

原因

维护配置目前不支持跨资源组或订阅移动分配的资源。

解决方法

一个变通方法是，对要移动的资源使用以下步骤。

如果使用 static 范围：

1. 删除资源分配。
2. 将资源移动到不同的资源组或订阅。
3. 重新创建资源分配。

如果使用 dynamic 范围：

1. 启动或等待下一次计划性运行。 此操作会提示系统完全删除任务，以便您可以继续执行后续步骤。
2. 将资源移动到不同的资源组或订阅。
3. 重新创建资源分配。

如果错过任何步骤，请将资源移到以前的资源组或订阅 ID，然后重试这些步骤。

无法将修补编排从自动更改为手动

问题

你希望确保 Windows 更新客户端不会在 Windows Server 实例上安装修补程序，因此需要将修补程序设置设置为手动。 不能使用更改更新设置来将补丁编排更改为手动更新。

原因

Azure 机器具有修补编排选项作为 AutomaticByOS/Windows 自动更新。

解决方法

如果不希望 Azure 协调任何修补程序安装，或者未使用自定义修补解决方案，可以将修补业务流程选项更改为 客户托管计划（预览版） （或 AutomaticByPlatform ）， ByPassPlatformSafetyChecksOnUserSchedule而不将计划或维护配置关联到计算机。 此设置可确保在明确更改之前不会在计算机上进行任何修补。

未评估计算机并显示 HRESULT 异常

问题

您有设备在符合性下显示为未评估，并且在其下方看到一条异常消息。 或者，可以在门户中看到 HRESULT 错误代码。

原因

更新代理（Windows 上的 Windows 更新代理和 Linux 分发版的包管理器）未正确配置。 更新管理器依赖于计算机的更新代理来提供必要的更新、修补程序的状态和已部署修补程序的结果。 如果没有该信息，则更新管理无法正确报告所需的或已安装的补丁。

解决方法

尝试在计算机上本地执行更新。 如果此作失败，则通常意味着更新代理的配置错误。 若要解决此问题，请执行以下操作：

• 对于 Linux，请查看相应的文档，确保可以访问包存储库的网络终结点。

• 对于 Windows，请查看代理配置，如 更新未从 Intranet 端点（WSUS 或 Configuration Manager）下载中所述。

  • 如果为 Windows 更新配置了计算机，请确保可以访问与 HTTP/代理相关的问题中所述的终结点。
  • 如果为 Windows Server Update Services (WSUS) 配置了计算机，请确保可以访问由 WUServer 注册表项配置的 WSUS 服务器。

如果看到 HRESULT 错误代码，请双击显示为红色的异常，以查看完整的异常消息。 查看下表，了解可能采取的解决方案或推荐操作。

查看%Windir%\Windowsupdate.log文件还可以帮助确定可能的原因。 有关如何读取日志的详细信息，请参阅 Windows 更新日志文件。

你还可以下载并运行 Windows 更新故障排除程序，以检查计算机上的 Windows 更新是否存在任何问题。 故障排除程序适用于 Windows 客户端和 Windows Server。

出现内部执行错误

问题

更新管理器无法修补 VM 并生成内部执行错误。 操作不返回回复，可能会不完整。

原因

由于更新管理器和 VM 之间的临时问题或通信失败，可能会出现此问题。 常见原因包括：

• 临时平台或后端服务问题。
• 无响应或过时的 Azure VM 代理。
• 处于负载过重状态或在操作过程中重新启动的 VM。
• 网络或连接问题。

解决方法

• 几分钟后重试更新。
• 确保 VM 代理正常运行且处于最新状态。
• 如果代理状态显示 “未就绪”，请尝试重新启动 VM。
• 检查 VM 资源使用情况（CPU、内存、磁盘）。 如果需要，请重新启动。
• 验证与 Azure 服务的网络连接。
• 有关更多详细信息，请查看 VM 和更新管理器上的日志。

预定的补丁无法运行

对于并发或有冲突的计划，只会触发一个计划。 第一个计划完成后，将触发另一个计划。

如果计算机是新创建的，并且涉及 Azure VM，则计划可能会有 15 分钟的触发延迟。

出现 ShutdownOrUnresponsive 错误

问题

计划的修补程序不会在虚拟机上安装，并会出现 ShutdownOrUnresponsive 错误。

原因

已知的限制可能会导致在删除的计算机上，在8小时内用相同的资源ID重新创建时，其触发的计划会因这个错误而失败。

解决方法

此问题不会在 8 小时后发生。

无法为已关机的计算机应用修补程序

问题

修补程序不会应用于处于关闭状态的计算机。 你可能还会发现计算机正在丢失其关联的维护配置或计划。

原因

计算机处于关闭状态。

解决方法

确保在计划更新前至少 15 分钟打开计算机。 有关详细信息，请参阅 “关闭计算机”。

更新历史记录不准确显示已超出维护时段

问题

在“更新历史记录”中查看更新部署时，属性“失败并超过维护时段”显示为 true，即使还有足够的执行时间，也是如此。 在这种情况下，可能会出现以下问题之一：

• 未显示更新。
• 一个或多个更新处于“挂起”状态。
• 重新启动状态为 “必需”，但是即使在重新启动设置为 IfRequired 或 Always 时，也未尝试重新启动。

原因

在更新部署期间，会在多个步骤中检查维护时段利用率。 维护时段中的十分钟预留用于在任何时刻重新启动。

在获取缺失更新列表、下载更新，或安装更新之前，会检查在维护窗口中是否有足够的剩余时间。

• 除 Windows Service Pack 之外的所有更新：重启需要 15 分钟 + 10 分钟，总共 25 分钟。
• Windows Service Pack 更新：重新启动 20 分钟 + 10 分钟，总共 30 分钟。

如果部署还没有足够的时间，则会跳过更新的扫描、下载和安装。 然后，部署过程接着会检查是否需要重启，以及维护时段是否还剩下10分钟。 如果是这样，部署将触发重新启动。 否则会跳过该重启。

在这种情况下，状态将更新为“失败”，而“超过维护时段”属性将更新为 true。 如果剩余时间少于 25 分钟，则不会扫描更新或尝试安装更新。

若要查找详细信息，请查看部署运行的错误消息所提供的文件路径中的日志。

解决方法

在触发 按需更新部署时，为最长持续时间设置更长的时间范围。

未安装 Windows/Linux OS 更新扩展

问题

无法在已启用 Azure Arc 的计算机上执行修补。

原因

必须在已启用 Azure Arc 的计算机上成功安装 Windows/Linux OS 更新扩展，以便执行按需评估、修补和计划修补。

解决方法

触发按需评估或修补，在计算机上安装扩展。 还可以将计算机附加到维护配置计划，该计划将在按计划执行修补时安装扩展。

如果扩展已存在于已启用 Azure Arc 的计算机上，但扩展状态未 成功， 请删除该扩展 ，然后触发按需作以重新安装它。

未安装 Windows/Linux 修补程序更新扩展

问题

无法在 Azure VM 上执行修补。

原因

必须在 Azure 计算机上安装 Windows/Linux 修补程序更新扩展才能执行按需评估或修补、计划修补和定期评估。

解决方法

触发按需评估或修补，在计算机上安装扩展。 还可以将计算机附加到维护配置计划，该计划将在按计划执行修补时安装扩展。

如果扩展已存在于计算机上，但扩展状态未 成功，请删除该扩展，然后触发按需作以重新安装它。

扩展检查失败

问题

检查以确保 AllowExtensionOperations 属性设置正确失败。

原因

该AllowExtensionOperations属性在计算机的false接口中设置为OSProfile。

解决方法

若要允许扩展正常工作，请将属性设置为 true.

Sudo 权限不存在

问题

你可能会看到以下异常：

EXCEPTION: Exception('Unable to invoke sudo successfully. Output: root is not in the sudoers file. This incident will be reported. False ',)

原因

不会向扩展组件授予 Sudo 权限，以进行评估或更新操作的 Linux 计算机。

更新管理器由于需要更新许多组件（包括内核驱动程序和操作系统安全补丁），因此需要高级别的权限。 更新管理器扩展使用 root 帐户执行操作。

解决方法

授予 sudo 权限以确保评估或修补操作成功。 需要将根帐户添加到 /etc/sudoers 文件中。

1. sudoers打开文件进行编辑：

   sudo visudo
   

2. 将以下条目添加到 sudoers 文件的末尾：

   root ALL=(ALL) ALL
   

3. 使用 Ctrl+X 键盘快捷方式保存并关闭编辑器。 如果使用 vi 编辑器，可以键入 :wq 并选择 Enter 键。

已配置代理

问题

代理阻止访问成功执行评估或修补操作所需的终结点。

原因

代理是在 Windows 或 Linux 计算机上配置的。

解决方法

对于 Windows，请参阅 与 HTTP/代理相关的问题。

对于 Linux，请确保代理设置不会阻止访问下载和安装更新所需的存储库。

TLS 1.2 检查失败

问题

确认使用 TLS 1.2 的检查未通过。

原因

你使用的是 TLS 1.0 或 TLS 1.1。 这些版本已弃用。

解决方法

使用 TLS 1.2 或更高版本。

对于 Windows，请参阅 TLS/SSL 中的协议（Schannel SSP）。

对于 Linux，请运行以下命令，查看分发版支持的 TLS 版本： nmap --script ssl-enum-ciphers -p 443 www.azure.com

HTTPS 连接检查失败

问题

检查以确保 HTTPS 连接的可用性失败。

原因

HTTPS 连接不可用。 需要此连接才能从每个操作系统的必要终结点下载和安装更新。

解决方法

允许从计算机建立 HTTPS 连接。

MsftLinuxPatchAutoAssess 服务未运行或超时

问题

定期评估不适用于 Linux 计算机。

原因

成功定期评估需要 MsftLinuxPatchAutoAssess 服务。

解决方法

确保机器的 LinuxPatchExtension 状态是 succeeded。 重启计算机，检查问题是否已解决。

无法访问 Linux 存储库

问题

从每个 Linux 分发版配置的公用或专用存储库下载更新。 计算机无法连接到这些存储库来下载或评估更新。

原因

网络安全规则可以阻止重要的连接。

解决方法

确保网络安全规则不会妨碍计算机连接到更新作所需的存储库。

相关内容

• 若要了解有关更新管理器的详细信息，请参阅 概述。
• 若要查看所有计算机的日志结果，请参阅 使用 Azure Resource Graph 访问 Azure 更新管理器操作数据。