MENU
  1. Accueil
  2. Windows
  3. RDP
  4. Résoudre la fermeture instantanée des sessions RDP sur Windows Server 2019 : guide complet de diagnostic

Résoudre la fermeture instantanée des sessions RDP sur Windows Server 2019 : guide complet de diagnostic

RDP

Les sessions RDP qui se ferment aussitôt après l’ouverture sur Windows Server 2019 sont souvent le symptôme d’un conflit entre authentification, pilote, correctif ou stratégie. Suivez le guide complet ci‑dessous pour diagnostiquer et corriger rapidement le problème.

Sommaire

Fermeture immédiate des sessions RDP sur Windows Server 2019

Vue d’ensemble de la question

Dans un environnement de production basé sur VMware vSphere 7.0.3, une VM Windows Server 2019 (Desktop Experience) refusait soudainement toute connexion RDP : l’écran « Welcome » clignotait puis la session se fermait sans message d’erreur. Le redémarrage du serveur, la vérification du service TermService et l’appartenance des utilisateurs au groupe Remote Desktop Users n’ont pas suffi. Il a donc fallu déployer une démarche systématique de diagnostic pour identifier la cause racine et rétablir le service.

Réponse & solutions proposées

Axe d’investigationPoints de contrôle & actions correctives
Journaux d’événements RDSConsultez :
Applications & Services Logs → Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS/Operational (codes de déconnexion 40/41/42). …→ Terminal‑Services‑RemoteConnectionManager/Operational. …→ TerminalServices‑LocalSessionManager/Operational. Le journal Security pour les échecs d’authentification et d’autorisation (4625, 4776).
Réseau & hyperviseurMesurez la latence : ping -n 20 serveur, pathping /n, tracert. Activez une trace réseau : netsh trace start capture=yes report=yes. Mettez à jour le pilote virtuel VMXNET3 via VMware Tools : version ≥ 12.4.5. Pour lever le doute, désactivez provisoirement les offloads (Large Send, Checksum) dans la NIC virtuelle. Côté vSphere, vérifiez les règles du Distributed vSwitch et d’éventuelles policies NSX.
Ressources serveurSurveillez CPU, RAM et I/O disque avec Performance Monitor pendant une tentative RDP : un pic à 100 % CPU ou un Committed Bytes épuisé peut provoquer une fermeture. Activez un Data Collector Set pour capturer % Processor Time, Available MBytes, Disk Queue Length.
Stratégies de groupe (GPO)Navigateurs GPMC :
Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host Vérifiez Connections : Limit number of connections, Set time limit for active but idle sessions. Contrôlez Security : Require user authentication for remote connections by using NLA, Set client connection encryption level. Forcez le rafraîchissement : gpupdate /force puis eventvwr.msc pour confirmer l’application.
Network Level Authentication (NLA)Désactivez temporairement NLA :
System Properties → Remote → Allow connections without NLA ou via Regedit : HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server → UserAuthentication=0. Testez une connexion depuis un poste client mis à jour ; si elle réussit, la cause est souvent un CredSSP/tls mis à jour côté client et non côté serveur.
Licences & rôlesDans Server Manager → Remote Desktop Services, vérifiez que le serveur de licences est Active et que des CAL User/Device valides sont allouées. Le service Remote Desktop Licensing doit être démarré (Port TCP 135). Utilisez RD Licensing Diagnoser pour afficher les erreurs fréquentes : 0xC004F074 ou 0x40004.
Mises à jour & correctifsRecherchez des KB récentes impactant CredSSP ou TLS (ex. KB5005568, KB5026361). Si la panne suit le Patch Tuesday, désinstallez le dernier CU via :
wusa /uninstall /kb:5005568 /quiet /norestart. Redémarrez et validez. Une désinstallation temporaire est un excellent test A/B avant de réinstaller un correctif plus récent.
Sessions fantômesListez les sessions :
qwinsta /server:localhost Réinitialisez‑les :
reset session <ID> /server:localhost ou rwinsta Des sessions orphelines en Disc ou Down monopoliseront des piles RDP et entraîneront des déconnexions éclair.
Certificat RDSDans MMC → Certificates (Local Computer) → Remote Desktop, confirmez que le certificat n’est pas expiré, qu’il contient le FQDN de la machine et la clé privée. Renouvelez‑le via Enable‑RDPCertificateAutoEnrollment ou importez‑en un PKI/TLS valide puis redémarrez TermService.

Informations complémentaires utiles

  1. Événements clés : RdpCoreTS 40 / 41 / 42 (raison 0 = échec d’authentification), RemoteConnectionManager 1026, LocalSessionManager 1130 sont souvent déterminants.
  2. Isolation du problème :
    • Ouvrez la console VMware puis exécutez : mstsc /v:localhost /admin. Si la session locale tombe aussi, le problème est interne au système.
    • Créez un compte test (New‑LocalUser) pour éliminer les profils corrompus.
  3. Sécurité : LAPS, Credential Guard ou un antivirus interceptant mstsc.exe peuvent couper la connexion. Désactivez brièvement pour vérifier.
  4. VMware Tools : une version obsolète peut réinitialiser le pilote vidéo ou réseau durant la négociation du canal RDP.

Étapes pas‑à‑pas de diagnostic détaillé

