Windows 虚拟机补丁管理的可扩展性

本文介绍在工作负荷中的Windows虚拟机（VM）上操作操作系统更新的建议方法。 此过程在工作负荷中的Windows VM 群中提供一致的、可缩放且受治理的修补程序管理解决方案。 在将更新提升到生产环境之前，使用此方法可以验证预生产环境中的更新。

有效的修补程序管理超出了安装更新的范围。 修补程序管理策略还需要一致的治理，以确保虚拟机加入修补程序管理解决方案，根据工作负荷标准进行配置，并持续监视符合性。

使用Azure 更新管理器

在Azure Windows 虚拟机上管理Windows OS 更新的建议方法是使用Azure 更新管理器。 此服务提供集中的计划、符合性报告，以及为 VM 执行分阶段 OS 更新部署的功能。 Azure 更新管理器可通过在工作负荷中的每个 VM 上安装的 sidecar Azure VM 扩展工作。 更新管理器本身不托管或分发修补程序。 它负责控制并激活每个虚拟机上的原生Windows 更新代理（WUA）。

Azure 更新管理器为工作负荷团队提供环境中虚拟机的修补状态的中心视图。 你可以设置补丁目标和周期，并支持按需部署补丁。

Azure资源组织

Azure 更新管理器本身不是Azure资源。 你不会将其部署到你的工作负载所属的订阅中。 可在 Azure 门户中使用，并且门户中的用户体验基于 RBAC，且与订阅无关。 但是，维护配置、要应用哪些 OS 补丁以及何时应用这些补丁，还有它们作为 Azure 资源与你的工作负载 VM 的关联关系，都由你来维护。

每个维护配置只能有一个计划，并且可以通过关联关系将任意数量的资源设为目标。 维护配置是区域性资源。 使用单个维护配置和关联关系，仅将位于同一区域且属于同一订阅的虚拟机纳入其中。 此方法意味着对于所有环境都有单独的维护配置资源，如果工作负荷是多区域或工作负荷的不同部分有不同的更新计划，则每个环境可能有多个资源。

将维护配置资源作为该环境中工作负载的 IaC 的一部分进行维护。 此方法允许你执行变更控制过程、安全部署做法，并提供灾难恢复选项。

虚拟机要求

Windows虚拟机必须是受支持的自定义映像或Azure 市场映像。 无论源是什么，都需要将 OS 配置为支持更新。 推荐的方法是通过虚拟机的 IaC 来配置所需的操作系统设置。 具体而言，请确保 VM 至少具有以下设置：

windowsConfiguration: {
  provisionVMAgent: true
  enableAutomaticUpdates: true

  patchSettings: {
    patchMode: 'AutomaticByPlatform'  // Disables automatic updates in the OS; now platform triggers updates
    assessmentMode: 'AutomaticByPlatform' // Scans for missing updates every 24 hours

    automaticByPlatformSettings: {
      bypassPlatformSafetyChecksOnUserSchedule: true  // Allows Azure Update Management to honor defined schedules
      rebootSetting: 'IfRequired'  // Or 'Never' if required in your workload
    }
  }
}

Windows 来宾代理会安装一个名为 Microsoft.CPlat.Core.WindowsPatchExtension 的 Sidecar 扩展。 此特权扩展在 VM 上运行，以获取其计划和更新配置。 它还调用本机Windows OS 更新 API 来执行更新。 不会将此扩展定义为 VM IaC 的一部分。 更新管理器会自动安装并维护其生命周期。

WindowsPatchExtension 扩展不会替代计算机上的更新源设置。 此行为意味着你仍负责为 VM 配置更新源：

• Windows 更新存储库（Windows OS + 选择驱动程序）
• Microsoft 更新存储库（Windows 操作系统 + 部分驱动程序 + 部分 Microsoft 产品）
• 如果你的组织仍要求工作负载使用该服务器，则需使用 Windows Server 更新服务 (WSUS) 服务器 （现已弃用）

有关支持的源的详细信息，请参阅支持的更新源、类型、Microsoft应用程序更新和非Microsoft更新。

启用自动评估，使 合规性报告 反映当前数据。 借助此功能，您可以查看每个 VM 相对于补丁基线的状态，并在下次计划运行前发现新近披露的安全暴露。 评估仅涵盖正在运行的 VM;不会扫描已停止或解除分配的 VM。

策略执行

您的工作负载还应使用 Azure Policy 来强制确保虚拟机始终保持符合 Azure 更新管理器 要求的正确配置。 将内置Azure 更新管理器策略作为配置偏移防护机制。 内置策略支持 DINE（DeployIfNotExists），并修改强制措施以自动修正不合规的 VM。

有关采用策略驱动的方法进行补丁管理的信息，请参阅 使用策略在 Azure VM 上启用定期评估和计划性修补。 如果工作负荷未使用 IaC 来部署和配置 VM，请使用此方法。

