Microsoft AZ-140: 会话主机映像和预配 — 学习指南
属于 Microsoft Azure Virtual Desktop Specialty AZ-140 — 学习指南. 使用经过验证的答案练习: Microsoft 考试中心, 或参加限时模拟考试: ExamRoll.io.
概述
会话主机映像和预配是 Azure Virtual Desktop 可靠性、性能和安全状况的基础。治理良好的映像管道可以最大限度地减少偏差、加速推出并实现安全回滚,同时确保每个会话主机的配置完全相同,并正确加入到正确的身份边界。本节涵盖映像源选择、Windows Enterprise multi-session 选项、Azure Compute Gallery、通用化和生命周期、自动化工具、加入模型、代理注册、更新策略以及强化与验证。
映像源和操作系统选项
选择正确的基础映像和操作系统决定了可支持性、管理工作量和用户体验。
Azure Marketplace 映像与自定义映像
- Marketplace 映像提供由 Microsoft 维护的基线,例如 Windows 11 Enterprise multi-session 以及包含 Microsoft 365 Apps 的变体。它们可以缩短部署时间,确保安装了最新的补丁,并包含 Azure 所需的映像元数据。
- 当您必须预安装业务线应用、代理(FSLogix、Defender for Endpoint)、语言包或安全基线时,建议使用自定义映像。从 Marketplace 基础映像开始构建,进行自定义、通用化处理,然后发布到 Azure Compute Gallery 以进行版本化分发。
- 操作指南:为提高敏捷性,尽可能首选 Marketplace 映像。一旦出现可重复的自定义需求,再转向使用自定义映像;避免对单个虚拟机进行临时配置,以减少偏差。
Windows Enterprise multi-session 映像和支持的操作系统选项
- 对于池化主机池,Windows 11 Enterprise multi-session 是当前战略性的客户端操作系统;对于现有环境,Windows 10 Enterprise multi-session 仍然受支持。
- Windows 11 Enterprise 和 Windows 11 Enterprise multi-session 支持加入 Microsoft Entra ID。对于应用远程处理场景,或者需要仅限服务器的功能和热修补的场景,Windows Server (2019/2022) 仍然是有效选择,但它缺少客户端多会话版本所能提供的完整 M365 桌面体验。
- Marketplace 变体(例如,“Windows 11 Enterprise multi-session + Microsoft 365 Apps”)简化了正确的 M365 应用服务和共享计算机激活过程。
使用 Azure Compute Gallery 进行映像管理
Azure Compute Gallery(前身为 Shared Image Gallery)是大规模管理黄金映像的权威方法。
映像定义和版本
- 定义捕获了操作系统类型、发布者/产品/SKU 语义和“系列”属性。版本则代表了该定义的不可变的、带有时间戳的快照。
- 使用与变更范围(补丁、次要、主要)对齐的语义化版本控制(例如,1.0.0 → 1.1.0 → 1.2.0)。始终保留之前的生产版本以备回滚。
复制和区域放置
- 将映像版本复制到将要部署主机池的 Azure 区域,以最大限度地缩短预配时间并避免跨区域依赖。例如,在 South India 创建主机虚拟机之前,先将 Image1 从 East US 复制到 South India。
- 在映像版本级别更新复制设置,以便在不重新构建映像的情况下添加或删除区域。
排除项和“latest”别名
- 库为每个定义提供了一个“latest”别名,模板可以将其作为目标。要将部署固定到特定版本或暂缓使用某个候选版本,请在新版本上设置 ExcludeFromLatest。
- 示例:要在 1.2.0 仍在验证期间将 1.1.0 设为默认版本,请将 1.2.0 标记为从 latest 中排除,这样新虚拟机默认会从 1.1.0 进行预配。
治理和访问
- 将会话库的读取者角色分配给部署身份;使用 RBAC 和资源锁来保护生产版本。利用 Azure Policy 来限制可用于会话主机的映像。
预配、通用化和自动化
规范的映像生命周期和自动化可以防止配置偏差,并确保各个主机拥有唯一的身份。
- Sysprep、通用化和唯一身份
- 在捕获 Windows 映像之前,请删除特定于计算机的数据,以便新主机获得独特的名称、SID 和身份。在提升的命令提示符下运行:
sysprep /oobe /generalize /shutdown /mode:vm
```
- 验证 Windows 是否已更新,所有每用户机密是否已清除,以及事件日志是否已轮转。不要将要捕获的映像加入域。
- Azure Image Builder 和可重复的自定义
- Azure Image Builder 使用声明性管道来编排映像创建过程,该管道可以添加软件、应用基线、注入语言包、运行 Windows 更新,并发布到 Azure Compute Gallery。
- 强制实现可重复性:将 AIB 模板存储在版本控制中,驱动参数化构建,并通过开发 → 验证 → 生产库或区域来提升映像。
- Azure Resource Manager 模板、Bicep 和部署自动化
- 将主机池、应用程序组、工作区、虚拟机规模集和会话主机虚拟机定义为代码。参数化映像引用(库/定义/版本)、网络、大小和身份。
- 在需要加入 AD DS 域的情况下,使用 Key Vault 引用来处理机密。对于大规模部署,请预先验证区域 vCPU 配额,以避免预配失败。
- 示例:在虚拟机预配期间使用注册令牌安装 AVD 代理的 Bicep 代码片段
@secure() param avdRegistrationToken string
resource avdAgent ‘Microsoft.Compute/virtualMachines/extensions@2023-09-01’ = { name: ‘${vmName}/Microsoft.DesktopVirtualization-AVDAgent’ location: location properties: { publisher: ‘Microsoft.DesktopVirtualization’ type: ‘rdagent’ typeHandlerVersion: ‘1.0’ autoUpgradeMinorVersion: true settings: { registrationInfoToken: avdRegistrationToken } } }
### 加入选项、注册以及网络/DNS 注意事项
身份加入和代理注册必须与名称解析和路由一并规划。
- 会话主机部署期间的域加入和 Microsoft Entra 加入
- AD DS 加入:支持 Windows 10/11 企业版多会话和 Windows Server。在您的部署工作流中使用 “JSONADDomainExtension” 或原生 domainJoin 属性。将加入权限委派给具有受限 OU 范围的服务帐户。
- Microsoft Entra ID 加入:支持 Windows 11 企业版和 Windows 11 企业版多会话。这消除了对域控制器的依赖,并可以通过仅限云的身份和条件访问来简化设备生命周期。在启用前,请确保满足 AVD 客户端和管理的先决条件。
- Azure AD DS 加入:使用托管域时,请先将 VNet DNS 服务器配置为 Azure AD DS 的 IP 地址;否则,部署和加入将会失败,因为会话主机无法解析托管域。
- DNS 和连接性要求
- 确保 VNet DNS 指向能够解析目标域和 Azure 服务记录的解析器。对于混合 AD DS,请使用可通过对等互连或 VPN 访问的域控制器 IP;配置多个 DNS 服务器以保持弹性。
- 对于跨 VNet 部署,请更新子 VNet 的 DNS 设置;不要依赖默认的 Azure DNS 进行 AD DS 加入。
- 会话主机代理的引导和注册令牌的使用
- AVD 代理对(Remote Desktop Agent Loader 和 side-by-side stack)使用一个有时限的注册令牌将 VM 注册到主机池。在主机池级别生成令牌,并在构建时或通过 VM 扩展注入它。
- 将现有 VM 载入主机池时,请在安装代理之前生成一个新的注册密钥,以便 VM 可以向代理(broker)注册。
### 更新、安全加固与验证
将会话主机视为不可变的;通过新镜像横向扩展新主机,排空并淘汰旧主机。
- 更新策略:镜像更新、hotpatching 和回滚计划
- 镜像更新:为每月的质量和功能更新制作新的库版本,进行验证,然后横向扩展。在解除分配和移除旧主机之前,使用“排空模式”来迁出用户。
- Hotpatching:仅适用于 Windows Server Azure Edition;它能减少修补过程中的重启次数。Windows 10/11 Enterprise multi-session 不支持 hotpatching——应在镜像管道中使用常规的累积更新,并根据需要应用紧急的带外补丁。
- 回滚:在所有区域中至少保留一个先前生产镜像版本的副本。如果检测到问题,则从先前的版本预配新主机并重新分配容量。使用库的 ExcludeFromLatest 属性来阻止有问题的构建版本。
- 镜像安全加固
- 基线:在镜像管道中应用适用于 Windows 10/11 的 Microsoft 安全基线或等效的 CIS 加固。使用 Defender for Cloud 和漏洞评估进行验证。
- 身份和访问:尽可能移除本地管理员,为所有本地管理员账户启用 Windows LAPS,并对 AVD 登录强制执行 MFA/Conditional Access。
- 磁盘和数据保护:使用平台管理的密钥或客户管理的密钥进行磁盘加密集。将 FSLogix 配置文件存储在弹性存储上;对于用户数量非常大且有低延迟要求的场景,Azure NetApp Files 提供最高的 IOPS 和最低延迟的配置文件存储。
- 应用程序控制和攻击面减少:在可行的情况下启用 Windows Defender Application Control,配置 ASR 规则,并部署 Microsoft Defender for Endpoint。
- 策略和漂移控制:使用 Azure Policy 限制允许的 VM 镜像和扩展;审计偏差并阻止流程外的变更。
- 在验证主机池中进行测试
- 维护一个小的、独立的验证主机池。将其设置为验证环境,以接收 AVD 代理的预发布更新,并在推广到生产环境之前验证新的镜像版本、FSLogix 变更和 GPO。
- 测量会话内的用户体验。例如,要快速判断可感知的显示问题,可以在性能监视器中检查 RemoteFX Graphics Frames Skipped/Second 计数器,以隔离客户端、网络或服务器瓶颈。
#### 实际问题场景
Siemens 需要在西欧和南印度地区标准化 Azure Virtual Desktop,使用 Windows 11 Enterprise multi-session 主机。他们要求可重复的镜像自定义、快速部署、安全回滚,并能支持 Microsoft 365 Apps 和一个业务线 (LOB) 加载项。在欧洲中心 VNet 中存在一个托管的 Azure AD DS 域,Siemens 计划在这两个区域部署池化主机池。
1) 准备名称解析和加入域的前提条件
- 操作:将两个 VNet 上的 DNS 服务器设置为 Azure AD DS 的 IP,并确保 VNet 对等互连允许转发的 DNS 流量。
- 原因:会话主机必须能够解析托管域才能加入 AD DS。首先更新 VNet DNS 可以防止加入域时发生故障,并确保 Kerberos 和 LDAP 解析正常工作。
2) 使用 Azure Image Builder 构建黄金镜像
- 操作:从 Marketplace 的 “Windows 11 Enterprise multi-session + Microsoft 365 Apps” 镜像开始。使用 Azure Image Builder 添加 FSLogix、Defender for Endpoint、语言包和安全基线;然后运行 Windows Update 和 sysprep 通用化。
- 原因:AIB 保证了一个可重复、可审计的管道,最大限度地减少了漂移并生成一个密封的镜像,确保每个主机都完全相同且合规。
3) 通过 Azure Compute Gallery 发布和复制
- 操作:将捕获的镜像作为版本 1.0.0 发布到 Azure Compute Gallery,并复制到西欧和南印度。将 1.0.0 标记为最新版本;在准备 1.1.0 时,将其设置为 ExcludeFromLatest,直到验证完成。
- 原因:Gallery 复制将镜像放置在靠近主机创建位置的地方,以加快预配速度,并通过“最新”和“排除”标志提供受控的推广。
4) 使用 Bicep 自动化主机池和 VM 预配
- 操作:将主机池、应用程序组和伸缩计划部署为代码。使用参数化的 Bicep 模板从 Gallery 版本创建会话主机,该模板会使用新生成的注册令牌安装 AVD 代理,并通过域扩展执行 AD DS 域加入操作。
- 原因:基础设施即代码确保了跨区域的一致性,使部署具有幂等性,并以最少的手动步骤简化了到代理的注册过程。
5) 在专用的验证主机池中进行验证
- 操作:在西欧建立一个小型验证主机池,启用验证环境,并将一个试点用户组引导至此。测量登录性能、FSLogix 行为和图形计数器;解决发现的问题,然后在 1.1.0 上移除 ExcludeFromLatest 标志。
- 原因:及早发现回归问题可以防止对广大用户造成影响,并使 Siemens 能够只推广经过验证的镜像。
6) 执行具有回滚安全性的生产部署
- 操作:在两个区域从 1.1.0 版本横向扩展新主机。将旧主机置于排空模式,在会话结束后解除分配并移除它们。将 1.0.0 版本保留两个发布周期。
- 原因:蓝绿部署式的替换避免了原地漂移,并能在出现问题时通过从前一个镜像版本进行预配来实现即时回滚。
7) 持续进行加固和治理
- 操作:应用 Azure Policy 来限制允许的镜像和必需的扩展,启用 Defender for Cloud 的建议,并将 FSLogix 配置文件存储在 Azure NetApp Files 上以获得可预测的高性能。
- 原因:持续的治理和高性能的配置文件存储可以在保持安全态势的同时,维持大规模下的用户体验。
---
← [网络、连接和传输](/cn/posts/az-140-networking/) · [所有领域](/cn/posts/az-140-study-guide/) · [FSLogix、配置文件和用户数据](/cn/posts/az-140-fslogix-profiles/) →
**[练习这些题目 →](/cn/kb/microsoft/)** · **[在 ExamRoll.io 上限时练习 →](https://www.examroll.io/?utm_source=guide&utm_medium=referral&utm_campaign=az-140)**
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →