Microsoft AZ-140: FSLogix、配置文件和用户数据 — 学习指南

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

属于 Microsoft Azure Virtual Desktop Specialty AZ-140 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

FSLogix 为 Azure Virtual Desktop 提供基于容器的用户配置文件，在用户登录期间通过 SMB 将其配置文件附加为虚拟磁盘。这种设计消除了传统漫游配置文件的弊端，加快了登录速度，并稳定了非持久性会话主机上的应用状态。FSLogix 将配置文件状态 (Profile Container) 与 Microsoft 365 数据及缓存 (Office Data File Container) 分离，并可通过 Cloud Cache 增加弹性层。正确的存储选择、基于身份的 SMB 权限以及配置文件大小治理对于实现低延迟登录和高会话密度至关重要。

FSLogix 容器与数据架构

FSLogix Profile Container 将整个用户配置文件存储在位于 SMB 存储上的单个虚拟磁盘文件中。登录时，该磁盘会挂载到 C:\Users\username，操作系统会将其视为原生配置文件。

• 磁盘格式：除非需要与非常旧的操作系统兼容，否则请使用 VHDX。VHDX 对损坏的抵御能力更强，支持更大的容量，更不容易出现元数据问题，并且是 FSLogix 的默认格式。仅在特定应用程序或旧版驱动程序需要时才使用 VHD。
• 大小调整：默认情况下，容器是动态扩展的。设置一个最大容量（例如，配置文件 30 GB，Office 10 GB），并允许动态增长。固定大小的磁盘很少能提升性能，反而会增加存储消耗和管理开销。
• 锁定与并发：配置文件容器会被第一个会话主机以读/写模式锁定。同一用户在不同主机上的第二个并发会话将根据策略被阻止或被允许只读访问。这可以保护配置文件的完整性。

Office Data File Container (ODFC) 将高频变动的 Microsoft 365 数据（如 Outlook OST/Dat 文件、OneDrive 和 Teams 缓存）分离到其自己的容器中。其优点包括：

• 登录速度更快，因为 Office 缓存不再使 Profile Container 膨胀。
• 可以独立清理 Office 缓存或为其重新建立基线，而不会影响用户配置文件。
• 降低了 Office 缓存损坏影响配置文件的风险。

使用 redirections.xml 将易失性文件夹从 Profile Container 中排除，以减小其增长并加快登录速度。常见的排除项包括 Teams 缓存、浏览器缓存、Temp 文件夹和日志。使用 ODFC 时，应从 Profile Container 中排除 Office 特定的缓存以避免数据重复。

redirections.xml 示例（放置在 frxtray.exe 旁边或通过注册表定义）：

<?xml version="1.0" encoding="UTF-8"?>
<FrxProfileFolderRedirection ExcludeCommonFolders="0">
  <Exclude>
    <Path>%LOCALAPPDATA%\Microsoft\Teams\Cache</Path>
    <Path>%LOCALAPPDATA%\Microsoft\Teams\Service Worker</Path>
    <Path>%LOCALAPPDATA%\Temp</Path>
    <Path>%LOCALAPPDATA%\Packages\Microsoft.MicrosoftEdge_*\AC\#!001\Cache</Path>
    <Path>%APPDATA%\Microsoft\Teams\media-stack</Path>
  </Exclude>
</FrxProfileFolderRedirection>

存储平台与访问控制

为 FSLogix 选择 SMB 存储是一项关乎性能和运维的决策：

• Azure NetApp Files (ANF)：提供最高的 IOPS 和最低的延迟；是超大规模和对延迟敏感的部署（例如，数万用户）的理想选择。它提供 SMB 卷，具有可预测的微秒到毫秒级的低延迟，每个卷的吞吐量与容量池绑定，并支持快照和跨区域复制。当您必须最大化桌面体验并处理极端并发时，应使用此服务。
• Azure Files Premium (FileStorage)：由 SSD 支持，在许多区域提供区域冗余，管理工作量极小，对于广泛的企业用途而言具有成本效益。共享性能随预配的大小扩展；随着容量增加，每个共享可提供高达 100,000 IOPS 和数 GB/s 的吞吐量。当您需要 SSD 性能但又不想承担 ANF 的管理开销时，推荐大多数主机池使用此服务。
• Azure Files Standard：由 HDD 支持；适用于小型实验室或轻量级使用场景。由于其较高的延迟和不稳定的性能，不推荐用于生产环境的 FSLogix 配置文件。

