Microsoft AZ-801: Windows Server 更新和补丁管理 — 学习指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

属于 Microsoft Windows Server Hybrid Administrator Associate AZ-801 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Windows Server 的补丁管理涵盖本地和 Azure 托管的工作负载，它结合了用于精细审批工作流的 WSUS、用于分环部署的 Windows Update for Business (WUfB) 策略、用于规模化管理的 Azure 编排以及强大的合规性报告。成功的策略需要标准化扫描源、隔离测试和试点环、在维护时段内控制重启，并持续清理元数据以保持性能的可预测性。混合环境的管理员还必须了解现代 Azure 功能，例如 Update Management Center、虚拟机来宾自动修补和适用于 Windows Server Azure Edition 的热修补，以便在维持安全态势的同时最大限度地减少停机时间。

WSUS 架构与管理

一个精心设计的 WSUS 拓扑始于一台从 Microsoft Update 同步元数据（以及可选的内容）的上游服务器。下游服务器订阅该上游服务器。在副本模式下，下游服务器会继承上游服务器的审批、计算机组和设置，以实现集中控制——这对于分支机构非常理想。在自主模式下，下游服务器接收更新元数据，但自行做出审批决策——这在区域团队控制维护时非常有用。应为选定的语言、产品和分类的元数据安排每日同步。对于大型部署，请配置 SSL（端口 8531）以保护客户端扫描流量和 WSUS 间的复制。

审批规则是实现分环部署的运营基础。自动审批规则可以为一个预生产组立即批准 Security Updates（以及可选的 Critical Updates），而其他环则延迟数天或数周。对于广泛部署，请使用带有截止日期的显式审批；截止日期会强制在指定时间前完成安装，无论客户端的“活动时间”如何。计算机组定义了环和工作负载层级（Pilot、Broad 和 Critical 服务器）。组分配可以是服务器端或客户端的。使用服务器端目标指定时，新客户端会出现在 Unassigned Computers 中，管理员再将其移动到 WSUS 组中。使用客户端目标指定时，通过组策略设置 TargetGroup 和 TargetGroupEnabled，使计算机在首次扫描时自动注册到指定的 WSUS 组中——这更适合大规模和基于 OU 的动态放置。

客户端 GPO 必须通过启用 Specify intranet Microsoft update service location（包括更新服务和统计服务器）将 Windows Update Agent 指向 WSUS。设置 Configure Automatic Updates（例如，选项 4，自动下载并计划安装）和 Automatic Updates detection frequency 来控制扫描频率。对于服务器，设置 No auto-restart with logged on users 和 Turn off auto-restart for updates during active hours 以避免干扰性重启；然后使用维护时段或编排工具来协调重启行为。如果环境中存在 WUfB 策略，请启用 Do not allow update deferral policies to cause scans against Windows Update 来防止客户端绕过 WSUS 并扫描 Windows Update。

要维持性能，WSUS 的健康维护是必不可少的。WSUS 清理向导会移除被取代和已过期的更新，删除过时的更新文件，并清理在设定时间间隔内未联系 WSUS 的过时计算机。使用

undefined

将清理工作脚本化，并在导入大量更新的同步操作后运行。

对于规模和稳定性而言，WSUS 数据库维护是必不可少的。已过期的更新应被拒绝；被取代的更新可以在其替代品在生产环境中达到稳定状态后被拒绝。使用微软的

undefined

定期对 SUSDB 重建索引和更新统计信息。不要依赖收缩操作；应专注于索引的健康状况。对于非常大的环境，将 SUSDB 从 WID 迁移到完整的 SQL Server 实例，以利用其高级索引、更好的 I/O 和原生的 SQL Agent 调度功能。避免选择过多的产品和语言——仅限于您实际部署的内容，以减少元数据搅动和审批开销。

云端编排更新：WUfB、Update Management Center、VM 来宾修补和热修补

