Azure Virtual Desktop Classic Retired : Prochaines étapes pour l'informatique

Introduction

La retraite d'Azure Virtual Desktop (classique) crée une distinction importante entre la perte d'un service de connexion hérité et la disponibilité continue des ressources Azure sous-jacentes. Pour les équipes informatiques qui ont manqué la date limite de migration, comprendre cette distinction est essentiel pour planifier la récupération sans remplacer inutilement l'infrastructure existante. Cet article explique ce que signifie la retraite pour les ressources existantes, comment identifier les déploiements classiques, quelles options de migration restent à évaluer et comment choisir une architecture de livraison d'applications prise en charge.

Que signifie la retraite d'Azure Virtual Desktop Classic ?

Microsoft a officiellement retiré Azure Virtual Desktop (classique) depuis le 30 septembre 2026. Selon la documentation officielle de Microsoft, « les connexions aux services classiques seront bloquées après le retrait. » Par conséquent, le retrait impacte le type spécifique de services liés à la gestion des bureaux virtuels et des applications utilisant le modèle de déploiement Azure Virtual Desktop (classique).

Cependant, le processus de retrait ne s'applique pas au bureau virtuel Azure moderne qui utilise Azure Resource Manager (ARM). Ainsi, la principale préoccupation pour les utilisateurs qui utilisent encore les ressources classiques est l'incapacité d'établir des connexions aux services qui fonctionnaient auparavant. Par conséquent, les utilisateurs doivent être particulièrement conscients de la gestion des ressources classiques, car les ressources elles-mêmes ne disparaîtront pas après la date de retrait.

Qu'est-ce qui a été exactement retiré ?

Azure Virtual Desktop (classique), précédemment connu sous le nom de Windows Virtual Desktop, avait son infrastructure de gestion basée sur des cmdlets PowerShell dédiés, des API et des objets de service.

Contrairement au bureau virtuel Azure moderne, les pools d'hôtes classiques et les groupes d'applications n'étaient pas définis comme des ressources unifiées du gestionnaire de ressources Azure.

Aujourd'hui, ces composants sont intégrés dans le système de gestion des ressources Azure, permettant aux administrateurs d'appliquer le contrôle d'accès basé sur les rôles Azure (RBAC), de gérer le service via le portail Azure et d'utiliser des modèles modernes d'infrastructure en tant que code pour l'automatisation du déploiement.

Capacité	AVD Classic (retired)	AVD moderne
Gestion	Plan de contrôle hérité	Gestionnaire de ressources Azure
portail Azure	Intégration limitée	Intégration native
Contrôle d'accès	Rôles de locataire hérités	Azure RBAC
Automatisation	APIs classiques et PowerShell	ARM, APIs, Az PowerShell
Distribution de bureau et d'application	Connexions bloquées	Pris en charge
État du service	Retraité	Pris en charge

La retraite représente un changement dans l'architecture de service sous-jacente, pas simplement un changement de nom de produit.

Est-ce que le bureau virtuel Azure moderne fonctionne toujours ?

Oui. Le bureau virtuel Azure moderne est pris en charge et continue d'offrir des bureaux Windows complets, des plateformes multisession et la livraison d'applications individuelles via RemoteApp.

Les organisations qui utilisent déjà les pools d'hôtes intégrés au gestionnaire de ressources Azure (ARM) ne sont pas affectées par la retraite du service classique.

Les responsables informatiques doivent également noter la différence entre la fin du support pour le classique Azure Virtual Desktop et la fin de support distincte pour les anciens clients Remote Desktop. Le client Remote Desktop pour Windows (MSI) devait atteindre la fin du support pour les environnements de cloud public le 27 mars 2026, et pour Azure Virtual Desktop (classique) le 28 septembre 2026.

Comment les équipes informatiques peuvent-elles identifier les déploiements classiques d'Azure Virtual Desktop ?

La première étape consiste à identifier si des charges de travail de production dépendent encore de l'architecture retirée.

Ceci est particulièrement critique pour les systèmes qui ont été mis en production il y a des années et qui ont pu être repris par de nouveaux administrateurs ou ignorés dans la documentation actuelle de l'infrastructure.

Vérifiez l'intégration d'Azure Resource Manager

