01 · Architecture et réseau d'Azure Virtual Desktop : reverse connect, RDP Shortpath, Private Link

Version : 1.1 · Date : 2026-10-22 · Domaine 1 de l'examen : Plan and implement an Azure Virtual Desktop infrastructure (40 à 45 %)

En une phrase : Microsoft héberge le plan de contrôle (gateway, broker, web, diagnostics) et vos session hosts ne font que sortir en HTTPS 443 vers lui (reverse connect) ; tout le travail réseau consiste à laisser passer les bonnes URL, à faire passer la session en UDP (RDP Shortpath, RDP Multipath, QoS), à la rendre privée si besoin (Private Link) et à mesurer la latence et la bande passante pour dépanner.

Ce que l'examen demande#

Repris mot pour mot du guide d'étude AZ-140 (compétences mesurées au 20 juillet 2026), bloc Plan, implement, and manage networking for Azure Virtual Desktop :

Ce chapitre ouvre le cours : la section 1 donne le vocabulaire AVD utilisé partout ensuite. Il renvoie au chapitre 03 (host pools, application groups, workspaces), au chapitre 02 (Azure Files et FSLogix), au chapitre 05 (NSG, UDR, Azure Firewall, Bastion, Conditional Access), au chapitre 06 (clients et RDP properties) et au chapitre 08 (Log Analytics, Insights, multi-région). Les bases réseau Azure (NSG, service tags, private endpoints, VPN, ExpressRoute) sont supposées acquises (AZ-700) ; les rappels sécurité sont dans SC-500 06.

1. Azure Virtual Desktop en 10 minutes pour un architecte#

1.1 Le plan de contrôle, géré par Microsoft#

Azure Virtual Desktop (AVD) est un service PaaS : vous ne déployez ni passerelle, ni broker, ni portail web. Ces composants tournent chez Microsoft, dans une quarantaine de régions Azure, avec au moins six instances de chaque composant par région.

Le plan de contrôle bascule tout seul d'une région à l'autre en cas d'incident : la reprise après sinistre que vous devez concevoir ne concerne que vos session hosts, vos profils et vos applications (chapitre 08).

1.2 Les objets que vous créez#

Le détail (règles des application groups, load balancing, licences) est au chapitre 03. AVD classic (l'ancienne version sans Azure Resource Manager) est retiré depuis le 30 septembre 2026 : toute question parle désormais d'AVD Azure Resource Manager.

1.3 La responsabilité partagée#

1.4 AVD, Windows 365 ou RDS ?#

À l'examen : multi-session, RemoteApp, choix fin des VM, coût à l'usage → AVD ; un PC cloud par personne, prix fixe, gestion Intune, sans compétence Azure → Windows 365 ; sur site sans dépendance cloud → RDS (ou AVD sur Azure Local / AVD Hybrid si le service doit rester géré par Azure).

2. Le flux de connexion : reverse connect#

2.1 La séquence#

sequenceDiagram
    participant C as Client (Windows App)
    participant E as Microsoft Entra ID
    participant W as Web service (feed)
    participant G as Gateway (via Azure Front Door)
    participant B as Broker
    participant H as Session host (agent)
    H->>B: Canal persistant, HTTPS 443 sortant
    C->>E: Authentification, jeton
    C->>W: Abonnement au workspace, feed
    W-->>C: Fichiers .rdp signés
    C->>G: TLS 443 vers la gateway la plus proche
    G->>B: Demande de connexion
    B->>H: Orchestration via le canal persistant
    H->>G: Connexion sortante 443 à la même gateway
    C-->>H: Session RDP dans un TLS imbriqué

1. Le client s'abonne au workspace, obtient un jeton Microsoft Entra ID et télécharge le feed : la liste des bureaux et applications, sous forme de fichiers .rdp signés.
2. À l'ouverture d'une ressource, le client se connecte en TLS sur 443 à la gateway la plus proche, en passant par Azure Front Door.
3. La gateway transmet au broker, qui choisit le session host et le prévient par le canal persistant que l'agent du session host maintient ouvert (Remote Desktop Agent Loader, service RDAgentBootLoader).
4. Le session host ouvre à son tour une connexion sortante 443 vers la même gateway.
5. Les deux tronçons sont reliés : la session RDP circule dans un TLS imbriqué de bout en bout.

2.2 Ce qu'il faut en retenir pour le réseau#

• Aucun port entrant sur les session hosts, aucune IP publique nécessaire : tout part en sortie, en HTTPS 443.
• Client et session host utilisent TLS 1.2 minimum vers l'infrastructure AVD ; la session RDP elle-même est protégée par un TLS imbriqué (jusqu'à TLS 1.3). Le certificat RDP du session host est auto-généré ; un certificat émis par une autorité de certification n'est pas pris en charge.
• Ce transport TCP s'appelle reverse connect : c'est toujours le premier transport, puis RDP Shortpath tente de passer en UDP (section 5).
• Le TCP sur 443 souffre de la perte de paquets et de la latence : c'est pour cela que l'UDP (Shortpath) est recommandé.

3. Évaluer la capacité et la vitesse du réseau#

3.1 La latence d'abord#

La latence (round-trip time, RTT) entre le client et la région Azure des session hosts (pas celle des metadata) pèse plus que la bande passante sur le ressenti.

Outils pour estimer avant de déployer :

• les Azure network round-trip latency statistics (latences médianes entre régions Azure publiées par Microsoft), à revoir tous les deux ou trois mois selon Microsoft ;
• l'Azure Virtual Desktop Experience Estimator (azure.microsoft.com/services/virtual-desktop/assessment/) : il mesure le RTT du poste vers chaque région et met en avant la plus proche. Il reste dans le module de formation officiel AZ-140 et le Cloud Adoption Framework (réponse attendue à l'examen), mais la page ne répondait pas le 22/10/2026 ;
• un pilote avec AVD Insights (section 9), qui donne le RTT réel par utilisateur et par gateway.

Règle de placement : session hosts dans la région la plus proche des utilisateurs, et proches des données qu'ils utilisent (serveurs de fichiers, bases, applications métier). Une application client-serveur bavarde doit rester près de son serveur, quitte à éloigner un peu l'utilisateur.

3.2 La bande passante#

Repères Microsoft (Network guidelines), pour un réseau à moins de 0,1 % de pertes, quel que soit le nombre de sessions par VM :

Consommation mesurée par scénario, un écran 1920 × 1080 (RDP bandwidth requirements) :

Ce qu'il faut comprendre :

• RDP adapte son débit (dynamic bandwidth allocation) : il compresse plus fort quand le réseau manque, il consomme ce qui est libre sinon. Une mesure isolée ne dit donc pas « ce qu'il faut », seulement « ce qui a été pris ».
• La charge dépend de l'image (nombre d'images par seconde, résolution, nombre d'écrans), pas du nombre de sessions par VM. Pour mémoire, un flux 1080p à 30 Hz non compressé représenterait environ 237 Mbit/s.
• Visioconférence, temps réel et vidéo 4K changent les besoins : tester avec un outil de charge (Login VSI ou équivalent) et la redirection multimédia et Teams (voir chapitre 07).
• Le dimensionnement se fait par site : nombre d'utilisateurs simultanés × profil de charge, comparé au lien Internet ou ExpressRoute du site, avec une marge pour les pics.

Exemple : 200 utilisateurs simultanés d'un site, profil Medium (3 Mbit/s) → environ 600 Mbit/s à prévoir au pic sur le lien du site, à corriger ensuite avec les mesures réelles (WVDConnectionNetworkData, section 9).

4. Concevoir le réseau des session hosts#

4.1 Les règles de conception#

4.2 Les URL et ports à autoriser en sortie#

Microsoft ne prend pas en charge un déploiement où ces adresses sont bloquées. Liste principale pour les session hosts (Azure public, tout en sortie) :

Pour les postes clients, la liste reprend les FQDN du service (*.wvd.microsoft.com, *.service.windows.cloud.microsoft, *.windows.cloud.microsoft, *.windows.static.microsoft), login.microsoftonline.com, 51.5.0.0/16 UDP 3478, *.servicebus.windows.net (données de dépannage), windows.cloud.microsoft et ecs.office.com (connection center), graph.microsoft.com, windows365.microsoft.com, go.microsoft.com, aka.ms, *.cdn.office.net (mises à jour du client Windows) et les URL de certificats en TCP 80. La liste complète, à jour, est dans Required FQDNs and endpoints.

Points d'examen :

• Les adresses 169.254.169.254 et 168.63.129.16 ne doivent ni passer par un proxy ni être interceptées.
• Le caractère générique est obligatoire pour le trafic du service ; pour le trafic de l'agent, on peut lister les FQDN régionaux exacts : Event Viewer > Windows Logs > Application > WVD-Agent, événement 3701, à refaire par région.
• AVD n'a pas de liste d'IP à autoriser à la place des FQDN : utiliser le service tag WindowsVirtualDesktop (NSG, Azure Firewall, UDR) et le FQDN tag WindowsVirtualDesktop (règles d'application Azure Firewall) ; un NGFW tiers a besoin d'une liste dynamique des IP Azure.
• Vérifier depuis un session host avec l'Azure Virtual Desktop Agent URL Tool (WVDAgentUrlTool.exe, livré avec l'agent, section 9). Il ne teste pas les caractères génériques : les autoriser avant.
• Les URL de Microsoft Entra ID, Office 365 et Windows Update ne sont pas dans cette liste : les ajouter selon les besoins.

4.3 Azure Firewall, proxy et routes#

Le détail des règles (NSG sortants, Firewall Policy, IP Groups, DNS proxy) est au chapitre 05 et dans SC-500 06. Pour la conception :

4.4 IaC : les règles de sortie dans un NSG#

Exemple Terraform (provider azurerm 5.x) de règles NSG sortantes par service tag pour le subnet des session hosts :

# Sortie vers le service AVD : TCP 443 et relais TURN UDP 3478 (51.5.0.0/16 fait partie du service tag)
resource "azurerm_network_security_rule" "avd_service" {
  name                        = "allow-avd-service-out"
  priority                    = 100
  direction                   = "Outbound"
  access                      = "Allow"
  protocol                    = "*" # Tcp pour 443, Udp pour 3478 : une règle par protocole si l'on veut être strict
  source_port_range           = "*"
  destination_port_ranges     = ["443", "3478"]
  source_address_prefix       = "VirtualNetwork"
  destination_address_prefix  = "WindowsVirtualDesktop"
  resource_group_name         = azurerm_resource_group.network.name
  network_security_group_name = azurerm_network_security_group.sessionhosts.name
}

Ajouter de la même façon AzureActiveDirectory (443), AzureMonitor (443), AzureFrontDoor.Frontend (443), Storage (443) et Internet en TCP 1688 pour le KMS (ou par FQDN sur le pare-feu, un NSG ne filtrant pas par FQDN).

5. RDP Shortpath#

5.1 Le principe#

RDP Shortpath établit un transport UDP direct (ou relayé) entre le client et le session host, en complément du reverse connect. Il utilise URCP (Universal Rate Control Protocol) pour adapter le débit : moins de latence, meilleure tenue à la perte de paquets que le TCP. La connexion commence toujours en TCP reverse connect, puis le client et le session host cherchent un chemin UDP ; si un chemin réussit, le reverse connect est abandonné et tous les canaux (affichage, saisie, redirections) passent en UDP. La sécurité est la même (TLS sur UDP fiable, certificat du session host).

5.2 Les quatre options#

Ce qu'il faut savoir :

• Les options publiques (STUN, TURN) fonctionnent sans configuration si les pare-feu laissent passer l'UDP et que les réglages de transport RDP de Windows sont aux valeurs par défaut.
• Quand le réseau managé et le réseau public sont possibles, c'est le premier chemin trouvé qui gagne pour la session.
• Les relais TURN sont dans 39 régions Azure et le relais est choisi selon la position du client ; un client loin de tout relais peut retomber en TCP. La plage 51.5.0.0/16 est dédiée à AVD et Windows 365 (elle remplace l'ancienne 20.202.0.0/16 partagée avec Azure Communication Services). Azure Government utilise 20.140.236.0/22.
• Une connexion TURN peut être coupée pendant une mise à jour des relais : le client se reconnecte en quelques secondes.
• Chaque session prend un port UDP dans la plage éphémère 49152 à 65535 (le port 65330 est réservé à Azure). On peut la réduire par la stratégie Use port range for RDP Shortpath for unmanaged networks (plage autorisée de 1024 à 49151 ; valeurs par défaut : port de base 38300, 1000 ports).

flowchart TD
    A["Connexion : TCP reverse connect, toujours d'abord"] --> B{"Client et host sur un réseau privé ?<br/>ExpressRoute ou VPN"}
    B -- "Oui, listener 3390 ouvert" --> M1["UDP (Private Network)<br/>Shortpath managed"]
    B -- "Oui, sans listener" --> M2["UDP direct via ICE/STUN"]
    B -- Non --> C{"UDP sortant autorisé ?"}
    C -- Non --> T["Reste en TCP 443"]
    C -- Oui --> D{"NAT cone ?"}
    D -- Oui --> S["UDP direct, STUN"]
    D -- "Non, NAT symétrique" --> R["UDP (Relay), TURN 51.5.0.0/16:3478"]

5.3 Activer et régler : la configuration à deux niveaux#

1. Host pool : onglet Networking > RDP Shortpath du host pool, un réglage par option (Default, Enabled, Disabled ; Default = choix de Microsoft, aujourd'hui Enabled pour les quatre).
2. Session host et client : stratégies Windows (Intune ou GPO). Le plus restrictif des deux niveaux s'applique : désactiver l'UDP sur le session host l'emporte sur un host pool en Enabled.

PowerShell (module Az.DesktopVirtualization 5.2.1-preview, qui ajoute ces paramètres) :

# Lire les réglages RDP Shortpath du host pool
$hp = @{ HostPoolName = 'hp-avd-lab'; ResourceGroupName = 'rg-avd-lab-service' }
Get-AzWvdHostPool @hp | Format-List ManagedPrivateUdp, DirectUdp, PublicUdp, RelayUdp

# Garder Shortpath managed (Default), couper tout ce qui passe par STUN ou TURN
Update-AzWvdHostPool -Name 'hp-avd-lab' -ResourceGroupName 'rg-avd-lab-service' `
    -ManagedPrivateUdp Default -DirectUdp Disabled -PublicUdp Disabled -RelayUdp Disabled

En Bicep, ces propriétés n'existent que dans les versions d'API preview de Microsoft.DesktopVirtualization/hostPools (depuis 2025-11-01-preview, dernière 2026-04-01-preview) ; la version GA 2025-10-10 les a retirées :

// Host pool existant : on ne change que les options RDP Shortpath (API preview requise)
resource hostPool 'Microsoft.DesktopVirtualization/hostPools@2026-01-01-preview' = {
  name: 'hp-avd-lab'
  location: location
  properties: {
    hostPoolType: 'Pooled'
    loadBalancerType: 'BreadthFirst'
    preferredAppGroupType: 'Desktop'
    managedPrivateUDP: 'Enabled'
    directUDP: 'Enabled'
    publicUDP: 'Enabled'
    relayUDP: 'Enabled'
  }
}

Le provider Terraform azurerm (5.10.0, API GA 2025-10-10) n'expose pas ces réglages sur azurerm_virtual_desktop_host_pool : passer par Bicep, PowerShell ou le portail.

RDP Shortpath for managed networks demande en plus, sur les session hosts :

• la stratégie Enable RDP Shortpath for managed networks (Intune Settings catalog ou GPO des modèles d'administration AVD), qui ouvre le listener UDP 3390 ;
• une règle entrante UDP 3390 dans le pare-feu Windows et dans le NSG, depuis les plages des clients uniquement.

Recommandations Microsoft pour maximiser le taux de réussite UDP :

• éviter le tunnel forcé, le double NAT et le CGN (carrier-grade NAT), les équipements d'inspection de paquets et les VPN sur TCP (un VPN qui encapsule en TCP détruit l'intérêt de l'UDP) ;
• activer IPv6 ou Teredo (Set-NetTeredoConfiguration -Type Enterpriseclient sur hosts et clients, puis redémarrage) : plus de candidats ICE ;
• autoriser UPnP sur les box domestiques ;
• prévoir le TURN quand la sortie des session hosts passe par Azure Firewall ou NAT Gateway (NAT symétrique).

5.4 Désactiver ou vérifier#

• Désactiver l'UDP côté session host : stratégie Connections > Select RDP transport protocols = Use only TCP (HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services, SelectTransport = 1 ; 2 = UDP ou TCP). Côté client : Remote Desktop Connection Client > Turn Off UDP On Client (...\Terminal Services\Client, fClientDisableUDP = 1). Une de ces valeurs oubliée dans une image ou une GPO explique beaucoup de sessions « bloquées » en TCP.
• Couper un seul chemin sur le session host : stratégies Azure Virtual Desktop > RDP Shortpath (managed networks using NAT traversal, public networks using NAT traversal, public networks using Relay (TURN)) ; Microsoft conseille de garder TURN sauf pour un dépannage.
• Vérifier : barre de connexion du client (Connection Information), événement 135 sur le session host, colonne UdpUse de WVDConnections (section 9).

6. RDP Multipath#

RDP Multipath garde plusieurs chemins ouverts pour une même session et bascule sur le meilleur si le chemin actif se dégrade, sans couper la session :

• plusieurs chemins UDP découverts par ICE (STUN et TURN), dont un actif et des chemins de secours ;
• des chemins TCP reverse connect redondants (établis par Rendezvous) ;
• si tous les chemins tombent (panne réseau), le client tente de se reconnecter quand le réseau revient.

La plage 40.64.144.0/20 ne couvre que la connexion RDP TCP : elle sert aux règles de contournement (VPN, proxy) ; le reste de *.wvd.microsoft.com doit rester autorisé par FQDN.

7. Quality of Service (QoS)#

La QoS donne la priorité aux paquets RDP dans les files des routeurs : moins de gigue, de pertes et de latence quand les liens sont chargés. Microsoft conseille de mettre en place la QoS d'abord, puis d'ajouter de la bande passante seulement là où il en manque.

# Sur chaque session host (ou en script d'image) : marquer RDP Shortpath for managed networks en DSCP 46
New-NetQosPolicy -Name "RDP Shortpath for managed networks" -AppPathNameMatchCondition "svchost.exe" `
    -IPProtocolMatchCondition UDP -IPSrcPortStartMatchCondition 3390 -IPSrcPortEndMatchCondition 3390 `
    -DSCPAction 46 -NetworkProfile All

Avec une GPO sur l'OU des session hosts, appliquer par gpupdate /force. La même mécanique permet de limiter le débit sortant (Specify Outbound Throttle Rate, -ThrottleRateActionBitsPerSecond), là encore pour Shortpath managed uniquement.

8. Private Link pour Azure Virtual Desktop#

8.1 Trois sub-resources, trois rôles#

Règles qui tombent à l'examen :

• Le private endpoint global se pose sur un workspace dédié, sans application group : il porte le FQDN partagé de découverte pour tous les workspaces. Supprimer ce workspace casse la découverte des feeds. Il reste toujours joignable en public : régler son accès sur « privé » est ignoré.
• Avant septembre 2023, le global partageait la zone privatelink.wvd.microsoft.com : ce montage n'est plus pris en charge, il faut un endpoint global avec la zone privatelink-global.wvd.microsoft.com.
• Vers le private endpoint connection, ne filtrer aucun port : toute la plage TCP 1 à 65535 est nécessaire (une seule IP sert de façade, par mappage de ports, à toutes les gateways).
• Prévoir de la place dans le subnet : Microsoft peut ajouter des adresses aux private endpoints lors des extensions de capacité.

8.2 Les quatre scénarios#

8.3 Public network access : qui peut passer par Internet#

Attention au piège du nom : EnabledForSessionHostsOnly signifie que les session hosts gardent l'accès public, donc que ce sont les clients qui doivent passer par le privé.

8.4 Mise en œuvre, dans l'ordre#

1. Réinscrire le resource provider Microsoft.DesktopVirtualization sur chaque abonnement concerné (portail : Subscriptions > Resource providers > Re-register).
2. Créer le private endpoint connection sur chaque host pool, feed sur chaque workspace, et éventuellement global sur un workspace vide dédié ; intégrer les zones DNS privées (ou les zones de votre DNS, avec des redirecteurs conditionnels depuis le site, par exemple via Azure DNS Private Resolver).
3. Régler public network access des workspaces et host pools.
4. Redémarrer le service RDAgentBootLoader (ou la VM) sur chaque session host du host pool : obligatoire après l'ajout d'un private endpoint et après tout changement de configuration réseau du host pool. Les sessions en cours ne sont pas affectées.
5. Fermer les routes publiques : retirer des NSG ou d'Azure Firewall l'autorisation sortante vers le service tag WindowsVirtualDesktop (garder les autres URL requises).
6. Valider : connexion depuis un client sur le réseau privé, résolution DNS des FQDN AVD vers les IP privées.

# Private endpoint "connection" pour un host pool (Az.Network) - valeurs de lab
$hostPool = Get-AzWvdHostPool -Name 'hp-avd-lab' -ResourceGroupName 'rg-avd-lab-service'
$subnet   = Get-AzVirtualNetwork -Name 'vnet-avd-lab' -ResourceGroupName 'rg-avd-lab-network' |
            Get-AzVirtualNetworkSubnetConfig -Name 'snet-privateendpoints'
$plsc = New-AzPrivateLinkServiceConnection -Name 'pe-hp-avd-lab-connection' `
            -PrivateLinkServiceId $hostPool.Id -GroupId 'connection'
New-AzPrivateEndpoint -Name 'pe-hp-avd-lab' -ResourceGroupName 'rg-avd-lab-network' -Location $hostPool.Location `
    -Subnet $subnet -PrivateLinkServiceConnection $plsc

# Utilisateurs en privé, session hosts encore en public pendant la transition
Update-AzWvdHostPool -Name 'hp-avd-lab' -ResourceGroupName 'rg-avd-lab-service' -PublicNetworkAccess EnabledForSessionHostsOnly

# Feed uniquement en privé
Update-AzWvdWorkspace -Name 'ws-avd-lab' -ResourceGroupName 'rg-avd-lab-service' -PublicNetworkAccess Disabled

# Même private endpoint avec Azure CLI (sub-resources : connection, feed ou global)
az network private-endpoint create --name pe-hp-avd-lab --resource-group rg-avd-lab-network \
  --vnet-name vnet-avd-lab --subnet snet-privateendpoints \
  --private-connection-resource-id "{hostPoolResourceId}" --group-id connection \
  --connection-name pe-hp-avd-lab-connection

# Terraform (azurerm 5.10.0) : accès public et private endpoint "connection"
resource "azurerm_virtual_desktop_host_pool" "lab" {
  name                  = "hp-avd-lab"
  location              = azurerm_resource_group.service.location
  resource_group_name   = azurerm_resource_group.service.name
  type                  = "Pooled"
  load_balancer_type    = "BreadthFirst"
  public_network_access = "EnabledForSessionHostsOnly" # Enabled, Disabled, EnabledForClientsOnly, EnabledForSessionHostsOnly
}

resource "azurerm_virtual_desktop_workspace" "lab" {
  name                          = "ws-avd-lab"
  location                      = azurerm_resource_group.service.location
  resource_group_name           = azurerm_resource_group.service.name
  public_network_access_enabled = false # feed accessible seulement par le private endpoint "feed"
}

resource "azurerm_private_endpoint" "hostpool_connection" {
  name                = "pe-hp-avd-lab"
  location            = azurerm_resource_group.network.location
  resource_group_name = azurerm_resource_group.network.name
  subnet_id           = azurerm_subnet.private_endpoints.id

  private_service_connection {
    name                           = "pe-hp-avd-lab-connection"
    private_connection_resource_id = azurerm_virtual_desktop_host_pool.lab.id
    subresource_names              = ["connection"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "avd"
    private_dns_zone_ids = [azurerm_private_dns_zone.wvd.id] # zone privatelink.wvd.microsoft.com
  }
}

8.5 UDP avec Private Link#

Par défaut, l'UDP est bloqué sur Private Link. Pour garder RDP Shortpath :

• cocher Allow Direct UDP network path over Private Link (page Networking du host pool ou du workspace ; propriété allowRDPShortPathWithPrivateLink dans les API preview) : l'opt-in devient obligatoire ;
• désactiver RDP Shortpath for public networks (STUN et TURN) : non pris en charge avec Private Link, le portail bloque l'enregistrement sinon ;
• garder RDP Shortpath for managed networks (avec ou sans ICE/STUN).

8.6 Limites connues#

• Avec l'ancien Remote Desktop client pour Windows sur un réseau privé sans accès Internet, un utilisateur abonné à la fois à des feeds publics et privés ne peut pas accéder à son feed.
• Private Link ne fonctionne qu'après la réinscription du resource provider sur l'abonnement.
• Le workspace de découverte globale ne se protège pas : la sécurité vient de l'authentification Entra ID et du Conditional Access (chapitre 05).

9. Surveiller et dépanner la connectivité réseau#

9.1 La méthode#

flowchart LR
    A["Session host Unavailable<br/>ou connexion refusée"] --> B["WVDAgentUrlTool.exe<br/>événements 3703, 3019"]
    C["Session lente<br/>ou saccadée"] --> D{"UDP ou TCP ?<br/>UdpUse, Connection Information"}
    D -- TCP --> E["avdnettest.exe, NSG, pare-feu, NAT,<br/>SelectTransport, fClientDisableUDP"]
    D -- UDP --> F{"RTT sous 150 ms ?"}
    F -- Non --> G["Région trop loin, tunnel forcé,<br/>VPN, proxy"]
    F -- Oui --> H["Bande passante, pertes,<br/>CPU et mémoire du host"]

9.2 Les outils, par niveau#

Les données arrivent dans Log Analytics avec un délai pouvant aller jusqu'à 15 minutes. Les tables WVDConnectionNetworkData et les autres ne sont remplies que si les diagnostic settings du host pool envoient les catégories voulues (allLogs ou au moins Connection et Network Data Logs) vers le workspace Log Analytics (chapitre 08).

9.3 Requêtes KQL utiles#

// Répartition des connexions par transport sur 24 h (1 = managed, 2 = STUN, 4 = TURN, autre = TCP)
WVDConnections
| where TimeGenerated > ago(1d) and State == "Connected"
| summarize Connexions = count() by UdpUse

// RTT et bande passante moyens par utilisateur sur 7 jours
WVDConnectionNetworkData
| where TimeGenerated > ago(7d)
| join kind=inner (
    WVDConnections
    | where State == "Connected"
    | project CorrelationId, UserName, SessionHostName
  ) on CorrelationId
| summarize RttMoyenMs = avg(EstRoundTripTimeInMs), BandePassanteMoyenneKBps = avg(EstAvailableBandwidthKBps)
    by UserName
| order by RttMoyenMs desc

// Sessions qui ont tenté ou obtenu RDP Shortpath
WVDCheckpoints
| where TimeGenerated > ago(1d)
| where Name contains "Shortpath"

9.4 Symptômes fréquents#

10. Labs conseillés#

Dans un abonnement de test et un tenant de test, avec un host pool pooled d'une ou deux VM du chapitre 03 et un workspace Log Analytics. Coût : les VM (quelques heures), plus, selon le lab, une VPN gateway, un Azure Firewall ou des private endpoints, facturés à l'heure : rien de cher si tout est supprimé le jour même. Nettoyage : supprimer les resource groups rg-avd-lab-* à la fin de chaque lab (VPN gateway et Azure Firewall d'abord : ce sont les plus chers).

Lab 1. Vérifier les URL et le reverse connect.

1. Sur un session host, lancer WVDAgentUrlTool.exe depuis le dossier de l'agent ; noter les FQDN de l'événement 3701.
2. Ajouter au NSG du subnet une règle sortante Deny vers le service tag WindowsVirtualDesktop (priorité haute), attendre quelques minutes.
3. Résultat attendu : le session host passe Unavailable, événement 3703 ou 3019 ; supprimer la règle, il revient Available. Constater qu'aucune règle entrante n'a jamais été nécessaire.

Lab 2. RDP Shortpath public : STUN, TURN, TCP.

1. Depuis un poste à domicile, se connecter avec Windows App ; lire Connection Information (UDP attendu).
2. Lancer avdnettest.exe sur le client et sur le session host ; noter le type de NAT.
3. Sur le host pool, passer PublicUdp à Disabled (garder RelayUdp) : reconnecter, le transport devient UDP (Relay) ; passer aussi RelayUdp à Disabled : TCP.
4. Résultat attendu : WVDConnections montre UdpUse 2, puis 4, puis 0 ; remettre les options à Default.

Lab 3. Mesurer la latence et la bande passante.

1. Activer les diagnostic settings du host pool (allLogs) vers Log Analytics.
2. Jouer une vidéo plein écran dans la session pendant 10 minutes, puis travailler sur un document.
3. Résultat attendu : WVDConnectionNetworkData montre la bande passante qui varie (RDP s'adapte) ; AVD Insights > Connection Performance montre le RTT par région de gateway.

Lab 4 (option, plus cher). Private Link.

1. Réinscrire Microsoft.DesktopVirtualization, créer un private endpoint connection sur le host pool et feed sur le workspace, zones DNS privées liées au VNet ; un client de test dans le VNet (ou joint en point-to-site VPN).
2. Régler le host pool en Disabled et le workspace en Disabled ; redémarrer RDAgentBootLoader sur les session hosts.
3. Résultat attendu : la connexion fonctionne depuis le réseau privé et échoue depuis Internet ; nslookup d'un FQDN AVD renvoie une IP privée. Remettre Enabled avant de supprimer les private endpoints.

11. Les pièges d'examen#

12. Scénarios d'entraînement#

1. Contoso déploie AVD dans un spoke dont la sortie Internet passe par Azure Firewall. Les session hosts restent Unavailable après la création du host pool. L'équipe réseau a autorisé login.microsoftonline.com et *.wvd.microsoft.com par règles réseau. Quelles sont les deux vérifications prioritaires ?

Lancer l'Azure Virtual Desktop Agent URL Tool sur un session host pour voir les URL bloquées, et remplacer les règles par une règle d'application avec le FQDN tag WindowsVirtualDesktop (les règles réseau par FQDN exigent le DNS proxy du pare-feu). Ajouter aussi les autres URL requises (Azure Monitor, KMS 1688, certificats en 80, 169.254.169.254 et 168.63.129.16 sans proxy).

2. Des utilisateurs en télétravail se plaignent de saccades. WVDConnections montre UdpUse à 0 pour toutes leurs sessions. La sortie des session hosts passe par une NAT Gateway. Que faire ?

Les sessions sont en TCP. La NAT Gateway fait du NAT symétrique : STUN ne marche pas, il faut TURN. Autoriser en sortie 51.5.0.0/16 en UDP 3478 (NSG, pare-feu), vérifier que RelayUdp n'est pas désactivé sur le host pool et que SelectTransport n'impose pas TCP. Tester avec avdnettest.exe.

3. Fabrikam relie ses bureaux à Azure par ExpressRoute et veut la meilleure qualité pour les postes du siège, avec une priorité réseau garantie. Quelle combinaison ?

RDP Shortpath for managed networks (listener UDP 3390 activé par Intune ou GPO, règle entrante UDP 3390 depuis les plages des bureaux) et une QoS DSCP 46 sur les session hosts (New-NetQosPolicy sur svchost.exe, UDP, port source 3390), respectée par chaque routeur du chemin.

4. La sécurité refuse toute règle entrante sur les session hosts, mais veut garder l'UDP sur le réseau ExpressRoute. Quelle option ?

RDP Shortpath for managed networks with ICE/STUN : UDP direct sur le réseau privé, ports dynamiques négociés, sans listener ni port entrant (option DirectUdp).

5. Une banque exige qu'aucune connexion d'utilisateur ne passe par Internet ; la découverte des feeds peut rester publique. Quels private endpoints et quels réglages ?

Private endpoints feed sur chaque workspace et connection sur chaque host pool (scénario 2), zone DNS privatelink.wvd.microsoft.com ; workspaces en PublicNetworkAccess Disabled, host pools en Disabled (ou EnabledForSessionHostsOnly si les hosts doivent encore sortir en public) ; réinscrire le resource provider, redémarrer RDAgentBootLoader.

6. Même banque : elle veut aussi la découverte initiale en privé et crée un private endpoint global par workspace. Que répondre ?

Il n'en faut qu'un seul pour tout le déploiement, sur un workspace dédié sans application group, avec la zone privatelink-global.wvd.microsoft.com. Ce workspace reste joignable en public (réglage ignoré) et ne doit jamais être supprimé.

7. Après la mise en place de Private Link, RDP Shortpath ne fonctionne plus ; les sessions sont en TCP. Que faut-il activer ou changer ?

Cocher Allow Direct UDP network path over Private Link sur le host pool et désactiver les options STUN et TURN (non prises en charge avec Private Link) ; garder RDP Shortpath for managed networks.

8. Une entreprise répartit ses utilisateurs entre Paris et Singapour et place tous les session hosts en West Europe. Les utilisateurs de Singapour se plaignent. Comment le démontrer, puis corriger ?

AVD Insights > Connection Performance et WVDConnectionNetworkData montrent un RTT au-delà de 150 à 200 ms pour Singapour. Créer un host pool dans une région proche (Southeast Asia), avec profils et données au plus près (chapitre 08 pour le multi-région).

9. Les sessions tombent plusieurs fois par jour, toujours quelques secondes, pour des utilisateurs en Wi-Fi instable. Que proposer sans changer le réseau ?

RDP Multipath : déployer Windows App 2.0.1069.0 ou plus (UDP multiples et TCP redondant) ; Shortpath doit fonctionner. Prévoir jusqu'à 3 ports UDP + 2 TCP par session dans le NAT et le pare-feu. Suivre l'effet dans Connection Reliability.

10. Un architecte doit dimensionner le lien Internet d'un site de 300 utilisateurs simultanés, profil Medium, écrans 1080p. Quelle estimation de départ et comment l'affiner ?

Repère Microsoft Medium = 3 Mbit/s par utilisateur → environ 900 Mbit/s au pic ; affiner par un pilote : mesures WVDConnectionNetworkData, usages réels (vidéo, Teams optimisé ou non), puis QoS si lien privé.

13. Pour aller plus loin (au-delà de l'examen)#

• Microsoft Entra Private Access ou un SASE tiers devant AVD : attention au double NAT et au trafic UDP ; utiliser la plage 40.64.144.0/20 et 51.5.0.0/16 pour les règles de contournement.
• Windows 365 : mêmes flux réseau (reverse connect, Shortpath, Multipath) ; la documentation Windows 365 Understanding network flows résume très bien les cinq méthodes RDP.
• AVD landing zone accelerator (github.com/Azure/avdaccelerator) : réseau spoke, private endpoints et DNS déjà câblés.
• Azure Virtual Network Manager pour imposer des règles d'administration de sécurité sur tous les spokes AVD (SC-500 06).
• RDP Shortpath et IPv6 : les candidats IPv6 augmentent nettement le taux de réussite UDP en réseau public.

14. Fiche à retenir#

• Plan de contrôle géré par Microsoft : web (Traffic Manager), broker, gateway (Azure Front Door), diagnostics ; bascule automatique ; vous gérez hosts, réseau, identité, profils, applications, postes.
• Reverse connect : client et session host sortent en 443 vers la même gateway ; aucun port entrant ; TLS 1.2 minimum, TLS imbriqué pour la session ; toujours le premier transport.
• AVD = multi-session, RemoteApp, coût à l'usage ; Windows 365 = Cloud PC par utilisateur, prix fixe, Intune, connectivité AVD ; RDS = rôles à déployer soi-même ; AVD classic retiré le 30/09/2026.
• RTT : < 150 ms recommandé, < 100 ms idéal, > 200 ms dégradé, 20 ms pour les technologies d'assistance.
• Bande passante : Light 1,5, Medium 3, Heavy 5, Power 15 Mbit/s ; 1080p à 30 i/s = 5 Mbit/s ; RDP s'adapte.
• URL : login.microsoftonline.com, *.wvd.microsoft.com (service tag et FQDN tag WindowsVirtualDesktop), 51.5.0.0/16 UDP 3478, Azure Monitor, KMS 1688, certificats en 80, 169.254.169.254 et 168.63.129.16 sans proxy.
• WVDAgentUrlTool.exe (ne teste pas les caractères génériques) ; événements 3701 (FQDN de l'agent), 3703, 3019.
• Azure Firewall : FQDN tag, DNS proxy, IP Groups, pas d'inspection TLS, UDR WindowsVirtualDesktop → Internet contre les coupures au scale-in.
• RDP Shortpath : managed (UDP 3390, listener + port entrant), managed ICE/STUN, public STUN, public TURN ; NAT symétrique (Azure Firewall, NAT Gateway) → TURN ; premier chemin trouvé ; ports 49152-65535 (65330 réservé).
• Réglages du host pool ManagedPrivateUdp, DirectUdp, PublicUdp, RelayUdp (Default = Enabled) ; le plus restrictif gagne avec la stratégie du host ; Az.DesktopVirtualization 5.2.1-preview, API Bicep preview, pas dans Terraform.
• RDP Multipath : automatique, GA, Windows App 2.0.559 (UDP) / 2.0.1069 (TCP redondant) ; 3 UDP + 2 TCP par session ; vérification barre de connexion et Connection Reliability.
• QoS : Shortpath managed seulement ; DSCP 46 (EF) ; svchost.exe, UDP, port source 3390 ; de bout en bout.
• Private Link : global (un seul, workspace vide, privatelink-global.wvd.microsoft.com, toujours public), feed (par workspace), connection (par host pool, privatelink.wvd.microsoft.com, TCP 1-65535).
• Public network access : workspace Enabled/Disabled ; host pool Enabled, Disabled, EnabledForSessionHostsOnly, EnabledForClientsOnly ; réinscrire le resource provider ; redémarrer RDAgentBootLoader.
• UDP sur Private Link : opt-in Allow Direct UDP network path over Private Link, sans STUN ni TURN.
• Dépannage : Connection Information (UDP, UDP (Private Network), UDP (Relay)), événement 135, avdnettest.exe, WVDConnections.UdpUse 1 / 2 / 4, WVDConnectionNetworkData (RTT, bande passante, 2 min), WVDCheckpoints, AVD Insights, jusqu'à 15 minutes de délai.

Références#

Toutes lues le 22/10/2026 sur Microsoft Learn, sauf mention :

• Guide d'étude de l'examen AZ-140
• What is Azure Virtual Desktop?
• Azure Virtual Desktop service architecture and resilience
• Security recommendations for Azure Virtual Desktop (shared responsibility)
• What is Windows 365 Enterprise?
• Windows 365 architecture
• Understanding Azure Virtual Desktop network connectivity
• Required FQDNs and endpoints for Azure Virtual Desktop
• Check access to required FQDNs and endpoints (Agent URL Tool)
• Proxy server guidelines for Azure Virtual Desktop
• Use Azure Firewall to protect Azure Virtual Desktop deployments
• Network topology and connectivity for Azure Virtual Desktop (Cloud Adoption Framework)
• Network guidelines (Remote Desktop Services)
• Remote Desktop Protocol bandwidth requirements
• Azure network round-trip latency statistics
• RDP Shortpath for Azure Virtual Desktop
• Configure RDP Shortpath for Azure Virtual Desktop
• Troubleshoot RDP Shortpath for public networks
• Use RDP Multipath to improve connection reliability
• Understanding network flows - Remote Desktop Protocol (Windows 365)
• Implement Quality of Service (QoS) for Azure Virtual Desktop
• Azure Private Link with Azure Virtual Desktop
• Set up Private Link with Azure Virtual Desktop
• Troubleshoot connection quality in Azure Virtual Desktop
• Analyze connection quality in Azure Virtual Desktop
• Connection quality monitoring (WVDConnectionNetworkData)
• Azure Virtual Desktop Insights use cases (connection performance, reliability)
• Troubleshoot the Azure Virtual Desktop agent (événements 3703, 3019)
• Microsoft.DesktopVirtualization hostPools (Bicep, ARM) et journal des versions d'API
• Module Az.DesktopVirtualization : Update-AzWvdHostPool
• Registre Terraform, provider hashicorp/azurerm 5.10.0 : azurerm_virtual_desktop_host_pool, azurerm_virtual_desktop_workspace, azurerm_private_endpoint
• Azure Virtual Desktop Experience Estimator (module de formation officiel) ; l'outil lui-même (azure.microsoft.com/services/virtual-desktop/assessment/) renvoyait une erreur 503 le 22/10/2026.