Résoudre les problèmes de connectivité Azure Virtual Desktop

Problème

Les connexions Azure Virtual Desktop (AVD) échouent lorsque les utilisateurs accèdent à AVD à partir du réseau du bureau avec Cisco Secure Access activé. Ce comportement spécifique a été observé :

• AVD fonctionne correctement lorsqu'il est accessible à partir d'un réseau personnel avec accès sécurisé désactivé.

• AVD fonctionne correctement lorsqu'il est accessible à partir du réseau du bureau sans accès sécurisé.

• AVD ne fonctionne pas lorsqu'il est accessible à partir de n'importe quel réseau avec l'accès sécurisé activé.

Cette panne de connectivité affecte la capacité des utilisateurs à accéder à leurs postes de travail virtuels et affecte les opérations commerciales de production. L'analyse de capture de paquets a montré un trafic bidirectionnel dans les scénarios de fonctionnement et de non-fonctionnement sans réinitialisation TCP ou d'autres indicateurs au niveau du réseau indiquant que Secure Access mettait fin à la connexion AVD.

Environnement

• Cisco Secure Access avec ZTNA (Zero Trust Network Access) activé

• Profil ZTNA configuré pour utiliser ZTA pour toutes les destinations Internet

• Déploiement d'Azure Virtual Desktop (AVD) accessible via les terminaux Microsoft

• Environnement réseau de bureau avec client Secure Access déployé

• Utilisateurs accédant à AVD à partir de réseaux professionnels et personnels

Résolution

Le problème a été résolu en ajoutant les domaines liés à Microsoft AVD à la liste des exceptions ZTA, permettant au client Secure Access de contourner ZTNA pour le trafic AVD.

Analyse diagnostique

L'analyse de dépannage conjointe a déterminé que le profil ZTNA était configuré pour utiliser ZTA pour toutes les destinations Internet, ce qui a amené Secure Access à acheminer le trafic WebSocket continu d'AVD via le proxy cloud Secure Access. Ce comportement a entraîné des abandons de session, car Azure Virtual Desktop utilise un trafic continu et complexe (WebSockets) pour diffuser des sessions de bureau en temps réel, et les proxys cloud sont conçus pour inspecter les pages Web standard plutôt que pour gérer les protocoles de diffusion.

Modification de configuration

Ces domaines liés à Microsoft AVD ont été ajoutés à la liste des exceptions ZTA :

*.wvd.microsoft.com
*.core.windows.net
*.servicebus.windows.net
*.events.data.microsoft.com

En ajoutant ces domaines à la liste des exceptions ZTA, le client Secure Access a reçu l'instruction d'ignorer complètement le trafic spécifique à AVD. Cela permet au trafic AVD d'aller directement à Microsoft, en contournant entièrement le proxy ZTNA, ce qui est exactement ce que Microsoft exige pour AVD de fonctionner correctement.

Validation

Après l'application de la configuration ZTA Exceptions, la connectivité AVD a été signalée comme fonctionnant normalement pendant la période de surveillance. Les utilisateurs ont pu accéder à leurs postes de travail virtuels à partir du réseau du bureau avec l'option Secure Access activée.

Motif

La cause principale était la configuration du profil ZTNA qui a intercepté tout le trafic lié à Internet, y compris les connexions Azure Virtual Desktop. Lorsque le trafic WebSocket d'AVD a été acheminé via le proxy cloud d'accès sécurisé pour inspection, il a provoqué des pertes de connexion, car le proxy n'était pas conçu pour gérer la nature de flux continu des sessions AVD. AVD nécessite une connectivité directe aux terminaux Microsoft pour maintenir la stabilité des sessions de diffusion sur le bureau.

Autres informations utiles

• Terminaux FQDN requis pour Microsoft Azure Virtual Desktop

• Dépannage et collecte des informations de base pour Cisco Secure Access

• Assistance technique de Cisco et téléchargements

Historique de révision

Révision	Date de publication	Commentaires
1.0	03-Nov-2026	Première publication