Vous devriez commencer par inspecter les ressources Azure Virtual Desktop dans le portail Azure. Les déploiements modernes d'Azure Virtual Desktop exposent des pools d'hôtes, des groupes d'applications et des espaces de travail en tant que ressources Azure dans un abonnement et un groupe de ressources. En revanche, les déploiements classiques exposaient des objets de service gérés de différentes manières.

La présence des éléments suivants de l'Azure Virtual Desktop constitue un indicateur fort d'un déploiement classique :

• Pools d'hôtes qui utilisent le module PowerShell classique d'Azure Virtual Desktop
• Références historiques à un locataire de service classique ou à une API de service classique
• Groupes d'applications qui manquent de ressources ARM correspondantes
• Machines virtuelles hôtes de session qui se réfèrent à une documentation plus ancienne

En même temps, l'absence d'un pool d'hôtes dans le portail Azure n'est pas nécessairement une indication d'un déploiement classique. Vous devez toujours vérifier quelle souscription, quel locataire Microsoft Entra et quel contrôle d'accès basé sur les rôles l'utilisateur possède avant d'analyser davantage le problème.

Examiner les outils de gestion des anciens systèmes et des dépendances

Les scripts de déploiement et les dépôts d'automatisation peuvent servir de sources supplémentaires de preuves.

Par exemple, la présence de scripts contenant des références Microsoft.RDInfra.RDPowerShell ou des opérations de gestion au niveau du locataire classiques suggérerait que l'environnement a été configuré avec l'ancienne pile de gestion.

Les environnements modernes tireront parti des interfaces de gestion intégrées à Azure Resource Manager et des modules Az PowerShell associés.

Les administrateurs devraient également inventorier toutes les ressources d'application, d'utilisateur et d'infrastructure associées aux pools d'hôtes potentiellement impactés.

Cela inclut l'examen des machines virtuelles hôtes de session, des attributions d'applications, des emplacements de stockage de profils, des dépendances d'authentification, des configurations réseau et des dépôts de sauvegarde. Le documentation de migration manuelle Microsoft contient des comparaisons détaillées entre le modèle d'objet de service classique et le modèle de ressource intégré à Azure Resource Manager (ARM).

Que peut-il arriver à vos ressources existantes après la retraite d'Azure Virtual Desktop Classic ?

La différence la plus importante est entre le service de connexion retiré et l'infrastructure Azure sous-jacente.

Bien que les connexions de bureau classiques soient bloquées, les machines virtuelles existantes, les ressources de stockage et les données d'application peuvent rester en place.

Les machines virtuelles et le stockage existants peuvent rester disponibles

Les machines virtuelles Azure sont des ressources qui sont gérées de manière autonome, sans dépendre du plan de contrôle de service classique retiré. Ainsi, les machines virtuelles hôtes de session, les disques gérés et les ressources réseau qui ont été créés dans l'abonnement peuvent encore exister.

Cependant, ils ne peuvent pas être utilisés pour rétablir le courtier de connexion à la retraite. Aucune machine virtuelle créée dans la nouvelle infrastructure Azure n'est disponible pour ramener l'expérience de bureau d'une organisation à l'état de fonctionnement.

Les administrateurs doivent examiner chaque ressource attentivement, et si elle peut être réutilisée pour une configuration prise en charge, ils doivent effectuer les étapes suivantes.

Il est essentiel de vérifier si le système d'exploitation de la machine virtuelle est pris en charge et si les applications et les configurations de sécurité sont compatibles.

L'accès aux applications et les données utilisateur nécessitent des vérifications distinctes

Les utilisateurs qui se sont connectés via le bureau classique ou le type de session RemoteApp ne pourront plus lancer leurs applications via ce service.

Le résultat de la cessation du service pourrait être la perte d'accès aux bureaux, aux applications publiées et des perturbations des processus commerciaux.

Cependant, la cessation du service ne garantit pas que les données liées à l'utilisateur soient supprimées.

Dans la plupart des cas, il s'agit probablement des données des utilisateurs qui sont conservées sur Azure Files, les disques VM ou d'autres supports de stockage, mais la conservation et l'accessibilité de ces informations dépendraient de la manière dont elles ont été configurées, sécurisées avec des autorisations, sauvegardées, etc.

