Azure Virtual Desktop Classic 已退役：IT 的下一步

介绍

Azure Virtual Desktop（经典版）的退役在遗留连接服务的丧失与基础 Azure 资源的持续可用性之间创造了一个重要的区别。对于错过迁移截止日期的 IT 团队来说，理解这一区别对于规划恢复至关重要，以避免不必要地替换现有基础设施。本文解释了退役对现有资源的意义，如何识别经典部署，哪些迁移选项仍值得评估，以及如何选择受支持的应用交付架构。

当 Azure 虚拟桌面经典版退役时意味着什么？

微软已于2026年9月30日正式退役Azure虚拟桌面（经典版）。根据微软的官方文档，“经典服务的连接将在退役后被阻止。”因此，退役影响与使用Azure虚拟桌面（经典版）部署模型的虚拟桌面和应用程序管理相关的特定类型服务。

然而，退休过程不适用于使用 Azure 资源管理器 (ARM) 的现代 Azure 虚拟桌面。因此，仍在使用经典资源的用户主要关心的是无法建立与之前正常工作的服务的连接。因此，用户应特别注意经典资源管理，因为资源本身在退休日期后不会消失。

到底退役了什么？

Azure Virtual Desktop（经典版），以前称为Windows Virtual Desktop，其管理基础设施基于专用的PowerShell cmdlets、API和服务对象。

与现代 Azure 虚拟桌面不同，经典主机池和应用程序组并未定义为统一的 Azure 资源管理器资源。

今天，这些组件被纳入Azure资源管理系统，使管理员能够应用Azure基于角色的访问控制（RBAC），通过Azure门户管理服务，并使用现代基础设施即代码模式进行部署自动化。

能力	AVD经典（已退役）	现代AVD
管理	遗留控制平面	Azure 资源管理器
Azure 门户	有限集成	原生集成
访问控制	遗留租户角色	Azure RBAC
自动化	经典API和PowerShell	ARM, APIs, Az PowerShell
桌面和应用程序交付	连接被阻止	支持
服务状态	退休	支持

退休代表了基础服务架构的变化，而不仅仅是产品名称的更改。

现代 Azure 虚拟桌面仍然有效吗？

是的。现代 Azure 虚拟桌面受到支持，并继续通过 RemoteApp 提供完整的 Windows 桌面、多会话平台和单个应用程序交付。

已经使用集成了 Azure 资源管理器 (ARM) 的主机池的组织不会受到经典服务退役的影响。

IT 经理还应注意经典 Azure 虚拟桌面结束支持与旧版远程桌面客户端单独结束支持之间的区别。Windows 的远程桌面客户端 (MSI) 计划于 2026 年 3 月 27 日在公共云环境中结束支持，并于 2026 年 9 月 28 日在 Azure 虚拟桌面（经典）中结束支持。

IT团队如何识别Azure虚拟桌面经典部署？

第一步是确定是否还有任何生产工作负载依赖于已退役的架构。

这对于那些多年前投入生产的系统尤其重要，这些系统可能已被新管理员重新接管或在当前基础设施文档中被忽视。

检查 Azure 资源管理器集成

您应该首先检查 Azure 门户中的 Azure 虚拟桌面资源。现代 Azure 虚拟桌面部署将主机池、应用程序组和工作区作为订阅和资源组中的 Azure 资源进行公开。相比之下，经典部署曾用于以不同方式管理的服务对象。

以下 Azure 虚拟桌面元素的存在是经典部署的强有力指标：

• 使用经典 Azure 虚拟桌面 PowerShell 模块的主机池
• 对经典服务租户或经典服务API的历史参考
• 缺少相应ARM资源的应用程序组
• 引用旧文档的会话主机虚拟机

同时，Azure 门户中缺少主机池并不一定表示经典部署。在进一步分析问题之前，您应始终检查用户拥有的订阅、Microsoft Entra 租户和基于角色的访问控制。

审查遗留管理工具和依赖关系

部署脚本和自动化存储库可以作为补充证据来源。

例如，包含 Microsoft.RDInfra.RDPowerShell 引用或经典租户级管理操作的脚本的存在表明该环境是使用较旧的管理堆栈配置的。

现代环境将利用集成Azure资源管理器的管理接口和相关的Az PowerShell模块。

管理员还应清点与可能受影响的主机池相关的所有应用程序、用户和基础设施资源。

这包括检查会话主机虚拟机、应用程序分配、配置文件存储位置、身份验证依赖关系、网络配置和备份存储库。 微软手动迁移文档 包含经典服务对象模型与集成Azure资源管理器（ARM）资源模型之间的详细比较。

您的现有资源在 Azure Virtual Desktop Classic 停用后会发生什么？

最重要的区别在于已退役的连接服务和基础的Azure基础设施之间。

虽然经典桌面连接被阻止，但现有的虚拟机、存储资源和应用数据可以保持原位。

现有虚拟机和存储可能仍然可用