UNC 路径和 DNS：

• Azure Files 使用路径格式 \storageaccount.file.core.windows.net\sharename。请确保会话主机能够解析并访问此终结点。建议使用专用终结点来控制流量。
• ANF 通过委托子网中的私有 IP 使用类似 \anf-vol-name\share 的 SMB 卷路径。

基于身份的 SMB 身份验证和权限取决于目录服务以及会话主机的加入状态：

• Active Directory Domain Services (AD DS) 或 Azure AD DS：会话主机已加入域；使用 Kerberos。使用您的 AD 组配置共享权限和 NTFS ACL。
• Microsoft Entra ID Kerberos for Azure Files：允许已加入 Entra ID 的会话主机在没有 AD DS 的情况下访问 SMB。在存储帐户上分配 Azure RBAC，并确保客户端操作系统和 FSLogix 版本支持此模式。

在常见场景中为 Azure Files 配置的最小权限（最小权限原则）：

• 当使用 Entra ID 身份验证时，在存储帐户或共享范围向用户组授予 Storage File Data SMB Share Contributor (Azure RBAC) 角色。
• 在共享根目录上配置 NTFS：用户（或专用的 AVD 用户组）拥有“修改”权限；创建者所有者对子文件夹拥有“完全控制”权限；管理员拥有“完全控制”权限；移除授予过多访问权限的继承权限。
• 对于通过 AD DS 身份验证的 Azure Files，还需设置共享级别的 ACL，以允许用户拥有“修改”权限。

弹性、Cloud Cache 和运维健康状况

Cloud Cache 将数据写入会话主机上的本地缓存，并将其复制到一个或多个远程 SMB 存储库。其优点包括在临时性存储中断期间能够持续运行以及跨区域弹性。设计注意事项：

• 使用两到四个 CCD 位置以平衡弹性与登录延迟。位置越多，在发生故障时附加超时时间就越长。
• 确保本地缓存磁盘空间充足（在最坏情况下，主机上每个并发活动用户通常需要 20–40 GB）。
• 混合使用目标（例如，区域内的主 Azure Files Premium 和配对区域中的辅助 Azure Files 或 ANF）。除非绝对必要，否则不要为 Cloud Cache 使用由 HDD 支持的慢速目标。

针对包含 Cloud Cache 和 ODFC 的配置文件容器的示例配置（注册表）：

reg add HKLM\SOFTWARE\FSLogix\Profiles /v Enabled /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v VolumeType /t REG_SZ /d VHDX /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v SizeInMBs /t REG_DWORD /d 30720 /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v IsDynamic /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v CCDLocations /t REG_MULTI_SZ /d "\\store1.file.core.windows.net\profiles\0!\\store2.file.core.windows.net\profiles\0" /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\ODFC /v Enabled /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\ODFC /v VolumeType /t REG_SZ /d VHDX /f
reg add HKLM\SOFTWARE\FSLogix\ODFC /v SizeInMBs /t REG_DWORD /d 10240 /f

诊断登录失败和配置文件锁定：

• 事件查看器：应用程序和服务日志 > FSLogix > Apps 提供附加、IO 和 Cloud Cache 诊断信息。查找访问被拒绝 (0x5)、共享冲突 (0x20) 或超时等问题。
• 过期锁：如果崩溃的会话主机遗留了打开的句柄，VHDX 文件可能会显示为正在使用。请验证没有活动会话，从 SMB 服务器端关闭打开的文件，并允许 FSLogix 重试。除非您已完全确认没有活动的挂载，否则请避免手动删除锁文件。
• 回退行为：使用 PreventLoginWithFailure 来控制在附加失败时用户是否可以使用临时本地配置文件登录。当存储性能下降但您仍希望允许访问时，可以考虑使用“只读尝试”(Try for read-only)；但请注意，所做的更改不会被持久化。

