Microsoft AZ-801: Azure Arc 和混合服务器管理 — 学习指南

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.

概述

Azure Arc 将非 Azure 服务器（本地或其他云中的服务器）纳入与原生 Azure 资源相同的控制平面下。已启用 Arc 的服务器会作为一等 Azure 资源呈现，因此您可以应用 Azure Policy、管理扩展、使用 Azure Monitor Agent 收集遥测数据、通过 Update Management Center 编排补丁，以及利用 Azure Automanage 实现标准化。要安全、一致地运营混合型服务器群，必须熟练掌握载入模式、代理和网络要求、基于角色的访问控制 (RBAC) 以及大规模治理。

已启用 Azure Arc 的服务器：载入、先决条件、网络、RBAC 和安全访问

载入过程通过安装 Azure Connected Machine 代理 (azcmagent) 将计算机连接到 Azure，该代理会将服务器注册到选定的订阅、资源组和区域中。

脚本化交互式载入是上手的最快方法。从 Azure 门户生成“添加服务器”脚本并在本地运行。该脚本会下载并安装代理，然后使用设备代码流对您的用户进行 Azure Resource Manager 身份验证，并创建 ConnectedMachine 资源。
基于服务主体的载入是推荐的生产环境方法。创建一个 Microsoft Entra 应用注册，并为其分配作用域限定于目标资源组的 Azure Connected Machine Onboarding 角色，以此创建最低权限凭据。将服务主体 ID 和密钥传递给载入脚本，以便通过您现有的工具（Configuration Manager、Group Policy、Ansible 或自定义自动化）实现无人值守和大规模部署。
使用 Azure Policy 进行大规模启用侧重于载入后的标准化。Azure Policy 无法在非 Azure 计算机上安装 Arc 代理，但一旦计算机连接到 Arc，即可分配策略，为数千台服务器自动部署所需的扩展（Azure Monitor Agent、Dependency Agent、Custom Script）和来宾配置基线，并进行漂移检测和修复。经测试，这是将 Arc 服务器载入到 Microsoft Sentinel 或 VM insights 等服务中的最省力方法。

支持的操作系统包括 Windows Server 2012 R2、2016、2019 和 2022，以及常见的企业级 Linux 发行版，如 Ubuntu LTS (18.04+)、RHEL 7–9、SLES 12/15、Oracle Linux 7/8/9、CentOS 7 和 Amazon Linux 2。在进行大规模部署之前，请务必在最新文档中核实确切的版本和内核要求。

代理的先决条件很简单：TLS 1.2、出站 HTTPS (TCP 443)、为代理缓存和扩展提供足够的磁盘和内存、稳定的计算机时钟，以及用于安装的管理员/root 权限。对于代理，该代理在 Windows 上支持系统代理 (WinHTTP)，并在两个平台上都支持显式代理。使用 azcmagent config set proxy.url=https://user:pass@proxy:port 来配置 azcmagent 以使用代理，或在 Windows 上利用 netsh winhttp set proxy。如果您的环境使用 TLS 检查，请将代理的受信任根 CA 导入到计算机存储中，以便代理可以验证 Azure 端点。

防火墙和出口允许列表必须允许到 Microsoft Entra ID（用于身份验证）、Azure Resource Manager 和区域性 Arc 服务的出站 443 端口流量。如果您将使用 Update Management Center 和 Automanage，还需允许访问 Windows Update/Microsoft Update 和您的 Linux 发行版存储库，以及分发软件包的内容分发端点。Arc 不需要任何入站防火墙开放；所有控制流量都从服务器发起，流向 Azure。

已启用 Arc 的服务器的 RBAC 遵循 Azure 的模型。使用内置角色来分离职责：

Azure Connected Machine Onboarding 允许通过服务主体创建 ConnectedMachine 资源，同时防止授予更广泛的修改权限。
Azure Connected Machine Resource Administrator 负责管理 Arc 服务器资源及其扩展，而无需授予订阅范围的权限。
Azure Connected Machine User Login 和 Azure Connected Machine Administrator Login 在启用基于 Azure AD 的通过 SSH (Linux) 或 RDP/WinRM (Windows) 的登录时，控制交互式访问。将 Arc 计算机组织到能反映环境（生产/非生产）、地理位置、业务部门或补丁更新环的资源组中。在资源组或管理组级别限定策略、锁和角色分配的作用域，以简化治理。

Arc 的即时隧道技术支持在没有公共 IP 的情况下进行安全的 SSH 访问。安装 AADSSHLoginForLinux 扩展以启用基于 Entra ID 的身份验证，并将用户/组映射到本地主体。拥有相应登录角色的授权用户可以运行 az ssh arc –resource-group RG –name Server01，以建立到服务器 SSH 守护进程的临时出站 TLS 隧道——无需入站端口、VPN 或堡垒机。应用 Conditional Access 和 Privileged Identity Management 来为登录角色设置时间限制。

