了解MSIX应用附加的功能与限制
凭借应用附加技术,IT部门可以为Windows应用程序执行部署和各种管理任务。MSIX应用附加功能已被弃用,但新特性带来了新的能力。
在短短几年内,MSIX应用附加已经发展了很多。随着微软更新其应用程序交付生态系统,应用附加已成为Azure虚拟桌面中应用程序部署的战略方向。这一转变使组织能够简化应用程序管理、降低基础设施复杂性,并将虚拟化应用程序交付扩展到混合云和云环境中。
通过这些变化,IT团队可以在应用程序生命周期管理方面获得更大的灵活性和控制力。组织应将应用附加的最新更新视为刷新其IT战略、优化许可和基础设施成本的机会。
微软应用虚拟化的近期变化
2023年4月,微软宣布App-V作为一个产品不再开发,并将在2026年终止支持。然而,在2024年11月,该公司宣布了以下变化:
- 先前关于App-V客户端终止支持的公告被撤销。
- 对App-V Sequencer的弃用声明被撤销。
- App-V Server仍将在原定日期终止支持。
- AVD中的应用附加功能现在将支持交付MSIX包和App-V包。
- 原始的MSIX应用附加功能将于2025年6月1日弃用。
- 新的应用附加功能将包含来自第三方厂商的集成,可通过与AVD的Azure控制台集成的额外第三方软件实现包交付。
由于这些变化,App-V包的主要交付方法将通过应用附加进行,因此仍在使用App-V的组织可以继续在AVD中使用应用附加。
什么是应用附加?
应用附加是一项将基于MSIX、App-V和AppX的应用程序交付到AVD虚拟机的功能。App-V是一种虚拟化应用程序格式,而AppX主要是通用Windows平台应用程序的包装器。
MSIX,最简单来说,是Windows应用程序的一种打包格式。与传统的微软安装程序格式相比,它提供了更新、改进的打包体验和生命周期管理。它还保留了当前应用程序包和安装文件的功能。此外,MSIX引入了用于打包和部署Win32、Windows Presentation Foundation和Windows窗体应用程序的新功能。
IT部门还可以配置MSIX打包的应用程序,使其在一个名为AppContainer的容器内运行。在此容器中,主应用程序进程及其子进程都在其中运行,允许它们通过文件系统和注册表虚拟化(类似于App-V所提供的)实现隔离运行。这使得IT专业人员可以在同一台机器上运行同一应用程序的多个版本,而不会引起任何冲突,即使它们需要读取或写入同一组文件或注册表。
每个AppContainer应用程序都可以访问全局注册表。然而,它只写入其独立的虚拟注册表和应用程序数据目录。这确保了在应用程序卸载或重置时数据会被移除。AppContainer应用程序的虚拟注册表和文件系统对于同一主机上的其他应用程序而言是不可访问的。
应用附加在AVD中如何工作
应用附加为其包定义使用了一种独特的格式,与标准的MSIX格式不同。这确保了当用户登录到Windows VDI会话时,应用程序能够快速可用。具体来说,该包格式是一个Windows磁盘分区或卷,被远程挂载,而不是复制到用户的虚拟机中,然后集成到环境中。
除了加快为用户准备好包的速度之外,应用附加在交付标准MSIX包方面没有增加任何新功能。此外,微软设计该功能是为了与AVD配合工作,以提供应用程序流式传输。
IT可以将应用附加包分配给任何主机池或会话主机,并将其分发到多个主机池。应用附加的好处之一是,它现在支持两种常见的身份选项:Active Directory或Microsoft Entra ID加入。这使得IT可以在不需要任何AD域控制器的情况下处理应用程序部署。
应用附加的工作原理是将应用程序映像存储在SMB版本3文件共享上,该共享在用户登录时挂载到每个会话主机上。这种设置在存储方面很灵活,因此IT不受限于特定的存储类型。微软的建议是使用Azure Files,因为它与Microsoft Entra ID和AD域服务都兼容。
另一个选择是Azure NetApp Files,但它要求会话主机加入AD DS,因为它不支持Entra ID。AVD中的每个主机都从文件共享挂载应用程序映像。这意味着每个主机都需要拥有NTFS和共享权限才能从文件共享读取对象。
例如,如果管理员计划在Entra ID加入的设备上使用AVD应用附加,他们只需要为AVD和Azure资源管理器提供程序服务主体分配"读取者和数据访问者"角色。
当计划为生产环境部署此功能时,IT必须采取以下措施:
- 确保文件共享与会话主机位于同一个Azure区域。
- 如果使用Azure Files,请确保存储账户也与会话主机位于同一区域。
- 将包含应用程序的磁盘映像从防病毒扫描(如Defender)中排除,因为它们是只读的。
- 确保存储和网络结构能够提供足够的性能。
- 避免将同一文件共享用于FSLogix配置文件容器。
MSIX应用程序在VDI主机上的集成过程涉及三个步骤:挂载、暂存和注册。对于单用户操作系统,这些步骤是为每个包单独执行的。在多用户操作系统中,对于已为其他用户添加的包,可能会省略挂载和暂存步骤。一旦应用程序注册,它就在与使用传统MSIX格式部署时相同的MSIX容器内运行。这种方法使应用程序能够像本地安装一样运行。
应用附加实施要求
MSIX支持其他Windows操作系统,包括Windows Server以及单会话和多会话配置的Windows 10和11。然而,应用附加功能明确要求Windows 10或11。
| 操作系统 | MSIX支持 | 应用附加支持 |
|---|---|---|
| Windows Server 2019 | 是 | 否 |
| Windows Server 2022 | 是 | 否 |
| Windows 10 和 11 单会话 | 是 | 是 |
| Windows 10 和 11 多会话 | 是 | 是 |
对于应用附加,IT可以使用新的复合映像文件系统、VHDX或虚拟硬盘用于磁盘映像,尽管微软不建议使用VHD。挂载和卸载CimFS映像的速度也明显快于VHD和VHDX。此外,这些过程消耗的CPU和内存更少。微软特别建议,如果会话主机运行的是Windows 11,则对应用程序映像使用CimFS。然而,目前用于CimFS的工具不多。它还绕过了VHD/VHDX所具有的256个字符的路径限制,这通常会影响捆绑了Python发行版等应用程序。
在这三种格式中,MSIX文件在使用应用附加时是未压缩存储的,这与原始的MSIX包不同(原始包是压缩的)。因此,平均而言,应用程序占用的存储空间是存储在文件共享上的MSIX包的2.5倍。
然而,应用附加强项之一是它不需要任何额外的基础设施,只需要存储。其他应用程序分层和虚拟化服务则有某些基础设施要求。
应用附加的未来
应用附加很可能将成为向AVD部署应用程序的默认服务。应用附加支持App-V的消息使组织更容易推迟转换其现有App-V应用程序的工作,因为并非所有应用程序都能直接转换为新的MSIX格式。
即使由于Windows 11版本24H2中MSIX格式的更改提高了兼容性,一些组织仍然在处理旧应用程序时遇到困难。
这也是为什么微软开始允许第三方厂商在应用附加之上构建集成。这有助于应用程序兼容性,同时也提供了更多的控制机制,以更动态地处理应用程序分发。以下厂商现在能够与应用附加集成:
- Liquidware FlexApp。
- Numecent Cloudpager。
- Omnissa App Volumes。
使用第三方厂商的优点之一是支持非Azure平台以及能够在物理设备上运行。与传统的基于MSIX的应用程序相比,它们还提供了更高的兼容率。另一个特性是支持应用程序分组。这使得例如两个给定的应用程序可以在其自己的虚拟环境中交互,这对于具有某种形式集成的应用程序很有用。
基于MSIX的应用程序还需要使用代码证书进行签名,该证书可以来自受信任的证书颁发机构或自签名证书,并且必须被主机池信任。对于没有相同要求的第三方工具,这个过程要简单得多。
这些变化对组织意味着什么?
因为应用附加支持Entra ID并且不需要专用基础设施,所以它为AVD提供了一种经济高效的应用程序交付方式。
随着微软仅支持基于AVD的环境中的App-V的策略,很明显该公司希望推动现有的App-V客户将其VDI工作负载也迁移到Azure。虽然它提供的功能可能适用于许多组织,但其他组织有特殊要求或复杂的应用程序列表,需要第三方工具。
这些发展表明微软打算使应用附加成为AVD中应用程序交付的标准,为组织提供一个可扩展的工作空间管理基础。