Windows Update for Business (WUfB) 通过基于环的延迟和暂停，控制设备何时直接从 Microsoft 的 CDN 接收功能更新和质量更新。延迟策略（通过 GPO 或 Intune）可设置“选择何时接收预览版本和功能更新”以及“选择何时接收质量更新”。功能更新的典型值为 0-365 天，质量更新的典型值为 0-35 天。“暂停更新”功能可从指定的开始日期起，将功能更新或质量更新的安装暂停最多 35 天——这在调查问题期间暂缓部署时非常有用。“环”通过具有不同延迟和暂停参数的独立策略分配来实现，随着信心的增加，部署范围会从 IT/试点环逐步扩大到广泛部署环。当您不需要 WSUS 审批，或者倾向于使用云内容交付和安全保障措施时，应使用此方法。

Azure 中的 Update Management Center (UMC) 为 Azure VM 和已启用 Arc 的服务器提供了现代化的更新编排能力。评估计划定义了计算机何时计算其缺失的更新和合规性状态——通常每天进行，以确保仪表板保持最新。修补策略定义了要安装的内容和时间：您可以选择分类、包含/排除 KB、定义带时区的维护时段、设置重启行为（如果需要则重启、始终重启或从不重启），以及选择编排选项。动态范围界定使用订阅、资源组、位置或标记将策略附加到一组动态变化的计算机上；当添加具有匹配标记的计算机时，它们会自动被包含在内。这解决了大规模治理的问题，无需手动维护目标列表。对于可用性集和规模集，UMC 会跨更新域错开修补时间，以维护仲裁和服务健康。

自动 VM 来宾修补将“关键”和“安全”更新的选择和安装工作委托给 Azure 平台。评估按照 Azure 管理的节奏运行；修补编排会遵循可用性结构，以最大程度地减少影响。重启设置可配置为“如果需要”(IfRequired)、“始终”(Always) 或“从不”(Never)；仅当您有外部重启协调机制时，才选择“从不”。对于需要的不仅仅是安全更新或需要特定冻结时段的服务器，应使用 UMC 的计划性修补部署，而不是完全自动模式。

对于受支持的 Windows Server Azure Edition 的 Azure 映像，热修补功能可为大多数月度安全更新免去重启操作。受支持的操作系统版本包括 Windows Server 2022 Datacenter: Azure Edition 和更新的 Azure Edition 版本。其服务模型在基线月份和热修补月份之间交替进行。基线月份会交付一个累积更新，该更新会建立一个新的基线并需要一次重启；随后的热修补月份会应用内存中修补程序且无需重启，从而显著减少停机时间。请围绕基线月份规划维护，并使用 UMC 或策略来确保每个周期至少应用一个基线，以整合无法热修补的更改。

合规性报告与旧版 Azure 更新管理

更新合规性报告必须同时满足高层管理的可视性需求和运营层面的根本原因分析需求。Windows Update for Business 报告提供设备级别和聚合级别的洞察，涵盖更新状态、安全保留、功能版本采用情况和故障诊断。设备将所需的诊断数据发送到与报告解决方案关联的 Log Analytics 工作区；可以通过 Intune、用于 Commercial ID 的 GPO 注册表项或用于服务器的 Azure Arc 来完成载入。使用内置的 Azure Monitor 工作簿按更新环、操作系统版本和更新类别对合规性数据进行切片分析；将关键图表固定到 Azure 仪表板，以供 NOC 查看。

Azure Update Management (旧版) 结合了 Azure Automation 帐户和 Log Analytics 工作区。计算机（Azure VM 和已启用 Arc 的服务器）将评估数据报告给 Log Analytics；计划的部署会调用 Automation runbook，以在定义的维护时段内协调补丁安装。可控制的参数包括分类、要包含/排除的 KB、前置/后置脚本以及重启策略。虽然已被 Update Management Center 取代，但旧版 Update Management 在棕地环境中仍然很重要；迁移规划应将计划、范围和 runbook 行为映射到 UMC 的补丁策略和动态范围界定。

补丁分类和严重性经常被混为一谈，但两者对于策略制定都很重要。“安全更新”是用于修复漏洞的更新的分类。在安全更新中，来自 Microsoft 安全响应中心的严重性评级分为“严重 (Critical)”、“重要 (Important)”、“中等 (Moderate)”和“低 (Low)”。“严重”通常表示远程代码执行或可广泛传播的蠕虫影响；“重要”通常包括权限提升或信息泄露；“中等”和“低”则反映了有限的可利用性或存在缓解措施。在 WSUS 和 Azure 策略中，首选方案是快速将安全更新（所有严重性）部署到试点环，并在遥测数据确认稳定性后扩大部署范围，同时根据业务对变更的容忍度来安排非安全的质量更新。

