排查 Azure 更新管理器的问题

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

常规故障排除

以下故障排除步骤适用于与 Windows 和 Linux 计算机上的补丁扩展相关的 Azure 虚拟机 (VM)。

在为专用的、迁移的和还原的 VM 进行创建的期间使用定期评估策略时，定期评估未正确设置

原因

由于当前的修改策略的设计方式，在为专用的、迁移的和还原的 VM 进行创建的期间，定期评估未正确设置。 创建后，该策略在合规性仪表板上会将这些资源显示为不合规。

解决方法

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

计划修补的先决条件未正确设置，在为专用化、通用化、迁移和还原的 VM 创建期间使用特定策略时，不会附加计划

原因

由于当前“如果不存在则部署”策略的设计方式，在创建专用、通用、迁移和恢复的虚拟机时，使用“使用 Azure Update 管理器安排定期更新”和“在 Azure 虚拟机上设置安排定期更新的前提条件”策略时，没有正确设置计划修补和附加计划的前提条件。 创建后，该策略在合规性仪表板上会将这些资源显示为不合规。

解决方法

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

库映像和具有加密磁盘的映像的策略修正任务失败

问题

对于虚拟机模式下引用库图像的虚拟机，修复会失败。 这是因为它需要库映像的读取权限，并且它当前不属于虚拟机参与者角色。

原因

虚拟机参与者角色没有足够的权限。

解决方法

• 对于所有新分配，将引入最近的更改，为在策略分配期间创建的托管标识提供“参与者”角色以进行修复。 今后，将为任何新分配分配此角色。
• 对于以前的任何分配，如果遇到修复任务失败，我们建议按照通过定义的角色向托管标识授予权限下列出的步骤手动将参与者角色分配给托管标识
• 此外，如果链接资源（库映像或磁盘）位于其他资源组或订阅中时参与者角色不起作用，请按照通过定义的角色向托管标识授予权限中的步骤手动向托管标识提供正确的角色和范围权限，以解除阻止修复。

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

问题

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

解决方法

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

当 VM 移至其他订阅或资源组时不会应用维护配置

问题

当 VM 移至另一订阅或资源组时，与 VM 关联的计划维护配置不会运行。

解决方法

维护配置目前不支持跨资源组或订阅移动分配的资源。 一个变通方法是，对要移动的资源使用以下步骤。 作为先决条件，请先删除分配，然后再按照步骤操作。

如果使用 static 范围：

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

如果使用 dynamic 范围：

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

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

无法将补丁编排选项从自动更新更改为手动更新

问题

你希望确保 Windows 更新客户端不会在 Windows Server 上安装补丁，因此你想要将补丁设置设为“手动”。 Azure 计算机的补丁编排选项为 AutomaticByOS/Windows 自动更新，你无法通过使用“更改更新设置”将补丁编排更改为“手动更新”。

解决方法

如果你不希望 Azure 编排任何补丁安装或不使用自定义修补解决方案，则可将补丁编排选项更改为“客户管理的计划(预览版)”或 AutomaticByPlatform 和 ByPassPlatformSafetyChecksOnUserSchedule，但不将计划/维护配置与计算机关联。 此设置可确保在明确更改之前不会在计算机上进行任何修补。 有关详细信息，请参阅用户方案中的“方案 2”。

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

问题

• 计算机在“合规性”下显示 Not assessed，并且能看到下面显示一条异常消息。
• 你会在门户中看到 HRESULT 错误代码。

原因

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

解决方法

尝试在计算机上本地执行更新。 如果此操作失败，则通常表示存在更新代理配置错误。

此问题通常是由网络配置和防火墙问题导致的。 执行以下检查来更正问题：

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

• 对于 Windows，请检查无法从 Intranet 终结点 (WSUS/SCCM) 下载更新中介绍的代理配置。

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

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