Azure 虚拟机是独立管理的资源，无需依赖已退役的经典服务控制平面。因此，在订阅中创建的会话主机虚拟机、托管磁盘和网络资源可能仍然存在。

然而，它们不能用于恢复已退役的连接代理。在新的 Azure 基础设施中创建的虚拟机无法将组织的桌面体验恢复到工作状态。

管理员应仔细检查每个资源，如果可以在支持的配置中重复使用，则应执行以下步骤。

检查虚拟机的操作系统是否受支持，以及应用程序和安全配置是否兼容是至关重要的。

应用访问和用户数据需要单独检查

通过经典桌面或RemoteApp会话类型连接的用户将无法再通过此服务启动他们的应用程序。

退休该服务的结果可能导致无法访问桌面、发布的应用程序以及业务流程的中断。

然而，服务的终止并不保证用户相关数据被删除。

在大多数情况下，用户的数据可能会保存在 Azure Files、虚拟机磁盘或其他存储介质上，但这些信息的保留和可访问性将取决于其配置、权限安全性、备份等方式。

因此，在停用或迁移相关系统之前，IT部门需要确保他们已保存所有必要的数据。

团队在 Azure 虚拟桌面经典版退役后还能迁移吗？

微软为从 Azure 虚拟桌面（经典版）迁移到新的 ARM 集成 Azure 虚拟桌面提供了两条迁移路径：自动迁移和手动迁移。

这两个选项的目的是在2026年9月30日之前可行。

由于该日期已过去，管理员不应将文档中描述的工具视为适用于所有场景的生产就绪状态。

微软的文档没有提供过渡期的指导。

因此，组织不应依赖任何退休后过渡工具和流程。

选项 1：自动迁移

微软的自动迁移过程 利用基于PowerShell的工具将符合条件的经典服务配置迁移到ARM资源。

公司的文档建议用户拥有一个有效的 Azure 订阅，并具备必要的权限，同时满足迁移模块列出的环境要求。

例如，微软的指南建议用户被授予贡献者权限以创建 Azure 资源，以及用户访问管理员权限以管理应用程序组成员资格。

然而，必须认识到该工具无法保证在退役后恢复数据。

拥有活跃经典部署的组织应咨询微软支持，以确认迁移过程是否是其环境的可用选项。

选项 2：手动迁移或重建

手动迁移需要创建现代 Azure 虚拟桌面资源并重新配置服务配置。

根据具体情况，管理员可能需要：

• 创建集成的基于ARM的主机池、应用程序组和工作区
• 建立或替换会话主机虚拟机
• 注册与新主机池兼容的会话主机
• 重新创建用户和应用程序关联
• 调整身份、网络、安全和配置文件设置

当遗留配置包含未记录的复杂性、广泛的自定义，或当现代迁移工具证明不足时，手动方法变得必要。

值得注意的是，重建交付基础设施并不总是涉及对应用程序和数据的完全替换。

剩余组件通常可以通过适当的兼容性评估、许可评估和安全审计进行重复使用。

决策应基于现有资源的当前状态和来自微软的可用支持。

情况	评估方法
符合条件的经典配置和微软确认迁移支持	自动迁移
复杂或无法访问的经典配置	手动重建
现有的虚拟机和数据保持可用	重建交付服务并评估重用
遗留工作负载不再需要	安全退役
不再需要 Azure 托管的桌面	替代交付架构

如果IT团队错过了退休截止日期，他们应该做什么？

截至2026年9月30日尚未完成迁移的组织应优先考虑资源的保护和业务应用访问的恢复。

建议管理员执行恢复过程，而不是尝试多次连接已退役的服务。

步骤 1：评估服务影响

识别哪些用户、桌面和应用程序不可用。

找出是整个环境还是特定工作负载受到影响。确认问题与经典退休有关，而不是其他身份验证、网络或会话主机相关的问题。

步骤 2：保护基础设施和数据

审核 Azure 订阅以识别当前的虚拟机、托管磁盘、存储帐户和网络资源

文档依赖关系并确保 备份 在采取任何行动之前存在。请勿删除资源，直到应用程序数据、用户配置文件和配置信息已被识别。

步骤 3：确认与 Microsoft 的恢复选项

联系微软支持以确保仍然有可用的迁移/恢复程序。

初始的自动/手动迁移说明是在考虑退休日期的情况下制定的，因此不应假定其适用。

在经典配置无法迁移的情况下，可能需要使用受支持的 Azure 虚拟桌面资源重新构建环境。

步骤 4：恢复应用程序和桌面交付

选择支持用户所需应用程序和桌面的架构。

对于计划继续使用 Azure 虚拟桌面的组织，这通常涉及设置集成 ARM 的主机池、受支持的会话主机、应用程序组和用户分配。

一些组织可能会发现另一个 应用程序发布 或桌面解决方案更符合他们的需求。

目标是重新建立访问，同时避免之前设置的复杂性和不必要的开销。

验证 Azure 虚拟桌面迁移的方法是什么？