La résolution rapide exige une approche structurée. Voici un guide chronologique que vous pouvez suivre sans outil payant :

  1. Confirmations préliminaires
    • Connectivité : telnet serveur 3389 depuis le LAN pour s’assurer que le port est ouvert.
    • Service RDP : Get‑Service TermService doit indiquer Running. S’il est en statut Stopped, redémarrez‑le : Start‑Service TermService.
  2. Inspection des événements
    Get-WinEvent -LogName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" -MaxEvents 50 | Select TimeCreated,Id,LevelDisplayName,Message Recherchez l’ID 40 avec ErrCode 0 (credsihp) et l’ID 42 (stack decryption failed). Ces traces orientent vers une erreur d’authentification ou de chiffrement.
  3. Test sans NLA
    Désactivez NLA uniquement à titre temporaire, puis retestez la connexion. Si elle fonctionne, réactivez NLA et passez directement à la mise à jour du serveur pour aligner la version du protocole CredSSP/TLS.
  4. Contrôle des GPO
    Utilisez gpresult /H c:\gp.htm pour auditer les stratégies effectives. Ouvrez le rapport dans Edge et recherchez « Remote Desktop Services » pour identifier une GPO limitant la session à 1 instance ou imposant un délai d’inactivité.
  5. Capture réseau avancée
    netsh trace start capture=yes scenario=rdp maxsize=512 tracefile=c:\trace.etl …&nbsp;effectuez une connexion RDP&nbsp;… netsh trace stop Analysez trace.etl avec Microsoft Message Analyzer ou Wireshark filtré sur tcp.port == 3389 ; vérifiez la séquence Server Hello/Client Key Exchange.
  6. Vérification des licences
    Dans RD Licensing Diagnoser, un avertissement « No licensing mode configured » signifie que le rôle Session Host ne trouve pas de serveur de licences. Configurez‑le : Set-RDLicenseConfiguration -Mode PerUser -LicenseServer @("RDLIC01.contoso.local")
  7. Nettoyage des sessions fantômes
    for /f "skip=1 tokens=3" %i in ('qwinsta') do reset session %i
  8. Reconstruction du sous‑système RDP
    En dernier recours, supprimez puis réinstallez les rôles Remote Desktop Services : Remove-WindowsFeature RDS-RD-Server Add-WindowsFeature RDS-RD-Server

Méthodologie de remédiation

Une fois la cause identifiée, appliquez la correction adéquate :

  • AuthN/AuthZ : alignez les politiques NLA et CredSSP côté client / serveur.
  • Patch & pilote : installez la dernière Cumulative Update, mettez à jour VMware Tools et redémarrez.
  • Licences : réactiver le serveur de licences ou convertir des CAL Device en CAL User pour absorber la charge.
  • GPO : ajustez la limite de temps et le nombre de connexions simultanées.
  • Certificat : déployez un nouveau certificat Wildcard SHA‑256 de 2048 bits, puis redémarrez TermService.

Bonnes pratiques préventives

  • Surveillez Remote Desktop Services avec un outil APM (ex. SCOM) pour être alerté sur les codes d’événements 40/1026.
  • Automatisez l’application des CU via WSUS, tout en maintenant un anneau Staging pour tester avant production.
  • Planifiez un renouvellement automatique des certificats RDP grâce à l’inscription auto‑PKI.
  • Documentez une procédure « break glass » console/admin en cas de verrou total.
  • Effectuez des sauvegardes mensuelles du profil Default et des clés de registre RDP pour accélérer une restauration.

FAQ

Pourquoi le service RDP plante‑t‑il après le Patch Tuesday ? Microsoft corrige fréquemment CredSSP et la pile TLS. Si le client est patché et le serveur non, le handshake échoue, ce qui se manifeste par une fermeture immédiate. Quelle est la différence entre mstsc /admin et une session classique ? L’option /admin se connecte à la session console (ID 0) et ignore la plupart des limitations RDS : quotas, licences, redirections, etc. C’est l’outil de secours idéal. Comment savoir si mon certificat RDP est bien utilisé ? Dans le gestionnaire de certificats, la colonne Intended Purposes doit afficher « Server Authentication ». Vous pouvez aussi lancer qwinsta : le champ Encryption doit indiquer SSL et non RDP Security Layer.

Annexe : commandes PowerShell et CLI utiles

# Liste des connexions RDP actives
Get-Process -Name "rdpclip","mstsc" | Format-Table -AutoSize

# Événements RDP sur les dernières 24 h

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=(Get-Date).AddHours(-24)} |
Where-Object {\$*.Properties\[8].Value -eq '10'} |
Select TimeCreated, @{n="User";e={\$*.Properties\[5].Value}}, Message

# Export des politiques RDS

secedit /export /cfg c:\rdp\_policies.inf

# Contrôle rapide des files d'attente CPU

typeperf "\Processor(\_Total)% Processor Time" -sc 5

En suivant cette grille de diagnostic exhaustive, vous déterminerez en général la cause — authentification NLA, ressources insuffisantes, correctif défaillant ou certificat expiré — et vous rétablirez l’accès RDP de manière fiable et documentée.

RDP
RDP dépannage Remote Desktop Services Windows Server 2019 VMware
Sommaire