网络要求

对于具有直接出站互联网访问能力的 Azure 虚拟机，Windows 更新 通常无需额外将网络加入允许列表，前提是来宾操作系统的更新源、DNS、代理、TLS 检查和本地策略设置允许 Windows 更新/Microsoft Update 流量。 但是，大多数工作负荷在具有受限出站访问的锁定虚拟网络中运行。 在这些情况下，您必须在所有出站流量经过的 NSG 和防火墙中允许流量访问 Microsoft Update 终结点。

网络安全组 (NSG)

默认更新源（包括Windows更新）是基于 DNS 的，不会发布稳定的静态 IP 列表。 对于 Internet 托管的更新源，此条件意味着附加到虚拟机 NIC 或其子网的 NSG 必须支持到 TCP：443 和 TCP：80 的 Internet 出口流量。 你还应在出口防火墙内部进一步限制访问。 如果更新来自静态 IP 地址范围（例如本地源），则应显式定义 NSG 中的出站目标。

出口防火墙

出口防火墙必须允许访问更新源所使用的 FQDN 的流量。 如果你正在使用 Azure 防火墙 和 Microsoft 提供的更新源，请使用 WindowsUpdate FQDN tag 来允许对 Windows 更新 终结点的出站访问。 有关网络路径中的其他出口防火墙，请参阅 配置防火墙。 应仅允许源自Windows VM 的此流量，而不是工作负荷中的不相关子网。

将 VM 与维护配置相关联

虽然可以在维护配置与 VM 之间创建静态关联，但请改用动态范围。 动态范围基于资源组、位置和标签等属性，确定哪些 VM 与维护配置关联。 维护配置（而不是动态范围）定义安装哪些更新以及何时进行更新。 动态作用域可将匹配的新 VM 纳入管理，而无需您管理针对每个 VM 的配置关联资源。

使用动态范围规则时，请遵循以下建议：

• 将动态范围规则作为 IaC 作为工作负荷的一部分进行管理。
• 仅纳入您所在环境中的虚拟机，以避免跨环境依赖关系，并按需在各个环境之间复制配置和动态作用域规则。
• 使用标记作为主要驱动程序，并通过Azure Policy强制执行其用法。

设计分阶段修补计划

工作负载的典型补丁计划采用分阶段部署计划。 Microsoft每月更新发布后，首先将更新应用于开发和测试虚拟机。 验证后，在单独的维护窗口中，将同一分类的更新先部署到预生产环境，然后再部署到生产环境。

创建维护配置以定义定期、维护时段、更新分类和重新启动行为。 然后创建动态范围界定关联，以将工作负载中的 VM 设为目标来执行例行补丁计划。

与补丁星期二对齐的时间安排通常会在部署到生产环境之前留出几天时间进行验证。 由于Microsoft的每月安全更新通常在每个月的第二个星期二发布，因此建议的方法可能如下所示。 在此示例中，目标虚拟机通过使用标记的动态范围界定规则进行管理。

处理更新并发问题

维护配置会同时对所有关联的 VM 启动更新。 Azure 仅对处于同一可用性集中的 VM 按更新域依次重启。 在此示例中，后端和前端波次是按层级划分计划的，而不是按冗余容量划分，因此某一层级中的所有实例都可能同时重启，导致该层级的可用容量降到其所需容量以下。

在每个生产层级中，将补丁部署拆分为多个保持容量的波次，并使这些波次与可用性区域、更新域或按工作负载定义的实例组相对应。 每波使用不同的标记值和维护配置。

考虑发布的一致性

更新管理器在每次运行时执行新的评估。 这意味着，基于分类的计划可以在后续波次中选择不同的 KB。 如果每个波次 必须 安装完全相同的一组经过验证的更新，请显式指定要包含的 KB，而不要仅依靠分类。

这可以通过使用更新管理器 REST API 从第一波查询评估结果，然后更新后续波的维护配置来自动完成。

为了实现完全的波次一致性，你所付出的代价是显著的编排复杂性。 如果你的工作负载可以承受后续批次安装与第一批次不同的 KB 这一风险，请使用基于分类的计划。

通过热补丁减少重启

重新启动通常是修补计划中最中断的部分。 它们决定了上表中的维护时段时长和重启行为。 在受支持的映像上，热修补通过修补正在运行的进程的内存中代码来安装 Windows 安全更新，因此在大多数月份，无需重启即可应用这些更新。 Hotpatch 是 Windows 更新 的一项扩展，因此 Azure 更新管理器 会通过与你用于其他 VM 的相同维护配置和动态作用域来安装热补丁。

如果您的工作负载对重启敏感，请采用支持热补丁的操作系统 SKU，并进行相应设计：

• 热补丁仅适用于特定 Windows 映像。 不能对任意自定义映像启用热修补。

