Sur deux hôtes RDS Windows Server 2022 récents, des groupes d’utilisateurs sont brutalement éjectés plusieurs fois par jour ; cet article propose un plan d’investigation et de remédiation exhaustif pour éliminer ces coupures RDP synchrones et préserver la continuité de service.
Déconnexions RDP aléatoires sur deux serveurs Terminal Server Windows Server 2022
Vue d’ensemble de la question
Dans un environnement de production virtualisé, deux machines Windows Server 2022 Datacenter (20 vCPU, 48 Go RAM, charge < 50 %) hébergent le rôle Remote Desktop Session Host. Le trafic RDP est distribué via deux appliances Kemp LoadMaster configurées en haute disponibilité. Malgré de bonnes performances globales, les utilisateurs font état de 1 à 4 déconnexions quotidiennes : à chaque occurrence, trois à quatre sessions se ferment exactement à la même seconde tandis que les autres demeurent actives.
Les journaux Microsoft‑Windows‑TerminalServices‑LocalSessionManager/Operational enregistrent systématiquement l’évènement ID 40 – Session disconnect avec l’un des codes :
- 0x80070079 (2147942521) – The semaphore timeout period has expired.
- 0x80070040 (2147942464) – The specified network name is no longer available.
Ces erreurs pointent vers une perte momentanée de connectivité entre le client et le serveur ou vers une réinitialisation côté intermédiaires réseau.
Synthèse des solutions et pistes proposées
| Domaine | Actions proposées | But recherché |
|---|---|---|
| Réseau & Load Balancer | • Surveiller latence, gigue et pertes (Wireshark, PRTG, NetFlow). • Examiner journaux Kemp (bascules HA, flapping VIP, health‑checks). • Tester sans LoadMaster (connexion directe au nœud) pour isoler la cause. • Vérifier timeout TCP/UDP et persistance de session sur les VIP. | Déterminer si l’instabilité provient de l’équilibreur ou du réseau amont. |
| Serveurs RDP | • Appliquer tous les CU/SSU Microsoft et pilotes NIC/VMware actuels. • Activer Keep‑Alive RDP ( HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\KeepAliveTimeout).• Désactiver LSO, RSS, GSO, Energy Efficient Ethernet sur les vNIC. • Vérifier qu’UDP 3389 (RDP ShortPath) n’est pas bloqué ou le désactiver si non géré. | Réduire les expirations de sémaphore et pertes de nom réseau. |
| Hyperviseur | • Contrôler CPU Ready / Co‑Stop, latence stockage, snapshots. • Aligner MTU/Jumbo Frames entre vSwitch, NIC physiques et LoadMaster. | Éliminer les micro‑coupures induites par la couche de virtualisation. |
| Journalisation & corrélation | • Activer logs « Analytic & Debug » de RdpCoreTS. • Exporter les ID 40 sur 24 h et les corréler aux logs réseau (horodatage exact). • Utiliser PerfMon : TCP Retransmissions/sec, RDP TCP Connections, UDP Errors/sec. | Mettre en évidence un motif temporel ou une saturation ponctuelle. |
| Tests ciblés | • Constituer un groupe pilote de 3 utilisateurs en connexion directe. • Mesurer taux de coupure sur 7 jours avec et sans équilibrage. • Simuler charge (15‑20 sessions) via Remote Desktop Load Simulation Tool. | Valider ou exclure chaque couche (serveur, réseau, load balancer). |
Analyse détaillée des codes d’erreur
0x80070079 indique un dépassement de temporisation au niveau du protocole de transport, souvent lié à une absence de réponse à un ACK TCP ou à des retransmissions excessives. Un ping -n 500 <VIP> permet parfois de visualiser la micro‑coupure :Reply from 10.x.x.x: bytes=32 time=1ms TTL=128
Request timed out.
Reply from 10.x.x.x: bytes=32 time=2ms TTL=128
0x80070040 apparaît lorsque la pile SMB/RDP ne parvient plus à résoudre le nom NetBIOS ou lorsque la connexion TCP est brutalement réinitialisée. Dans la majorité des cas rencontrés en environnement RDS, cela reflète un RST émis par un pare‑feu intermédiaire ou par le load balancer après expiration de son idle timeout.
Inspection réseau pas à pas
- Captures Wireshark côté client et serveur
Démarrer une capture filtréetcp.port == 3389 or udp.port == 3389. Lorsque la déconnexion survient :- si l’on observe un RST depuis l’adresse VIP : suspecter les réglages Kemp LoadMaster ;
- si l’on observe un trou de plusieurs secondes sans paquet entrant, suspecter une perte physique (Wi‑Fi, WAN MPLS, SD‑WAN).
- Analyse des journaux Kemp
Sur les modèles Kemp, le journal System Message File consigne toute bascule HA ou tout échec de health‑check. Rechercher la combinaison :[L7] Service 3389 down
[L7] Service 3389 up
Si un « down » précède de quelques secondes les ID 40, le coupable est identifié. - Validation hors Load Balancer
Modifier temporairement les enregistrements DNS pour faire pointer le FQDN vers l’une des IP privées des nœuds RDSH et demander aux utilisateurs pilotes de se reconnecter. Si aucune coupure n’est observée pendant 48 h, la responsabilité du LoadMaster est confirmée.
Optimisation de la configuration Kemp LoadMaster
Les versions antérieures à la 7.2.53 contiennent un correctif spécifique RDS. Si la mise à jour immédiate n’est pas envisageable, appliquez au minimum :
- Timeout TCP : 900 s (valeur par défaut = 660 s).
- Check Interval : 10 s / Failure Retries : 3, afin d’éviter un flapping excessif.
- Persistence : Source IP Affinity ou Layer 7 Persistence Mode = RDP Cookie.
- Scheduling Method : ne jamais utiliser Least Connections avec RDSH ; préférer Round Robin ou Fixed Weighting.
Dans la console Kemp, un trafic continu s’affichant à 0 octet/s sur la VIP pendant la coupure valide l’hypothèse d’une interruption upper‑layer et non d’un drop physique.
Paramètres Windows Server à durcir
- RDP Keep‑Alive
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v KeepAliveTimeout /t REG_DWORD /d 120000 /f
Redémarrer le service TermService ou le serveur. - Désactivation des offloads problématiques
Disable-NetAdapterChecksumOffload -Name "*"Disable-NetAdapterLso -Name "*" - Désactivation RDP ShortPath si non supporté
reg add "HKLM\SOFTWARE\Microsoft\Terminal Server Client" /v UDPTransport /t REG_DWORD /d 0 /f - Règle QoS DSCP 46 pour marquer le trafic RDP et éviter la mise en file d’attente surchargée.
Surveillance continue et tableaux de bord
Pour corréler automatiquement une déconnexion ID 40 et la couche réseau :
Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational';ID=40;StartTime=(Get-Date).AddHours(-24)} |
Select TimeCreated,UserId,SessionId | Export-Csv C:\Logs\RDP_Disconnects.csv -NoTypeAlimentez ensuite votre SIEM ou Grafana / Prometheus / PRTG avec :
- PerfMon collector set exporté en CSV (compteurs TCPv4\Segments Retransmitted/sec, ICMPv4\Outbound Packets Dropped).
- Flux NetFlow depuis les appliances Kemp vers un collecteur Elastiflow pour repérer toute reprise de handshake.
Plan d’action pas à pas
- J‑0 : Capturer l’évènement
Activer la journalisation étendue, synchroniser tous les serveurs sur la même source NTP et noter l’heure exacte (hh:mm:ss,fff). - J‑1 : Reproduire sans Load Balancer
Diriger 10 % des utilisateurs vers l’IP directe et comparer le nombre de coupures. - J‑2 : Ajuster les timeouts Kemp
Porter le Idle Connection Timeout à 900 s, appliquer la persistance source et redémarrer le service L7. - J‑3 : Mettre à jour firmwares / CU
Appliquer la dernière Monthly Rollup Windows Server 2022 et la version firmwares Kemp recommandée par le support. - J‑4 : Vérifier l’hôte
Auditer la latence disque (« Average Read/Write > 25 ms »), CPU ready, co‑stop et l’activation DRS/vMotion pendant les heures de pointe. - J‑5 : Sécuriser la pile TCP
Activer Congestion Control CTCP (netsh int tcp set supplemental internet congestionprovider=ctcp) pour limiter les retransmissions. - J‑6 : Validation charge synthétique
Utiliser Remote Desktop Load Simulation Tool pour injecter 1000 connexions sur 24 h et valider l’absence d’ID 40. - J‑7 : Clore l’incident
Documenter la RCA, exporter les règles définitives et créer un dashboard permanent sur Grafana/PRTG.
Bonnes pratiques de durcissement RDP
- Activer l’authentification NLA ; elle réduit les attaques RDP brute‑force et diminue la charge RDSH.
- Limiter la bande passante par utilisateur via Group Policy → Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment → Limit maximum color depth.
- Utiliser le paramètre GPO Set time limit for active but idle Remote Desktop Services sessions pour éviter les sessions fantômes qui consomment des ports dynamiques.
- Placer les serveurs RDSH dans un VLAN dédié avec ACL orientées east‑west minimisant la latence.
- Sauvegarder quotidiennement le fichier
C:\ProgramData\Microsoft\Crypto\RSAafin de préserver la clé de cookie de persistance lors d’un rollback.
Mesures préventives à long terme
Même après résolution, gardez :
- une fenêtre de maintenance mensuelle pour mettre à jour le firmware LoadMaster ;
- un baseline Grafana : latence médiane < 2 ms, 95e percentile < 20 ms, retransmissions < 0,01 % ;
- un test de charge automatisé avant chaque montée de version Windows ;
- une escrime stateless sur les switches ToR pour isoler tout port en erreur CRC > 0,01 %.
FAQ interne
Les licences RDS peuvent‑elles provoquer un ID 40 ? Non. Une licence expirée génère un évènement ID 1152 ou ID 1202 dans TerminalServices-RemoteConnectionManager, jamais un ID 40. MLS/IPS étatique peut‑il couper le RDP ? Oui. Tout équipement inspectant TLS 1.2 ou supérieur sans prise en charge ALPN « spdy/3 » ou mstshash peut interrompre un flux RDP encapsulé. Pourquoi certaines sessions survivent‑elles ? Parce que l’expiration LoadMaster cible un chemin spécifique : seules les sessions mappées sur la même Service ID tombent ; les autres VIP restent stables.
Check‑list rapide
- [ ] Connexion directe sans LB testée 48 h.
- [ ] Mise à jour LoadMaster ≥ 7.2.53.
- [ ] Timeout VIP TCP/UDP ≥ 900 s.
- [ ] RDP Keep‑Alive = 120 s.
- [ ] Offloads LSO/RSS/GSO désactivés.
- [ ] UDP ShortPath validé ou bloqué.
- [ ] PerfMon & NetFlow corrélés.
- [ ] Charge synthétique passée sans ID 40.
Conclusion
Les déconnexions synchrones observées sont quasi toujours liées à de brèves interruptions réseau ou à un rééquilibrage intempestif de l’appliance Kemp. En appliquant la méthode : isolation → hardening → monitoring, on obtient généralement un environnement RDS stable en moins d’une semaine, sans devoir toucher aux profils utilisateurs ni au broker RDS.