大规模治理和配置：Azure Policy 来宾配置和 Automanage

来宾配置是 Azure Policy 为 Arc 提供的虚拟机内部审核和配置能力。内置策略涵盖了常见的基线，例如确保安装 Azure Monitor 代理、审核密码策略、在支持的 Windows 上强制执行 BitLocker 或 FIPS 模式，或要求在 Linux 上使用特定的 syslog 设施。将这些策略大规模分配给 Arc 范围，平台会根据需要部署来宾配置扩展。对于自定义策略，您可以编写一个基于 DSC 的来宾配置包来表达所需状态（例如，强化的 SSHD 配置或 Windows 防火墙规则），将其发布为自定义策略定义，然后将其分配给您的 Arc 范围。

修复任务将审核转化为行动。具有 DeployIfNotExists 或 Modify 效果的策略可以创建或更改配置，您也可以触发按需修复，使现有计算机进入合规状态。对于重复性偏差，启用自动修复，以便策略引擎重新应用所需状态。在“合规性”边栏中按策略、按计算机和按范围跟踪合规性状态，并从同一用户界面向监管机构导出证据。

适用于已启用 Arc 的服务器的 Azure Automanage 将“计算机最佳实践”付诸实践。为开发/测试或生产环境选择一个合适的配置配置文件，平台会将计算机载入一组精选的服务中：Azure Monitor（通过 AMA 和 VM 见解配置文件）、具有已定义维护时段的更新管理中心、更改跟踪和清单、Microsoft Defender for Cloud 计划启用以及核心操作系统安全基线。Automanage 持续检测与所选配置文件的偏差，并在支持的情况下进行修复，同时提供对非 Azure 环境中任何需要手动干预的项目的可见性。由于 Automanage 在底层使用 Azure Policy，您可以大规模部署配置文件，并依赖相同的合规性报告模型。

运维和监控：更新管理中心、AMA 和 DCR 以及 Arc 扩展

更新管理中心 (UMC) 是适用于 Azure 和 Arc 计算机的现代化、轻代理补丁服务。它持续评估缺失的安全和非安全更新，按严重性和分类呈现合规性，并支持一次性和重复性维护配置。定义维护时段，包括最大持续时间、重启行为（从不、如果需要或始终）、前置和后置脚本，以及使用 Azure 查询和标记进行动态目标设定，以便符合条件的新 Arc 计算机被自动纳入。对于 Windows，UMC 从 Windows Update/Microsoft Update 获取源，如果已配置，则从 WSUS 获取；对于 Linux，则从配置的包存储库获取。使用合规性报告来按范围跟踪修补百分比，查看带有精细错误代码的失败记录，并导出数据以供审计。由于 UMC 不依赖于 Azure Automation 和旧版 MMA，因此它是补丁编排的战略性前进道路。

Azure Monitor 代理 (AMA) 是适用于已启用 Arc 的服务器的统一遥测管道。您无需在计算机上硬编码工作区，而是定义数据收集规则 (DCR) 来描述：

收集什么：Windows 事件日志、Linux syslog 设施和严重性、性能计数器以及更改跟踪信号。
发送到哪里：一个或多个 Log Analytics 工作区、Azure Monitor 指标，以及可选的事件中心。
如何转换：引入前可选的数据塑形。在资源、资源组、订阅或管理组范围关联 DCR。这将配置与计算机解耦，使得在工作区之间移动计算机或在不同环境中收集不同数据变得轻而易举。Arc 上的 VM 见解现在使用带有 VM 见解 DCR 配置文件的 AMA 来获取性能数据；对于依赖关系映射和进程拓扑，请安装 Dependency Agent。

扩展是虚拟机内部功能的交付机制。可以从 Arc 服务器的“扩展”边栏、CLI 或策略中管理它们：

Microsoft Monitoring Agent (MMA) 是旧版代理，对于大多数解决方案已停用；仅当某个依赖项尚未迁移到 AMA 时才使用它。
Azure Monitor 代理 (AMA) 是当前用于日志和指标的默认代理；请与 DCR 配对使用。
Dependency Agent 提供服务和进程映射，在其完全被取代之前，是 VM 见解映射所必需的。
自定义脚本扩展 (Windows/Linux) 在策略修复无法表达所需更改时，大规模执行脚本以进行引导或纠正操作。
AADSSHLoginForLinux 和 AADLoginForWindows 启用 Entra ID 登录。其他常见扩展包括 Defender for Endpoint 和配置管理客户端。使用 Azure Policy 来确保所需的扩展存在且运行状况良好。扩展的更新、回滚和状态在资源中以及用于审核的活动日志中都是可见的。

使用 Azure Resource Graph 进行清单、合规性和报告