• 只有 Windows 安全更新支持热补丁。 非安全更新、.NET更新和驱动程序或固件更新在发布后几个月仍需要重新启动。 季度热补丁基线以及 Microsoft 为修复零日漏洞而发布的任何计划外基线也都需要重新启动。 预留一个能够涵盖重启所需时间的维护窗口。

处理“before”和“after”问题

Azure 更新管理器评估和安装操作系统更新，但成功的修补过程可能包括维护时段前后的活动，以正常处理所需的重启或应用程序特定的问题。 更新管理器提供在工作负荷自动化中使用的 预事件和后事件 。 你可以在工作负载的架构中添加事件处理程序（例如 Azure Function），以响应计划修补运行前后的 Azure 事件网格 通知。

使用更新管理器的预修补操作来执行以下任务，例如：

• 启动已停止或解除分配的 VM。 已停止或已解除分配的虚拟机无法应用修补程序，因此将被跳过。
• 验证备份恢复点是否可用。
• 验证虚拟机和应用程序运行状况。
• 暂时禁止监视警报，以防止在维护时段内出现误报。

安装更新后，可通过补丁安装后的操作执行以下任务，例如：

• 恢复监控。
• 执行应用程序和服务运行状况检查。
• 向Microsoft Teams频道发布通知。

将Azure 事件网格和事件处理程序计算视为工作负荷资源。 使用 IaC 部署它们，并在环境之间隔离它们。

为按需更新做好准备

Azure 更新管理器支持在任何计划维护时段之外进行按需修补安装。 此功能可用于在更广泛的计划推出之前在单个 VM 上应用紧急修补程序、关键周期外修复或验证修补行为。 可以直接从Azure门户或针对一个或多个 VM 的更新管理器 REST API 触发按需更新。 作为工作负载团队，请制定有关何时执行带外更新以及如何在整个工作负载中统筹安排这一流程的指导原则。

回滚更新

Azure 更新管理器 不提供操作系统补丁回滚。 应用修补程序后，没有内置机制可以直接通过更新管理器卸载它们。

如果您的工作负载需要支持“最后已知正常”状态，请在执行维护操作之前创建快照或恢复点。 自动创建快照以在每个修补窗口之前运行，以确保在应用修补程序之前始终存在恢复点。 或者，在没有修补程序的情况下重新部署 VM，从部署中排除有问题的 KB 修补程序，然后重新应用更新。

合规性报告

更新管理器将评估结果和补丁安装结果推送到 Azure Resource Graph，后者会将待定更新存储 7 天，并将安装结果存储 30 天。 Azure 更新管理器包括内置的合规性报告和管理视图，这些视图可让你了解环境中更新状态。 这些仪表板使管理员能够监视修补程序符合性、识别需要注意的计算机，并从中心位置跟踪更新部署进度。

预定义工作簿在工作负载中显示关键信息：

• 计算机状态和配置的总体摘要
• 按严重性和分类划分的待处理更新明细
• 计划、维护配置以及与每个计划关联的机器的摘要
• 过去安装运行的历史视图，包括成功率和任何失败

许多组织要求其应用程序团队也提供合规性报告。 理想情况下，贵组织已经使用 Azure 更新管理器 来跟踪这些信息，因为 Azure 更新管理器 门户和工作簿可以跨订阅运行，而且您无需在自己的工作负载中提供任何自定义补丁状态报告。

如果你或你的组织需要预定义视图之外的自定义报告，则工作簿是可自定义的。 在工作负荷的 IaC 文件中包括自定义工作簿，以应用更改控制过程并提供灾难恢复选项。 另一种方法是通过Azure Resource Graph查询提供所需的符合性报告数据。

如果工作负荷必须保留比Azure Resource Graph提供的时间更长的修补程序历史记录，请生成一个过程，以将数据导出到你控制的存储。

替代方法

如果你决定不为工作负载采用 Azure 更新管理器 的计划式分阶段方法，请先评估VM 来宾自动修补，再设计任何自定义方案。 使用此选项，Azure为你安排修补。 但是，如果你选择这种方式，你将放弃以下内容：

• 分阶段推出。 更新不会在开发、测试和生产阶段之间推进，因此会失去验证关卡。

• 维护时段控制。 Azure 会决定在每个 VM 所在时区的非高峰时段何时进行修补。

• 更新分类控件。 仅应用关键更新和安全更新。 不会自动安装其他分类。

Contributors

Microsoft维护本文。 以下贡献者撰写了本文。

主要作者：

• 泰德曼·李 |高级解决方案工程师

若要查看非公开的领英个人资料，请登录领英。

后续步骤

• 了解更新管理器的工作原理
• 维护配置服务限制：查看计划、资源关联和动态范围的限制。
• 使用前置事件和后置事件安排执行顺序：了解前置事件和后置事件的时间窗口及取消行为，以便在每个维护窗口前后预留足够的提前量。