Ainsi, avant de décommissionner ou de migrer les systèmes concernés, les départements informatiques doivent s'assurer qu'ils ont préservé toutes les données nécessaires.

Une équipe peut-elle encore migrer Azure Virtual Desktop Classic après sa retraite ?

Microsoft documente deux chemins de migration pour passer d'Azure Virtual Desktop (classique) au nouveau Azure Virtual Desktop intégré à ARM : migration automatique et migration manuelle.

Les deux options étaient destinées à être viables jusqu'au 30 septembre 2026.

Étant donné que cette date est dans le passé, les administrateurs ne devraient pas considérer les outils décrits dans la documentation comme prêts pour la production dans tous les scénarios.

La documentation de Microsoft ne fournit pas d'orientation sur la période de transition.

Par conséquent, les organisations ne devraient pas compter sur des outils et des processus de transition post-retraite.

Option 1 : Migration automatique

Le processus de migration automatique de Microsoft utilise un outil basé sur PowerShell pour déplacer les configurations de service classique éligibles vers des ressources ARM.

La documentation de l'entreprise recommande que les utilisateurs aient un abonnement Azure actif avec les autorisations nécessaires et répondent aux exigences environnementales énumérées par le module de migration.

Par exemple, les directives de Microsoft suggèrent que les utilisateurs soient délégués avec des autorisations de contributeur pour créer des ressources Azure et des autorisations d'administrateur d'accès utilisateur pour gérer l'appartenance au groupe d'applications.

Cependant, il est essentiel de reconnaître que l'outil ne peut garantir la récupération des données après la retraite.

Les organisations avec des déploiements classiques actifs devraient consulter le support Microsoft pour confirmer si le processus de migration est une option disponible pour leur environnement.

Option 2 : Migration manuelle ou reconstruction

La migration manuelle nécessite la création de ressources modernes Azure Virtual Desktop et la reconfiguration de la configuration du service.

Selon le cas spécifique, les administrateurs peuvent avoir besoin de :

• Créer des pools d'hôtes basés sur ARM intégrés, des groupes d'applications et des espaces de travail
• Établir ou remplacer des machines virtuelles hôtes de session
• Enregistrer des hôtes de session compatibles avec les nouveaux pools d'hôtes
• Recréer les associations utilisateur et application
• Ajuster les configurations d'identité, de réseau, de sécurité et de profil

L'approche manuelle devient nécessaire lorsque les configurations héritées contiennent une complexité non documentée, une personnalisation extensive, ou lorsque les outils de migration modernes s'avèrent insuffisants.

Il est à noter que la reconstruction de l'infrastructure de livraison n'implique pas toujours le remplacement complet des applications et des données.

Les composants restants peuvent souvent être réutilisés grâce à des évaluations de compatibilité appropriées, des évaluations de licences et des audits de sécurité.

La décision devrait être basée sur l'état actuel des ressources existantes et du support disponible de Microsoft.

Situation	Approche pour évaluer
Configuration classique éligible et Microsoft confirme le support de migration	Migration automatique
Configuration classique complexe ou inaccessible	Reconstruction manuelle
Les VM existantes et les données restent disponibles	Reconstruire les services de livraison et évaluer la réutilisation
Les charges de travail héritées ne sont plus nécessaires	Démantèlement sécurisé
Les bureaux hébergés sur Azure ne sont plus nécessaires	Architecture de livraison alternative

Que doivent faire les équipes informatiques si elles ont manqué la date limite de retrait ?

Les organisations qui n'ont pas terminé leur migration d'ici le 30 septembre 2026 devraient donner la priorité à la préservation des ressources et à la restauration de l'accès aux applications métier.

Au lieu de tenter plusieurs connexions au service retiré, il est conseillé aux administrateurs d'effectuer un processus de récupération.

Étape 1 : Évaluer l'impact du service

Identifiez quels utilisateurs, bureaux et applications sont indisponibles.

Découvrez s'il s'agit d'un environnement entier ou de charges de travail spécifiques qui sont impactées. Confirmez que le problème est lié à une retraite classique et non à un autre problème d'authentification, de réseau ou d'hôte de session.

Étape 2 : Préserver l'infrastructure et les données

Examinez les abonnements Azure pour identifier les machines virtuelles actuelles, les disques gérés, les comptes de stockage et les ressources réseau.

