Azure 虚拟桌面中的应用附加和 MSIX 应用附加
Azure 虚拟桌面中有两项功能可让你将应用程序包中的应用程序动态附加到 Azure 虚拟桌面中的用户会话 - 应用附加和 MSIX 应用附加。 使用应用附加和 MSIX 应用附加时，应用程序不会本地安装在会话主机或映像上，因此可以更轻松地为会话主机创建自定义映像，并降低组织的运营开销和成本。 应用程序在容器中运行，这些容器将用户数据、操作系统和其他应用程序分开，从而提高安全性，使它们更易于故障排除。
下表比较了 MSIX 应用附加与应用附加：
| MSIX 应用附加 | 应用附加 |
|---|---|
| 应用程序使用 RemoteApp 交付或作为桌面会话的一部分交付。 权限通过分配给应用程序组进行控制，但所有桌面用户都会在桌面应用程序组中看到所有 MSIX 应用附加应用程序。 | 应用程序使用 RemoteApp 交付或作为桌面会话的一部分交付。 权限按每个用户的每个应用程序应用，让你更好地控制用户可在远程会话中访问的应用程序。 桌面用户只能看到分配给他们的应用附加应用程序。 |
| 应用程序只能在一个主机池上运行。 如果你希望它在另一个主机池上运行，则必须创建另一个包。 | 同一个应用程序包可以跨多个主机池使用。 |
| 应用程序只能在添加了它们的主机池上运行。 | 应用程序可以在与应用程序包位于同一 Azure 区域中运行 Windows 客户端操作系统的任何会话主机上运行。 |
| 若要更新应用程序，必须删除它然后使用另一版本的包重新创建应用程序。 应在维护时段更新应用程序。 | 应用程序可以通过新的磁盘映像升级到新的应用程序版本，而无需维护时段。 |
| 用户不能在同一会话主机上运行同一应用程序的两个版本。 | 用户可以在同一会话主机上并发运行同一应用程序的两个版本。 |
| 现在可通过 Azure Log Analytics 获取使用情况和运行状况的遥测数据。 | 可以通过 Azure Log Analytics 获取使用情况和运行状况的遥测数据。 |
可以使用以下应用程序包类型和文件格式：
| 包类型 | 文件格式 | 功能可用性 |
|---|---|---|
| MSIX 和 MSIX 捆绑包 | .msix.msixbundle |
MSIX 应用附加 应用附加 |
| Appx 和 Appx 捆绑包 | .appx.appxbundle |
仅应用附加 |
MSIX 和 Appx 是 Windows 应用程序包格式，可为 Windows 应用程序提供新式打包体验。 应用程序在容器中运行，这些容器将用户数据、操作系统和其他应用程序分开，从而提高安全性，使它们更易于故障排除。 MSIX 和 Appx 相似，主要区别在于 MSIX 是 Appx 的超集。 MSIX 支持 Appx 的所有功能，另外还具备使它更适合企业使用的其他功能。
提示
选择本文顶部的按钮，在应用附加和 MSIX 应用附加之间进行选择，以查看相关文档。
可以从软件供应商处获取 MSIX 包，也可以通过现有安装程序创建 MSIX 包。 若要了解有关 MSIX 的详细信息，请参阅什么是 MSIX？
用户如何获取应用程序
可以将不同的应用程序分配给同一主机池或同一会话主机上的不同用户。 在登录期间，必须满足以下三项要求，用户才能在正确的时间获取正确的应用程序：
必须将应用程序分配给主机池。 将应用程序分配到主机池使你可以选择让应用程序在哪些主机池上可用，以确保合适的硬件资源可供应用程序使用。 例如，如果应用程序是图形密集型应用程序，则你可以确保它仅在具有 GPU 优化会话主机的主机池上运行。
用户必须能够登录到主机池中的会话主机，因此它们必须位于桌面或 RemoteApp 应用程序组中。 对于 RemoteApp 应用程序组，必须将应用附加应用程序添加到应用程序组，但无需将应用程序添加到桌面应用程序组。
必须将应用程序分配给用户。 可以使用组或用户帐户。
如果满足了所有这些要求，则用户会获取应用程序。 此过程控制着谁获取哪个主机池上的应用程序，以及如何让单个主机池中的用户甚至登录到同一个多会话会话主机的用户获取不同的应用程序组合。 不符合要求的用户不会获取应用程序。
用户如何获取应用程序
可以将不同的应用程序分配给同一主机池中的不同用户。 使用 MSIX 应用附加时，可将 MSIX 包添加到主机池，并使用桌面或 RemoteApp 应用程序组控制应用程序的分配。 在登录期间，必须满足以下要求，用户才能在正确的时间获取正确的应用程序：
用户必须能够登录到主机池中的会话主机，因此它们必须位于桌面或 RemoteApp 应用程序组中。
必须将 MSIX 映像添加到主机池。
如果满足了这些要求，则用户将获取应用程序。 使用桌面应用程序组分配应用程序时，会将它们添加到用户的开始菜单。 不符合要求的用户不会获取应用程序。
应用程序映像
在将应用程序包与 Azure 虚拟桌面配合使用之前，需要使用 MSIXMGR 工具通过现有的应用程序包创建 MSIX 映像。 然后，需要在会话主机可访问的文件共享上存储每个磁盘映像。 有关文件共享的要求的更多信息，请参阅文件共享。
磁盘映像类型
可以将复合映像文件系统 (CimFS)、VHDX 或 VHD 用于磁盘映像，但不建议使用 VHD。 装载和卸载 CimFS 映像的速度比 VHD 和 VHDX 文件更快，并且占用的 CPU 和内存也更少。 建议只在会话主机正在运行 Windows 11 时对应用程序映像使用 CimFS。
CimFS 映像是多个文件的组合：一个文件具有 .cim 文件扩展名，并且包含元数据，以及至少两个其他文件，一个以 objectid_ 开头，另一个以 region_ 开头并包含实际的应用程序数据。 .cim 文件附带的文件没有文件扩展名。 下表是可在 CimFS 映像中找到的示例文件列表：
| 文件名 | 大小 |
|---|---|
MyApp.cim |
1 KB |
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 |
27 KB |
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 |
20 KB |
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 |
42 KB |
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 |
428 KB |
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 |
217 KB |
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 |
264,132 KB |
下表是 VHDX 和 CimFS 之间的性能比较。 这些数字是测试运行的结果，每个格式 500 个 300 MB 的文件，该测试是在 DSv4 Azure 虚拟机上执行的。
| 指标 | VHD | CimFS |
|---|---|---|
| 平均装入时间 | 356 毫秒 | 255 毫秒 |
| 平均卸载时间 | 1615 毫秒 | 36 毫秒 |
| 内存占用率 | 6%（共 8 GB） | 2%（共 8 GB） |
| CPU（计算高峰） | 多次达到最大值 | 无影响 |
应用程序注册
应用附加会在登录期间将包含你的应用程序的磁盘映像从文件共享装载到用户的会话，然后注册过程会使应用程序可供用户使用。 有两种注册类型：
MSIX 应用附加会在登录期间将包含你的应用程序的磁盘映像从文件共享装载到用户的会话，然后注册过程会使应用程序可供用户使用。 有两种注册类型：
按需：应用程序仅在登录时部分注册，应用程序的完整注册将推迟到用户启动应用程序时。 按需是我们建议使用的注册类型，因为它不会影响登录到 Azure 虚拟桌面所需的时间。 按需是默认注册方法。
登录阻止：分配给用户的每个应用程序都已完全注册。 当用户登录到其会话时进行注册，这可能会影响 Azure 虚拟桌面的登录时间。
重要
所有 MSIX 和 Appx 应用程序包都包含证书。 你负责确保证书在环境中受信任。 相应的信任链支持自签名证书。
应用附加不会限制用户可以使用的应用程序数。 应考虑可用的网络吞吐量以及你的文件共享支持的每个文件（每个映像）的打开句柄数，因为它可能会限制你可以支持的用户数或应用程序数。 有关详细信息，请参阅文件共享。
重要
所有 MSIX 应用程序包都包含一个证书。 你负责确保证书在环境中受信任。 支持自签名证书。
MSIX 应用附加不会限制用户可以使用的应用程序数。 应考虑可用的网络吞吐量以及你的文件共享支持的每个文件（每个映像）的打开句柄数，因为它可能会限制你可以支持的用户数或应用程序数。 有关详细信息，请参阅文件共享。
应用程序状态
MSIX 和 Appx 包设置为活动或非活动。 设置为活动的包使应用程序可供用户使用。 设置为非活动的包会被 Azure 虚拟桌面忽略，在用户登录时不会添加。
MSIX 包设置为活动或非活动。 设置为活动的 MSIX 包使应用程序可供用户使用。 设置为非活动的 MSIX 包会被 Azure 虚拟桌面忽略，在用户登录时不会添加。
应用程序的新版本
可以通过提供包含更新的应用程序的新映像来添加应用程序的新版本。 可以通过两种方式使用此新映像：
并排：使用新的磁盘映像创建新的应用程序，并将其分配给与现有应用程序相同的主机池和用户。
就地：在应用程序版本号更改时创建新映像，然后更新现有应用程序以使用新映像。 版本号可以更高或更低，但不能使用相同的版本号更新应用程序。 在所有用户都结束使用现有映像之前，请勿删除它。
更新后，用户将在下次登录时获取更新后的应用程序版本。 用户无需停止使用以前的版本来添加新版本。
应用程序的新版本
使用 MSIX 应用附加时，需要删除应用程序包，然后使用新的磁盘映像创建新的应用程序，并将其分配给同一主机池。 无法像应用附加那样就地更新。 下次登录时，用户将获取带有更新后的应用程序的新映像。 应在维护时段内执行这些任务。
标识提供者
下面是可用于应用附加的标识提供者：
| 标识提供者 | 状态 |
|---|---|
| Microsoft Entra ID | 支持 |
| Active Directory 域服务 (AD DS) | 支持 |
| Microsoft Entra 域服务 | 不支持 |
下面是可用于 MSIX 应用附加的标识提供者：
| 标识提供者 | 状态 |
|---|---|
| Microsoft Entra ID | 不支持 |
| Active Directory 域服务 (AD DS) | 支持 |
| Microsoft Entra 域服务 (Azure AD DS) | 不支持 |
文件共享
应用附加要求你的应用程序映像存储在 SMB 文件共享上，它之后会在登录期间在每个会话主机上装载。 应用附加不依赖于文件共享使用的存储构造的类型。 建议使用 Azure 文件存储，因为它与 Microsoft Entra ID 或 Active Directory 域服务兼容，并在成本和管理开销之间提供了极佳的价值。
MSIX 应用附加要求你的应用程序映像存储在 SMB 版本 3 文件共享上，它之后会在登录期间在每个会话主机上装载。 MSIX 应用附加不依赖于文件共享使用的存储结构类型。 建议使用 Azure 文件存储，因为它与可用于 MSIX 应用附加的受支持的标识提供者兼容，并在成本和管理开销之间提供了极佳的价值。
以下部分提供有关文件共享所需的权限、性能和可用性方面的一些指导。
权限
每个会话主机会从文件共享装载应用程序映像。 需要配置 NTFS 和共享权限，以允许每个会话主机计算机对象对文件和文件共享具有读取访问权限。 配置正确的权限的方式取决于用于文件共享和会话主机的存储提供程序和标识提供者。
若要在会话主机加入 Microsoft Entra ID 时使用 Azure 文件存储，需要将读者和数据访问 Azure 基于角色的访问控制 (RBAC) 角色分配给 Azure 虚拟桌面和 Azure 虚拟桌面 ARM 提供程序服务主体。 此 RBAC 角色分配允许会话主机使用访问密钥访问存储帐户。 存储帐户必须与会话主机位于同一 Azure 订阅中。 若要了解如何将 Azure RBAC 角色分配给 Azure 虚拟桌面服务主体，请参阅将 RBAC 角色分配给 Azure 虚拟桌面服务主体。
有关将 Azure 文件存储与已加入 Microsoft Entra ID、Active Directory 域服务或 Microsoft Entra 域服务的会话主机配合使用的详细信息，请参阅用于 SMB 访问的 Azure 文件存储基于标识的身份验证选项概述。
警告
将 Azure 虚拟桌面 ARM 提供程序服务主体分配到存储帐户时，会向 Azure 虚拟桌面服务授予存储帐户中所有数据的权限。 建议仅在此存储帐户中存储应用以用于应用附加，并定期轮换访问密钥。
对于具有 Active Directory 域服务的 Azure 文件存储，需要将存储文件数据 SMB 共享读者 Azure 基于角色的访问控制 (RBAC) 角色分配为默认共享级别权限，并配置 NTFS 权限以向每个会话主机的计算机对象授予读取访问权限。
有关将 Azure 文件存储与已加入 Microsoft Entra ID、Active Directory 域服务或 Microsoft Entra 域服务的会话主机配合使用的详细信息，请参阅用于 SMB 访问的 Azure 文件存储基于标识的身份验证选项概述。
对于具有 Active Directory 域服务的 Azure 文件存储，需要将存储文件数据 SMB 共享读者 Azure 基于角色的访问控制 (RBAC) 角色分配为默认共享级别权限，并配置 NTFS 权限以向每个会话主机的计算机对象授予读取访问权限。
若要详细了解如何将 Azure 文件存储与已加入 Active Directory 域服务或 Microsoft Entra 域服务的会话主机配合使用，请参阅用于 SMB 访问的 Azure 文件存储基于标识的身份验证选项概述。
可以使用 PsExec 验证权限是否正确。 有关详细信息，请参阅检查文件共享访问权限。
性能
要求可能会有很大差异，具体取决于映像中存储的打包应用程序数，你需要测试应用程序以了解要求。 对于较大的映像，需要分配更多带宽。 下表提供了包含一个应用程序的单个 1 GB MSIX 映像对每个会话主机的要求示例：
| 资源 | 要求 |
|---|---|
| 稳定状态 IOPS | 一个 IOP |
| 计算机启动登录 | 10 IOPS |
| 延迟 | 400 毫秒 |
若要优化应用程序的性能，建议：
文件共享应与会话主机位于同一 Azure 区域中。 如果使用 Azure 文件存储，则存储帐户需要与会话主机位于同一 Azure 区域中。
从防病毒扫描中排除包含你的应用程序的磁盘映像，因为它们是只读的。
确保存储和网络构造可以提供足够的性能。 应避免将同一文件共享用于 FSLogix 配置文件容器。
可用性
针对 Azure 虚拟机的任何灾难恢复计划都必须包括将 MSIX 应用附加文件共享复制到辅助故障转移位置的操作。 还需要确保文件共享路径在辅助位置可访问。 例如，可以将分布式文件系统 (DFS) 命名空间与 Azure 文件存储配合使用，以在不同的文件共享之间提供单个共享名称。 若要详细了解 Azure 虚拟桌面的灾难恢复，请参阅设置业务连续性和灾难恢复计划。
Azure 文件
Azure 文件存储对每个根目录、目录和文件的打开句柄数有限制。 使用应用附加或 MSIX 应用附加时，会使用会话主机的计算机帐户装载 VHDX 或 CimFS 磁盘映像，这意味着每个会话主机每个磁盘映像（而不是每个用户）会打开一个句柄。 有关限制和大小调整指南的详细信息，请参阅 Azure 文件可伸缩性和性能目标和适用于 Azure 虚拟桌面的 Azure 文件存储大小调整指南。
MSIX 和 Appx 包证书
所有 MSIX 和 Appx 包都需要有效的代码签名证书。 若要将这些包与应用附加配合使用，需要确保整个证书链在会话主机上都受到信任。 代码签名证书具有对象标识符 1.3.6.1.5.5.7.3.3。 可从以下项获取包的代码签名证书：
公共证书颁发机构 (CA)。
内部企业或独立证书颁发机构，例如 Active Directory 证书服务。 需要导出代码签名证书（包括其私钥）。
用于生成自签名证书的工具，例如 PowerShell cmdlet New-SelfSignedCertificate。 只能在测试环境中使用自签名证书。 若要详细了解如何为 MSIX 和 Appx 包创建自签名证书，请参阅为包签名创建证书。
获取证书后，需要使用证书对 MSIX 或 Appx 包进行数字签名。 创建 MSIX 包时，可以使用 MSIX 打包工具对包进行签名。 有关详细信息，请参阅通过任何桌面安装程序创建 MSIX 包。
为了确保证书在会话主机上受到信任，需要会话主机信任整个证书链。 如何执行此操作取决于从哪里获取证书以及如何管理会话主机和所使用的标识提供者。 关于如何确保证书在会话主机上受到信任，下表提供了一些指导：
公共 CA：Windows 和 Windows Server 中默认信任来自公共 CA 的证书。
内部企业 CA：
对于已加入 Active Directory 的会话主机，AD CS 配置为内部企业 CA，默认情况下受到信任，并存储在 Active Directory 域服务的配置命名上下文中。 将 AD CS 配置为独立 CA 时，需要配置组策略，以将根证书和中间证书分发到会话主机。 有关详细信息，请参阅使用组策略将证书分发到 Windows 设备。
对于已加入 Microsoft Entra ID 的会话主机，可以使用 Microsoft Intune 将根证书和中间证书分发到会话主机。 有关详细信息，请参阅Microsoft Intune 受信任的根证书配置文件。
对于使用 Microsoft Entra 混合联接的会话主机，可根据要求使用上述任一方法。
自签名：在每个会话主机上将受信任的根安装到“受信任的根证书颁发机构”存储中。 不建议使用组策略或 Intune 分发此证书，因为它只应用于测试。
重要
应设置包的时间戳，使其在证书到期日期之后仍然有效。 否则，证书过期后，需要使用新的有效证书更新包，并再次确保它在会话主机上受到信任。