排查 Azure 更新管理器的问题
本文介绍部署或使用 Azure 更新管理器时可能会出现的错误、解决方法以及计划修补的已知问题和限制。
常规故障排除
以下故障排除步骤适用于与 Windows 和 Linux 计算机上的补丁扩展相关的 Azure 虚拟机 (VM)。
Azure Linux VM
若要验证 Azure 虚拟机代理（VM 代理）是否正在运行并已在计算机上触发相应的操作和自动修补请求的序列号，请检查 /var/log/waagent.log 中的代理日志以获取详细信息。 每个 AutoPatching 请求在计算机上都有一个与之关联的唯一序列号。 查找如 2021-01-20T16:57:00.607529Z INFO ExtHandler 所示的日志。
扩展的包目录为 /var/lib/waagent/Microsoft.CPlat.Core.Edp.LinuxPatchExtension-<version>。 子 /status 文件夹中包含一个 <sequence number>.status 文件。 该文件包含单个 AutoPatching 请求和状态期间执行的操作的简要说明。 其中还包含应用更新时发生的错误的简短列表。
要查看与扩展执行的所有操作相关的日志，请在 /var/log/azure/Microsoft.CPlat.Core.LinuxPatchExtension/ 中查看更多相关信息。 该目录包含以下两个相关的日志文件：
<seq number>.core.log：包含与修补操作相关的信息。 此信息包括在计算机上评估并安装的修补以及在此过程中遇到的任何问题。<Date and Time>_<Handler action>.ext.log：修补操作上面有一个用于管理扩展和调用特定修补操作的包装器。 此日志包含有关该包装器的详细信息。 对于 AutoPatching，日志<Date and Time>_Enable.ext.log包含有关是否调用了特定修补操作的相关信息。
Azure Windows VM
要验证 VM 代理是否正在运行、是否已在计算机上触发了相应的操作以及 AutoPatching 请求的序列号，请查看 C:\WindowsAzure\Logs\AggregateStatus 中的代理日志以了解更多相关信息。 扩展的包目录为 C:\Packages\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version>。
要查看与扩展执行的所有操作相关的日志，请在 C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version> 中查看更多相关信息。 该目录包含以下两个相关的日志文件：
WindowsUpdateExtension.log：包含与修补操作相关的信息。 此信息包括在计算机上评估并安装的修补以及在此过程中遇到的任何问题。CommandExecution.log：修补操作上面有一个用于管理扩展和调用特定修补操作的包装器。 此日志包含有关该包装器的详细信息。 对于 AutoPatching，该日志包含有关是否调用了特定修补操作的相关信息。
在为专用的、迁移的和还原的 VM 进行创建的期间使用定期评估策略时，定期评估未正确设置
原因
由于当前的修改策略的设计方式，在为专用的、迁移的和还原的 VM 进行创建的期间，定期评估未正确设置。 创建后，该策略在合规性仪表板上会将这些资源显示为不合规。
解决方法
在创建后运行修正任务以修正新创建的资源。 有关详细信息，请参阅使用 Azure Policy 修正不合规的资源。
计划修补的先决条件未正确设置，在为专用化、通用化、迁移和还原的 VM 创建期间使用特定策略时，不会附加计划
原因
由于当前“如果不存在则部署”策略的设计方式，在创建专用、通用、迁移和恢复的虚拟机时，使用“使用 Azure Update 管理器安排定期更新”和“在 Azure 虚拟机上设置安排定期更新的前提条件”策略时，没有正确设置计划修补和附加计划的前提条件。 创建后，该策略在合规性仪表板上会将这些资源显示为不合规。
解决方法
在创建后运行修正任务以修正新创建的资源。 有关详细信息，请参阅使用 Azure Policy 修正不合规的资源。
库映像和具有加密磁盘的映像的策略修正任务失败
问题
对于虚拟机模式下引用库图像的虚拟机，修复会失败。 这是因为它需要库映像的读取权限，并且它当前不属于虚拟机参与者角色。
原因
虚拟机参与者角色没有足够的权限。
解决方法
- 对于所有新分配，将引入最近的更改，为在策略分配期间创建的托管标识提供“参与者”角色以进行修复。 今后，将为任何新分配分配此角色。
- 对于以前的任何分配，如果遇到修复任务失败，我们建议按照通过定义的角色向托管标识授予权限下列出的步骤手动将参与者角色分配给托管标识
- 此外，如果链接资源（库映像或磁盘）位于其他资源组或订阅中时参与者角色不起作用，请按照通过定义的角色向托管标识授予权限中的步骤手动向托管标识提供正确的角色和范围权限，以解除阻止修复。
无法为已启用 Arc 的服务器生成定期评估
问题
已启用 Arc 的服务器所加入的订阅不会生成评估数据。
解决方法
确保 Arc 服务器订阅已注册到 Microsoft.Compute 资源提供程序，以便按预期定期生成定期评估数据。 了解详细信息
当 VM 移至其他订阅或资源组时不会应用维护配置
问题
当 VM 移至另一订阅或资源组时，与 VM 关联的计划维护配置不会运行。
解决方法
系统当前不支持跨资源组或订阅移动资源。 一个变通方法是，对要移动的资源使用以下步骤。 作为先决条件，请先删除分配，然后再按照步骤操作。
如果使用 static 范围：
- 将资源移动到不同的资源组或订阅。
- 重新创建资源分配。
如果使用 dynamic 范围：
- 启动或等待下一次计划性运行。 此操作会提示系统完全移除分配，以便可以继续执行后续步骤。
- 将资源移动到不同的资源组或订阅。
- 重新创建资源分配。
如果缺少任何步骤，请将资源移动到以前的资源组或订阅 ID，然后重新尝试这些步骤。
注意
如果删除资源组，请使用相同的名称重新创建它。 如果删除订阅 ID，请联系支持团队寻求帮助。
无法将补丁编排选项从自动更新更改为手动更新
问题
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 更新错误代码列表中的相关错误代码，以查找有关异常原因的详细信息。 |
0x8024402C0x8024401C0x8024402F |
指示网络连接问题。 请确保你的计算机具有与更新管理的网络连接。 有关所需端口和地址的列表，请参阅网络规划部分。 |
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 更新是否存在任何问题。
注意
根据 Windows 更新故障排除程序文档，该程序不仅适用于 Windows 客户端，还适用于 Windows Server。
计划修补的已知问题
- 对于并发或有冲突的计划，只会触发一个计划。 完成一个计划后，会触发另一个计划。
- 如果计算机是新建的，则对于 Azure 虚拟机，计划可能会出现 15 分钟的计划触发器延迟。
- 策略定义（使用 Azure 更新管理器版本 1.0.0 预览版计划定期更新）可成功修复资源。 但是，这些更新始终显示为不符合要求。 存在条件的当前值是一个占位符，其计算结果总是为 false。
计划修补失败并出现错误“ShutdownOrUnresponsive”
问题
计划修补尚未在 VM 上安装补丁，发出了“ShutdownOrUnresponsive”错误。
解决方法
由于已知限制，在 8 小时内用相同资源 ID 删除和重新创建的计算机上触发的计划可能会失败，并出现 ShutdownOrUnresponsive 错误。
无法为关闭的计算机应用补丁
问题
补丁不会应用于处于关闭状态的计算机。 你可能还会发现计算机正在丢失其关联的维护配置或计划。
原因
计算机处于关闭状态。
解决方法
在计划更新之前至少提前 15 分钟让计算机保持打开状态。 有关详细信息，请参阅关闭计算机。
即使还有剩余时间，补丁也运行失败并且“超过维护时段”属性显示为 true
问题
在“更新历史记录”中查看更新部署时，属性“失败并超过维护时段”显示为 true，即使还有足够的执行时间，也是如此。 在这种情况下，可能会出现以下问题之一：
- 未显示更新。
- 一个或多个更新处于“挂起”状态。
- 重启状态为“必需”，但即使传递的重启设置为
IfRequired或Always，也未尝试重启。
原因
在部署更新期间，系统会通过多个步骤检查维护时段的使用。 将在维护时段中留出 10 分钟时间以便随时重启。 在部署获取缺失更新的列表或者下载或安装任何更新（Windows 服务包更新除外）之前，系统将验证是否有 15 分钟 + 10 分钟时间用于重启（即，在维护时段中留出 25 分钟）。
对于 Windows 服务包更新，部署会检查是否有 20 分钟 + 10 分钟（即 30 分钟）时间用于重启。 如果部署没有足够的剩余时间，则会跳过更新的扫描/下载/安装。 然后，部署运行将检查是否需要重启，以及是否在维护时段中留出了 10 分钟时间。 如果留出了该时间，部署会触发重启。 否则会跳过该重启。
在这种情况下，状态将更新为“失败”，而“超过维护时段”属性将更新为 true。 如果剩余时间少于 25 分钟，则不会扫描更新或尝试安装更新。
若要查找详细信息，请查看部署运行的错误消息所提供的文件路径中的日志。
解决方法
在触发按需更新部署时，为最大持续时间设置更长的时间范围有助于避免该问题。
后续步骤
- 若要详细了解更新管理器，请参阅概述。
- 若要查看所有计算机的已记录结果，请参阅从更新管理器查询日志和结果。