最后，保持运营节奏。定期在验证后拒绝过期的和被取代的更新，每月运行清理向导和 SQL 索引维护，协调在 SLA 内未联系 WSUS 或 Azure 的客户端，并持续评估更新环的延迟和暂停逻辑。对于混合设备群，为每台设备标准化扫描源，要么使用 WSUS，要么使用 WUfB；不要在单个服务器上混合使用。使用 Azure Arc 统一治理，使云端和本地服务器出现在同一个合规性结构中。

实际问题场景

Fabrikam, Inc. 运营着 600 台 Windows Server 计算机：250 台位于严格出口控制下的本地服务器，250 台托管分层应用程序的 Azure VM，以及 100 台运行 Windows Server 2022 Datacenter: Azure Edition 的 Azure VM。他们需要可预测的周二补丁修复，同时要求停机时间最短、集中报告和零手动目标设定。

建立扫描源和更新环

对于本地服务器，在数据中心部署一个中央上游 WSUS，并在分支机构部署两个下游副本服务器。通过 GPO 强制执行客户端目标设定，以便服务器自动注册到 WSUS 组 Pilot-Servers、Broad-Servers 和 Finance-Servers 中。这确保了无需互联网扫描即可进行确定性的内容审批。
对于 Azure VM，使用 Update Management Center 并通过标签 Ring=Pilot 或 Ring=Broad 进行动态范围界定，以避免手动维护列表。这可以在云计算机预配时自动将其与更新环的意图对齐。原因：WSUS 满足出口限制和细粒度审批的要求；UMC 提供云规模的协调和标签驱动的治理。

定义审批和延迟策略

在 WSUS 中，立即为 Pilot-Servers 自动批准安全更新；为 Broad-Servers 设置 7 天的截止日期进行批准。非安全的质量更新首先批准给 Pilot-Servers，验证后再进行推广。
在 UMC 中，创建两个补丁策略：Pilot 在“补丁星期二”的第二天安装安全和质量更新；Broad 将质量更新延迟 7 天。两者都在 2 小时的维护时段内，在需要时执行重启。原因：更新环可以及早发现回归问题，同时缩短漏洞的修复时间。

在 Azure Edition 服务器上启用热补丁

将适用的 Azure Edition VM 迁移到支持热补丁的映像，并将其注册到遵循基线月份的 UMC 补丁策略中。确保每个基线周期至少应用一个基线。原因：热补丁消除了 100 台 Azure Edition 服务器上的大多数重启，在保留 SLA 的同时仍然应用每月的安全修复程序。

为边缘案例配置 VM 来宾自动修补

对于低风险的实用工具 VM，启用仅限于安全更新的 VM 来宾自动修补 (AutomaticByPlatform)，并在需要时于工作时间之外重启。原因：减轻了那些无需精细控制的系统的运营负担。

为 WSUS 客户端强化 GPO

设置“指定 Intranet Microsoft 更新服务位置”、“配置自动更新”、“检测频率”以及“不允许更新延迟策略导致针对 Windows Update 的扫描”。为服务器配置“登录用户存在时不自动重启”。原因：防止扫描源冲突和在服务时间内发生不必要的重启。

实施合规性报告

使用 Azure Arc 将所有本地服务器载入到 Windows Update for Business 报告，并为 Azure VM 使用本机集成，将所需的诊断数据发送到专用的 Log Analytics 工作区。发布按更新环和环境分段的 Azure Monitor 工作簿。原因：跨混合资产的单一窗格报告，并可深入钻取到故障诊断。

维护 WSUS 健康状况和数据库性能

每月运行 WSUS 清理向导（修剪过期的/被取代的更新、过时的计算机），在验证后拒绝被取代的更新，并执行 WSUSDBMaintenance.sql 来重建 SUSDB 的索引。将产品/语言限制为 Fabrikam 实际部署的那些。原因：保持同步和审批操作的快速性，减少客户端扫描时间，并避免数据库膨胀。