恢复基础设施并不保证用户操作正常。

因此，迁移或重建必须在服务和应用程序层面进行验证。

验证身份和用户访问

确认用户可以进行身份验证并访问已分配给他们的资源。

检查 Microsoft Entra、多因素身份验证、条件访问策略和 Azure RBAC 分配（如适用）。

管理员应确认权限与最小权限原则一致，并确保没有意外延续的遗留访问模式。

测试业务关键应用程序

测试发布的应用程序和桌面，利用不同的代表用户帐户。

验证活动应包括应用程序启动、数据库连接、网络共享、打印、剪贴板重定向以及任何必要的外设。

遗留应用程序必须特别考虑，因为它们可能需要特定的操作系统配置、网络路径或应用程序组件。

一个遗留应用程序的例子可能是一个ERP应用程序，它成功启动但无法从新的会话主机连接到其数据库。

验证配置文件、性能和操作

使用 FSLogix 或其他任何配置工具的公司应确保所有内容都正确附加、持久，并且可以正确访问。

首次登录时进行测试至关重要，以检查用户在打开应用程序和下次登录时一切是否正常工作。确保流程得到监控、备份和恢复也是至关重要的。

迁移只有在一切准备就绪时才算完成，包括用户能够访问他们的应用程序。必须能够正确维护系统。

组织是否应该重新考虑他们的桌面交付架构？

Azure Virtual Desktop (classic) 退役主要是一个平台生命周期问题，但这也提供了一个机会来评估当前的桌面交付平台是否继续满足您的需求。

转向现代 Azure 虚拟桌面显然是许多人的明智选择，尤其是那些已经优先使用 Azure 并利用 Azure 托管桌面的用户。

其他组织的复杂要求较少。

现代 Azure 虚拟桌面何时有意义？

现代Azure虚拟桌面 可能适合需要集中管理的Windows桌面和应用程序的组织，这些桌面和应用程序托管在Azure上。

它支持多会话、RemoteApp 模式以及 Microsoft ID 和管理工具。

对于已经拥有 Azure 足迹的企业来说，这是有意义的，但 IT 部门仍然必须处理云的复杂性，包括许可、网络、存储、管理和运营方面。

何时适合使用其他Windows应用程序发布架构？

并非所有组织都需要在 Microsoft Azure 中托管的完全实施的桌面虚拟化环境。

一些企业只需要有限的 remote access 到特定的Windows应用程序，例如财务或ERP应用程序或传统的业务应用程序。

这些组织可以考虑发布托管在集中管理的Windows服务器上的应用程序，而不是部署通用的虚拟桌面基础设施（VDI）。

现代 Azure 虚拟桌面不仅仅是关于桌面或应用程序虚拟化，还涉及应用程序发布。

今天，可以使用 RemoteApp 方法发布 Azure 应用程序。

现实情况是，应用交付领域并不存在二分法，而是一个从应用发布到桌面虚拟化的连续体。

讨论应集中在为特定组织和用例寻找最相关的应用交付架构。

例如，如果有一个长期运行的应用程序托管在 Windows Server 文件夹中，并由一组授权用户访问，则在传统基础设施仍正常工作的情况下，组织无需将其发布在 Azure 虚拟桌面上。

相反，对于这些企业来说，将其应用程序托管位置保留在本地，同时升级其应用程序访问方法可能是有益的。

什么因素应该指导决策？

IT部门应根据部署需求的标准评估选择，而不是退役系统的功能。

考虑	关键问题
托管	工作负载必须在 Azure 中运行吗？
用户体验	完整桌面还是选定应用程序？
兼容性	现有的Windows应用程序会工作吗？
安全性	身份和会话访问是如何保护的？
管理	谁维护基础设施？
许可	哪些 Microsoft 和软件许可证适用？
可扩展性	需要多少个并发用户？
成本	拥有总成本是多少？

选择一个能够满足可用性、安全性和降低管理复杂性要求的企业架构。

寻找Windows应用程序和桌面交付的替代方案吗？

迁移到现代 Azure 虚拟桌面并不一定是每个组织的最佳选择。主要需要访问现有 Windows 应用程序或集中托管桌面的企业可能会受益于更简单的架构，特别是在他们不需要完全 Azure 托管的虚拟桌面环境时。

TSplus 远程访问 使IT团队能够通过RDP兼容客户端或HTML5网页门户发布Windows应用程序和完整的远程桌面。它支持本地和云托管的Windows服务器，为寻求维护现有应用程序的组织提供了一个实用的替代方案，同时简化了远程应用程序交付。

结论

Azure Virtual Desktop (classic) 的退役使得识别受影响的部署、保留现有资源并通过受支持的基础设施恢复访问变得至关重要。IT 团队在尝试迁移或重建之前应验证可用的恢复选项。

无论组织是继续使用现代 Azure 虚拟桌面还是采用其他交付架构，优先事项仍然是确保安全、可靠的应用程序访问，而不增加不必要的操作复杂性。