清理和维护：

• 启用 DeleteLocalProfileWhenVHDShouldApply 以删除过期的本地配置文件。
• 如果 VHDX 文件因临时数据而增大，请定期离线压缩它们。
• 对于 Cloud Cache，如果主机已停用，请安排清理废弃的本地缓存。

性能、规模和会话密度

存储的 IOPS 和延迟直接决定了登录时间、应用程序响应能力以及每个主机可以承载的并发会话数量：

• 延迟目标：在登录风暴期间，低于 2 毫秒到个位数毫秒的存储延迟可提供最佳体验。ANF 通常能实现最低的延迟。当通过私有终结点访问时，Azure Files Premium 的延迟通常为低个位数毫秒。
• IOPS 特性：FSLogix 在登录期间表现出显著的突发 IOPS（每用户数十到数百），以及适度的稳态 IOPS（通常每用户 3–15，具体取决于工作负载）。将此值乘以并发登录数来规划存储大小。
• Azure Files Premium 扩展：增加预配的共享大小以提高 IOPS 和吞吐量上限；在支持的操作系统上启用 SMB Multichannel 以提高每个主机的吞吐量。
• ANF 容量和分层：根据每预配 TiB 的 MiB/s 选择 ANF 性能层；Premium 和 Ultra 层通常用于重度 Office 和 CAD 用户。对于非常大的部署，使用多个卷来并行化 I/O。

网络路径至关重要。使用私有终结点并确保会话主机与存储位于同一区域，以避免 WAN 延迟。将主机和存储放置在同一虚拟网络或具有低延迟路径的对等网络中。

管理 Microsoft 365 数据和配置文件增长

结合使用 ODFC、OneDrive Files On-Demand 和 Known Folder Move (KFM) 来控制增长：

• ODFC：在一个单独的容器中漫游 Outlook OST、OneNote 缓存和 Office Wef 数据。这可以减少 Profile Container 中的变动并加快登录速度。
• 带有 Files On-Demand 的按计算机安装的 OneDrive：将 OneDrive 安装在 Program Files 目录中，以便所有用户共享二进制文件；Files On-Demand 在配置文件中保留占位符，并在访问时填充内容，从而限制容器的增长。
• KFM：将桌面、文档和图片重定向到 OneDrive，在任何设备上都提供相同的用户体验。借助 Files On-Demand，只有被访问的文件才会在本地填充，从而进一步减少了增长。
• 排除项：如果您想积极地最小化容器大小，可以通过 redirections.xml 排除 OneDrive 的同步缓存；这将在每次登录后按需重新填充。这种方法可以节省空间，但可能会增加大文件的首次打开延迟。在大多数情况下，仅使用 Files On-Demand 就足够了，无需排除 OneDrive。
• Microsoft Teams 优化：使用为 AVD 优化的 Teams，并使用 redirections.xml 排除临时的 Teams 缓存，以避免重复的大量 I/O 操作。

安全、备份与恢复

• 传输中加密：SMB 3.1.1 加密和签名可保护传输中的数据。在支持的情况下强制执行加密。
• 静态加密：Azure Files 和 ANF 默认对静态数据进行加密。为获得更高的保障，请对 Azure Files 使用客户管理的密钥；ANF 在特定区域支持双重加密和卷级密钥。
• 访问控制：最小化权限。对于使用 Entra ID Kerberos 的 Azure Files，授予用户 Storage File Data SMB Share Contributor 角色，并将 NTFS 权限限制为“修改”。对于基于 AD DS 的访问，将共享和 NTFS ACL 设置为最小权限。为读/写用户和管理员使用不同的组。
• 网络隔离：使用 private endpoints 或 ANF delegated subnets。将存储防火墙的访问限制在受信任的子网内。
• 备份和快照：
  • Azure Files：使用 Azure Backup for Azure Files；配置每日快照，并设置满足 RPO/RTO 的保留策略。启用软删除以防止意外删除。
  • ANF：使用快照策略，并在需要时使用跨区域复制进行灾难恢复 (DR)。测试将快照挂载为只读共享，以快速恢复单个配置文件。