Documentez les dépendances et assurez sauvegardes exister avant de prendre toute action. Ne supprimez pas les ressources tant que les données de l'application, les profils d'utilisateur et les informations de configuration n'ont pas été identifiés.

Étape 3 : Confirmer les options de récupération avec Microsoft

Contactez le support Microsoft pour vous assurer qu'il existe encore des procédures de migration/récupération prises en charge.

Les instructions de migration automatiques/manuelles initiales ont été élaborées en tenant compte de la date de retrait et ne doivent donc pas être considérées comme applicables.

Dans le cas où la configuration classique ne peut pas être migrée, il peut être nécessaire de reconstruire l'environnement avec des ressources Azure Virtual Desktop prises en charge.

Étape 4 : Restaurer la livraison d'application et de bureau

Sélectionnez une architecture qui prend en charge les applications et les bureaux dont les utilisateurs ont besoin.

Pour les organisations qui prévoient de rester sur Azure Virtual Desktop, cela implique généralement la configuration de pools d'hôtes intégrés ARM, d'hôtes de session pris en charge, de groupes d'applications et d'attributions d'utilisateurs.

Certaines organisations peuvent constater qu'un autre publication d'application ou la solution de bureau correspond mieux à leurs besoins.

L'objectif est de rétablir l'accès tout en évitant la complexité et les frais généraux inutiles de la configuration précédente.

Quelle est la méthode pour valider une migration vers un bureau virtuel Azure ?

Restaurer l'infrastructure ne garantit pas le bon fonctionnement des utilisateurs.

Une migration ou une reconstruction doit donc être validée aux niveaux du service et de l'application.

Vérifier l'authentification et l'accès utilisateur

Confirmez que les utilisateurs peuvent s'authentifier et accéder aux ressources qui leur ont été attribuées.

Vérifiez Microsoft Entra, l'authentification multifactorielle, les politiques d'accès conditionnel et les attributions Azure RBAC le cas échéant.

Les administrateurs doivent confirmer que les autorisations sont alignées sur le principe du moindre privilège et qu'il n'existe pas de modèles d'accès hérités qui ont été transférés par inadvertance.

Tester des applications critiques pour les entreprises

Testez les applications et bureaux publiés en utilisant des comptes utilisateurs représentatifs distincts.

Les activités de validation devraient inclure le lancement d'applications, les connexions à la base de données, les partages réseau, l'impression, la redirection du presse-papiers et les périphériques requis le cas échéant.

Les applications héritées doivent être prises en considération de manière spéciale car elles peuvent nécessiter une configuration spécifique du système d'exploitation, un chemin réseau ou un composant d'application.

Un exemple d'une application héritée pourrait être une application ERP qui se lance avec succès mais échoue à se connecter à sa base de données depuis le nouvel hôte de session.

Valider les profils, la performance et les opérations

Les entreprises qui utilisent FSLogix ou l'un des autres outils de profilage doivent s'assurer que tout est correctement attaché, est persistant et peut être correctement accessible.

Il est essentiel de le tester en se connectant pour la première fois et en vérifiant si tout fonctionnera correctement lorsqu'un utilisateur ouvrira une application et lors de la prochaine connexion. Il est également crucial de s'assurer que les processus sont surveillés, sauvegardés et restaurés.

La migration est complète uniquement lorsque tout est prêt, y compris les utilisateurs pouvant accéder à leurs applications. Il doit être possible de maintenir le système correctement.

Les organisations devraient-elles reconsidérer leur architecture de livraison de bureau ?

La retraite d'Azure Virtual Desktop (classique) est principalement un problème de cycle de vie de la plateforme, mais elle présente également une opportunité d'évaluer si la plateforme de livraison de bureau actuelle continue de répondre à vos besoins.

Le passage à Azure Virtual Desktop moderne est le choix évident pour beaucoup, en particulier pour ceux qui sont déjà Azure-first et utilisent des bureaux hébergés sur Azure.

D'autres organisations ont des exigences moins complexes.

Quand le bureau virtuel moderne Azure a-t-il du sens ?

Bureau Virtuel Azure Moderne peut convenir aux organisations qui nécessitent des bureaux et des applications Windows gérés de manière centralisée, hébergés sur Azure.

Il permet des sessions multiples, des modèles RemoteApp, ainsi que des outils d'administration et d'identification Microsoft.

Il est logique pour les entreprises qui ont déjà une empreinte Azure, mais les départements informatiques doivent toujours faire face aux complexités du cloud, y compris la gestion des licences, le réseau, le stockage, l'administration et les aspects opérationnels.

Quand une autre architecture de publication d'application Windows est-elle appropriée ?

Toutes les organisations n'ont pas besoin d'un environnement de virtualisation de bureau entièrement mis en œuvre hébergé dans Microsoft Azure.

Certaines entreprises n'ont besoin que d'un accès limité remote access à des applications Windows spécifiques, telles que des applications financières ou des applications ERP ou des applications métier héritées.

Ces organisations peuvent envisager de publier des applications qui sont hébergées sur des serveurs Windows gérés de manière centralisée au lieu de déployer une infrastructure de bureau virtuel (VDI) généralisée.

Le bureau virtuel moderne Azure ne concerne pas seulement la virtualisation de bureaux ou d'applications, mais aussi la publication d'applications.

Aujourd'hui, il est possible de publier des applications Azure en utilisant la méthode RemoteApp.

La réalité est qu'il n'y a pas de dichotomie dans le domaine de la livraison d'applications, mais plutôt un continuum qui va de la publication d'applications à la virtualisation de bureau.

La discussion devrait se concentrer sur la recherche de l'architecture de livraison d'applications la plus pertinente pour l'organisation et les cas d'utilisation donnés.

Par exemple, s'il existe une application de longue date hébergée dans un dossier Windows Server accessible par un ensemble d'utilisateurs autorisés, l'organisation n'a pas besoin de la publier dans Azure Virtual Desktop lorsque l'infrastructure héritée fonctionne encore correctement.

Au lieu de cela, il pourrait être bénéfique pour de telles entreprises de laisser leur emplacement d'hébergement d'application sur site tout en améliorant leur méthode d'accès à l'application.

Quels facteurs devraient guider la décision ?

Les départements informatiques devraient évaluer le choix en fonction des critères des besoins de déploiement, plutôt qu'en fonction des fonctionnalités du système désaffecté.

Considération	Question clé
Hébergement	Les charges de travail doivent-elles s'exécuter dans Azure ?
Expérience utilisateur	Desktops complets ou applications sélectionnées ?
Compatibilité	Les applications Windows existantes fonctionneront-elles ?
Sécurité	Comment l'identité et l'accès aux sessions sont-ils protégés ?
Gestion	Qui maintient l'infrastructure ?
Licences	Quelles licences Microsoft et logiciels s'appliquent ?
Évolutivité	Combien d'utilisateurs simultanés sont nécessaires ?
Coût	Quel est le coût total de possession ?

L'objectif est de sélectionner une architecture d'entreprise qui répondra aux exigences de disponibilité, de sécurité et de réduction de la complexité administrative.

À la recherche d'une alternative pour la livraison d'applications Windows et de bureau ?

Migrer vers un bureau virtuel Azure moderne n'est pas nécessairement la meilleure option pour chaque organisation. Les entreprises qui ont principalement besoin d'accéder à des applications Windows existantes ou à des bureaux hébergés de manière centralisée peuvent bénéficier d'une architecture plus simple, en particulier lorsqu'elles n'ont pas besoin d'un environnement de bureau virtuel entièrement hébergé sur Azure.

TSplus Remote Access permet aux équipes informatiques de publier des applications Windows et des bureaux à distance complets via des clients compatibles RDP ou un portail web HTML5. Avec un support pour les serveurs Windows sur site et hébergés dans le cloud, il offre une alternative pratique pour les organisations cherchant à maintenir leurs applications existantes tout en simplifiant la livraison d'applications à distance.

Conclusion

La retraite d'Azure Virtual Desktop (classique) rend essentiel d'identifier les déploiements affectés, de préserver les ressources existantes et de restaurer l'accès via une infrastructure prise en charge. Les équipes informatiques doivent vérifier les options de récupération disponibles avant d'essayer la migration ou la reconstruction.

Que les organisations continuent avec Azure Virtual Desktop moderne ou adoptent une autre architecture de livraison, la priorité reste d'assurer un accès aux applications sécurisé et fiable sans complexité opérationnelle inutile.