异常	解决方法或操作
Exception from HRESULT: 0x……C	搜索 Windows 更新错误代码列表中的相关错误代码，以查找有关异常原因的详细信息。
0x8024402C 0x8024401C 0x8024402F	指示网络连接问题。 请确保你的计算机具有与更新管理的网络连接。 有关所需端口和地址的列表，请参阅网络规划部分。
0x8024001E	由于服务或系统正关闭，未能完成更新操作。
0x8024002E	已禁用 Windows 更新服务。
0x8024402C	如果使用 WSUS 服务器，请确保注册表项 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 下 WUServer 和 WUStatusServer 的注册表值指定的是正确的 WSUS 服务器。
0x80072EE2	网络连接问题或与已配置的 WSUS 服务器通信的问题。 检查 WSUS 设置并确保可以从客户端访问服务。
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422)	请确保 Windows 更新服务 (wuauserv) 正在运行，并且未禁用。
0x80070005	拒绝访问错误可能是由以下任一问题引起的： - 计算机受感染。 - 未正确配置 Windows 更新设置。 - %WinDir%\SoftwareDistribution 文件夹出现文件权限错误。 - 系统驱动器（驱动器 C）的磁盘空间不足。
任何其他一般异常	在 Internet 上搜索可能的解决方案，并与本地 IT 支持人员合作。

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

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

计划修补的已知问题

• 对于并发或有冲突的计划，只会触发一个计划。 第一个计划完成后，将触发另一个计划。
• 如果计算机是新建的，则对于 Azure 虚拟机，计划可能会出现 15 分钟的计划触发器延迟。

计划修补失败并出现错误“ShutdownOrUnresponsive”

问题

计划修补尚未在 VM 上安装补丁，发出了“ShutdownOrUnresponsive”错误。

解决方法

由于已知限制，在 8 小时内用相同资源 ID 删除和重新创建的计算机上触发的计划可能会失败，并出现 ShutdownOrUnresponsive 错误。

无法为关闭的计算机应用补丁

问题

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

原因

计算机处于关闭状态。

解决方法

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

即使还有剩余时间，补丁也运行失败并且“超过维护时段”属性显示为 true

问题

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

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

原因

在部署更新期间，系统会通过多个步骤检查维护时段的使用。 将在维护时段中留出 10 分钟时间以便随时重启。 在部署获取缺失更新的列表或者下载或安装任何更新（Windows 服务包更新除外）之前，系统将验证是否有 15 分钟 + 10 分钟时间用于重启（即，在维护时段中留出 25 分钟）。

对于 Windows 服务包更新，部署会检查是否有 20 分钟 + 10 分钟（即 30 分钟）时间用于重启。 如果部署没有足够的剩余时间，则会跳过更新的扫描/下载/安装。 然后，部署运行将检查是否需要重启，以及是否在维护时段中留出了 10 分钟时间。 如果留出了该时间，部署会触发重启。 否则会跳过该重启。

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

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

解决方法

在触发按需更新部署时，为最大持续时间设置更长的时间范围有助于避免该问题。

未安装 Windows/Linux OS 更新扩展

问题

必须在 Arc 计算机上成功安装 Windows/Linux OS 更新扩展才能执行按需评估、修补和计划内修补。

解决方法

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

如果扩展已存在于计算机上，但扩展状态不是“已成功”，请确保删除该扩展并触发按需操作，以便再次安装扩展。

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

问题

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

解决方法

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

如果扩展已存在于计算机上，但扩展状态不是“已成功”，请触发按需操作，再次安装扩展。

允许扩展操作检查失败

问题

计算机 OSProfile 中的属性 AllowExtensionOperations 设置为 false。

解决方法

应将该属性设置为 true，以便扩展能够正常工作。

不存在 sudo 特权

问题

未向 Linux 计算机上的扩展授予执行评估或修补操作所需的 sudo 特权。

解决方法

授予 sudo 权限，确保评估或修补操作成功。

已配置代理

问题

Windows 或 Linux 计算机上配置了代理，可能会阻止访问评估或修补操作成功所需的终结点。

解决方法

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

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

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 状态为“已成功”。 重启计算机，检查问题是否已解决。

无法访问 Linux 存储库

问题

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

解决方法

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

后续步骤

• 若要详细了解更新管理器，请参阅概述。
• 若要查看所有计算机的已记录结果，请参阅从更新管理器查询日志和结果。