Azure Resource Graph (ARG) 查询可以返回所有已启用 Arc 的服务器近乎实时的清单和合规性状态，且无需代理。您可以使用它来驱动 CMDB 同步、标签清理以及策略和补丁的作用域选择。常见模式包括：

按操作系统和位置划分的混合云清单：

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, resourceGroup, location, osName = properties.osName, osVersion = properties.osVersion, status = properties.status

Sentinel/AMA 就绪情况：

Resources
| where type == "microsoft.hybridcompute/machines"
| extend hasAMA = todynamic(properties.extensions) has_any (x: x.name =~ "AzureMonitorWindowsAgent" or x.name =~ "AzureMonitorLinuxAgent")
| project name, hasAMA

基于标签的报告和补丁环目标选择：

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, patchRing = tags.PatchRing, owner = tags.Owner
| summarize count() by patchRing

策略合规性汇总：

PolicyResources
| where type == "microsoft.policyinsights/policystates"
| summarize nonCompliant = countif(isCompliant == false) by resourceId

这些查询是 Update Management Center、Automanage 分配和仪表板中动态作用域的底层支持。在载入时标准化最小标签集（Environment、PatchRing、BusinessUnit、Owner），以确保 ARG 保持可操作性。

实际问题场景

Contoso Ltd. 在两个数据中心托管了 600 台本地 Windows Server 和 Linux 虚拟机，由 Configuration Manager 和 Ansible 进行管理。管理层要求实现标准化监控、在严格的周六维护窗口内进行每月修补、载入到 Sentinel，并为工程师提供安全的 SSH 访问，且不暴露公网 IP。他们还希望为审计员提供合规性证据，并最大限度地减少持续的管理工作。

准备最小权限访问

创建一个服务主体，其作用域限定于将包含 Arc 计算机的资源组 (RG)，并分配 Azure Connected Machine Onboarding 角色。这使得能够通过现有工具进行无人值守的载入，而无需授予宽泛的权限。原因：基于服务主体的载入方式具有可扩展性，并满足最小权限原则。

使用自动化载入计算机

在用于 Windows 的 Configuration Manager 和用于 Linux 的 Ansible 中，使用生成的 Arc 载入脚本和服务主体来安装 azcmagent，并将每台服务器注册到相应的资源组 (RG) 中（并使用 Environment 和 PatchRing 标签进行标记）。原因：重用现有的部署工具可实现快速、一致的推广，并嵌入标签以用于下游治理。

建立网络和代理出口

确保到 Entra ID、Azure Resource Manager、Arc 区域终结点、Windows Update/Microsoft Update 和发行版仓库的出站 443 端口通信畅通。配置 azcmagent 代理设置，并在需要时导入 TLS 检查的根 CA 证书。原因：保证代理和扩展的健康状况、更新的获取，并避免连接性漂移。

使用 Azure Policy 来宾配置强制执行基线

分配内置策略以部署 Guest Configuration 扩展、AMA 和 Dependency Agent。应用自定义的来宾配置包来强化 SSH 和 RDP 设置。为关键设置启用自动修复。原因：策略能大规模地表达期望状态，提供漂移检测，并修复偏差。

使用 Automanage 标准化操作

将 Automanage for Arc 的 Production 配置文件分配给生产环境的资源组 (RG)，将 Dev/Test 配置文件分配给非生产环境。审查任何为非 Azure 资源标记为手动的项目。原因：Automanage 以最少的操作员工作量持续应用最佳实践。

配置监控和 Sentinel 载入

创建数据收集规则 (DCR) 以收集 Windows SecurityEvent、Syslog 身份验证设施日志和性能计数器，并发送到连接至 Microsoft Sentinel 的中央 Log Analytics 工作区。使用 Azure Policy 将 DCR 与所有 Arc 计算机关联，并根据需要部署 Sentinel 解决方案包。原因：AMA + DCR 将数据收集与计算机本身解耦，而 Azure Policy 提供了在考试场景中得到验证的、工作量最小的载入方法。

使用 Update Management Center 编排修补

根据 PatchRing 标签定义每月重复的维护配置，包括一个 4 小时的周六窗口、需要时重启以及通知挂钩。使用基于标签的动态作用域，以便新计算机能被自动包含进来。原因：UMC 提供轻量级代理、标签驱动的补丁治理，并带有可审计的合规性报告。

在不使用公网 IP 的情况下启用安全的 SSH

通过 Policy 部署 AADSSHLoginForLinux，并通过 Privileged Identity Management 在目标资源组 (RG) 上为工程师授予 Azure Connected Machine User Login 角色。指导工程师使用 az ssh arc 命令并结合即时 (just-in-time) 激活。原因：Arc 隧道无需公共入口或跳转主机，而 Entra ID 加上 PIM 提供了最小权限、有时间限制的访问。