• 恢复：首选的恢复方式是项目级恢复（恢复单个用户的 VHDX）到隔离路径，验证其完整性，然后交换指针。维护一份处理配置文件损坏的操作手册，其中应包括快速分离、快照恢复和用户沟通等步骤。

实际问题场景

Siemens AG 需要为 12,000 名使用 Windows 11 Enterprise 多会话版以及 Microsoft 365 Apps、Teams 和 OneDrive 的工程师改善 Azure Virtual Desktop 的登录时间。目前，他们的配置文件存储在一个过载的标准文件共享上，导致在早晨登录风暴期间出现高延迟和频繁的配置文件锁定事件。

1. 将配置文件存储迁移到与主机池相同区域的 Azure NetApp Files Premium SMB 卷。

• 原因：ANF 提供数千个并发登录所需的最低延迟和可预测的高 IOPS。将存储和主机部署在同一位置可以最大限度地减少往返时间。

2. 使用 FSLogix ODFC 分离 Office 缓存，将 Profile Container 的最大大小减少到 20 GB，同时将 ODFC 设置为 10 GB，两者均使用动态 VHDX。

• 原因：隔离易变的 Microsoft 365 数据可以减少配置文件的频繁变动并加快容器附加速度。动态 VHDX 在节省容量的同时，允许在需要时进行突发性增长。

3. 实施 Cloud Cache，设置两个 CCD 位置：主位置为 ANF 卷，次位置为通过 private endpoints 连接的配对区域中的 Azure Files Premium 共享。

• 原因：Cloud Cache 可在维护或瞬时存储事件期间确保持续性。次要区域无需手动故障切换即可提高恢复能力。

4. 通过 Azure RBAC 和 NTFS 强制实施最小权限访问：在 Azure Files 次要共享上为工程师 AVD 组分配 Storage File Data SMB Share Contributor 角色，并在两个存储库上授予“修改” (Modify) NTFS 权限；管理员获得“完全控制” (Full Control) 权限。强制执行 SMB 加密。

• 原因：正确的共享和 NTFS 权限使 FSLogix 能够安全地创建和写入 VHDX 文件，同时防止权限过高访问。加密可保护传输中的数据。

5. 部署按计算机安装的 OneDrive，启用 Files On-Demand 和针对桌面、文档和图片的 Known Folder Move。将 OneDrive 保留在容器内，但通过 redirections.xml 排除临时的 Teams 缓存。

• 原因：KFM 规范了用户数据的存放位置，而 Files On-Demand 可防止批量文件同步，从而控制配置文件增长。排除 Teams 缓存可以在不影响用户文件的情况下减少重复的 I/O 操作。

6. 调优 FSLogix 并进行监控：启用 DeleteLocalProfileWhenVHDShouldApply，设置 PreventLoginWithFailure 以仅允许 Tier-0 紧急访问帐户使用临时本地配置文件，并检测登录遥测数据。

• 原因：自动清理可消除过时的本地配置文件，而受控的回退机制可防止静默的数据分歧。监控可验证登录时间是否缩短并检测异常情况。

7. 保护和恢复：配置 ANF 快照策略，设置每小时的短期保留和每日的长期保留；在关键卷上启用跨区域复制；为 Azure Files 次要共享启用 Azure Backup。每月测试恢复单个用户的 VHDX。

• 原因：快照为单个配置文件提供快速的时间点恢复；复制和备份为抵御区域性或操作性故障提供了分层保护，并确保了可预测的 RPO/RTO。

← 会话主机映像和预配 · 所有领域 · 会话主机运维、缩放和优化 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →