RDP lent via CAPAM : diagnostic réseau, affichage et optimisation pas‑à‑pas

Lorsque l’affichage d’une session RDP traversant CA Privileged Access Manager (CAPAM) devient anormalement lent ou se fige, il est indispensable d’aborder le sujet de façon méthodique : commencer par confirmer les symptômes, puis éliminer chaque cause potentielle jusqu’à isoler le goulet d’étranglement.

Sommaire

Contexte

CAPAM agit comme une passerelle sécurisée entre l’utilisateur et le serveur cible ; tout paquet RDP voyage donc poste → CAPAM → hôte. Ce double saut ajoute de la latence et concentre les flux dans l’appliance : la moindre faiblesse côté réseau, protocole, ressources système ou configuration se manifeste directement à l’écran par un lag, un rafraîchissement en mosaïque ou une session complètement bloquée.

Symptômes typiques

  • Retards de plusieurs secondes entre l’action clavier/souris et l’affichage.
  • Bureau noir ou figé, puis reprise abrupte.
  • Sons robotisés lors de redirection audio.
  • Taux d’images très bas (< 5 fps) malgré une faible charge CPU sur le serveur RDS.
  • Messages CAPAM du type « channel later retry » ou « session busy » dans les logs.

Grille d’analyse rapide

Axe d’analysePoints de contrôleActions recommandées
Client & protocole RDPClient obsolète ; services Remote Desktop arrêtés ; protocole RDP désactivé.Mettre à jour le client RDP et l’OS. Redémarrer/activer TermService et le protocole RDP sur l’hôte.
Paramètres d’affichageRésolution ou profondeur de couleur élevées ; mise à l’échelle DPI personnalisée non optimisée.Réduire résolution & couleurs, désactiver animations/redirections inutiles (audio, imprimantes, presse‑papiers).
RéseauLatence, perte de paquets, MTU inadaptée, congestion entre poste ↔ CAPAM ↔ hôte.Tester avec ping, tracert, Network Monitor ou Wireshark ; vérifier QoS, bande passante et ports 3389/443/22.
Appliance CAPAMCPU/RAM saturées, trop de sessions simultanées, version logicielle dépassée.Surveiller ressources CAPAM, consulter journaux de session, appliquer correctifs ; augmenter vCPU/RAM ou activer le mode « Direct Connect ».
Configuration RDP avancéeParamètres non adaptés au lien réseau.Activer codec H.264/AVC et transport UDP (ou forcer TCP si UDP bloqué) ; ajuster la compression bitmap.
Sécurité & tiersInspection TLS/SSL par firewall/IDS ; antivirus analysant le flux.Désactiver temporairement ces composants pour tester ; optimiser négociation TLS (certificats à jour, suites chiffrées).
Serveur de sessionsContres‑performances ponctuelles non décelées via CPU/RAM seuls.Employer Performance Monitor : % Processor Time, Disk Queue Length, Network Interface, etc.
Isolement du problèmeDoute sur la responsabilité de CAPAM.Ouvrir une session RDP directe (sans CAPAM) ; comparer les performances.

Détails et procédures de diagnostic

Évaluer le client RDP et le service Terminal Services

Un poste exécutant une version Remote Desktop Connection antérieure à 10.0.19041.x ne supporte pas toujours le codec H.264 ou le transport UDP moderne. Exécutez :

mstsc /version

Si la version est obsolète, déployez les dernières mises à jour cumulatives Windows ou installez Remote Desktop client for Windows Desktop. Côté serveur, vérifiez que le service TermService est démarré :

sc query TermService

Arrêtez/redémarrez‑le si nécessaire pour purger les sessions fantômes.

Optimiser les paramètres d’affichage

  • Définir la résolution en 1280 × 720 ou 1600 × 900 pour tester la réactivité.
  • Réduire la profondeur de couleur à 16 bits si le lien est inférieur à 2 Mbit/s.
  • Désactiver la redirection audio, imprimante, presse‑papiers et lecteur si ces fonctions ne sont pas requises.
  • Désactiver la composition visuelle (« Font smoothing », « Menu animation ») sur le serveur RDS via gpedit.msc > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment.

Tester et ajuster le réseau

Commencez par un ping continu entre le poste et CAPAM ; une latence stable au‑delà de 120 ms ou une perte > 1 % provoque déjà des saccades visuelles. Utilisez ensuite :

pathping <FQDN hôte RDP>

pour identifier l’étape qui injecte la latence. Vérifiez le MTU : un MTU trop bas (< 1300) entraîne de la fragmentation et multiplie les ACK/TCP ; ajustez via :

netsh interface ipv4 show subinterfaces

Puis :

netsh interface ipv4 set subinterface "Ethernet" mtu=1470 store=persistent

Surveiller et tuner l’appliance CAPAM

Connectez‑vous à l’interface d’administration : Dashboard > Statistics > System Health. Un CPU au-delà de 80 % ou une swap constante sont de mauvais signes. Points clés :

  • Sessions simultanées : chaque proxy RDP consomme environ 10–15 Mo de RAM et 30–60 file descriptors.
  • Version logicielle : notez le build ; les correctifs ID 62686, 62914 et 63221 résolvent divers freezes RDP.
  • Mode Direct Connect : autorise le flux graphique à contourner l’appliance après l’authentification initiale, réduisant la latence de 20–30 ms.
  • vCPU réservé : en environnement VMware, affectez un CPU Reservation équivalente à au moins 75 % de la fréquence nominale nécessaire.

Activer le codec H.264/AVC et le transport UDP

Depuis Windows Server 2022/Windows 10 1607, le paramètre Configure H.264/AVC hardware encoding for RemoteFX améliore la compression. Vérifiez via GPO :

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment

Activez également Enable UDP Transport. Attention : si des pare‑feux bloquent UDP 3389, la connexion retombera sur TCP ; mesurez alors le débit (Get-NetTCPConnection) pour décider d’ouvrir UDP.

Gérer l’inspection TLS/SSL

Les boîtiers WAF/IDS insèrent parfois des algorithmes de ré‑encodage impactant la latence ; désactivez brièvement la fonction SSL‑inspection sur le flux CAPAM <‑> hôte et surveillez la différence. Côté serveur, installez un certificat ECDSA 384 bits et éliminez les suites RC4/3DES ; négocier TLS 1.2 ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 réduit le handshake de plusieurs paquets.

Détecter les goulets invisibles du serveur RDS

Un serveur peut afficher un CPU < 20 % sans pour autant délivrer correctement les images RDP. Ajoutez les compteurs suivants dans perfmon.msc :

  • RemoteFX Encoder Frames / sec
  • Network Interface » Bytes Total/sec
  • LogicalDisk » Average Disk Queue Length
  • TCPv4 » Connections Established

Corrélez un pic de file d’attente disque ou un goulot sur Frames avec le freeze utilisateur ; upgradez alors le contrôleur RAID, passez à SSD NVMe ou répartissez le rôle RD Session Host sur plusieurs VM.

Isolement : comparer avec une session directe

La règle d’or : si une session directe RDP (poste – VPN – hôte) est fluide tandis qu’une session via CAPAM se fige, la responsabilité revient quasi certainement à l’appliance (ressources, version, configuration, inspections intermédiaires). Documentez les chiffres : latence directe vs proxifiée, perte de paquets, FPS, taille des fenêtres TCP, etc., pour étayer votre ticket d’escalade.

Checklist pas‑à‑pas

  1. Mettre à jour le poste client (Windows Update ou macOS App Store).
  2. Redémarrer TermService sur le serveur puis contrôler qwinsta pour libérer les sessions orphelines.
  3. Basculer la résolution RDP en 1280 × 720, 16 bits, sans redirections.
  4. Exécuter ping -n 50 vers la VIP CAPAM ; viser < 80 ms/0 % perte.
  5. Ouvrir System Metrics dans CAPAM ; vérifier CPU < 70 %, RAM < 80 %.
  6. Appliquer le patch CAPAM le plus récent (au moins build 4.1.2.x).
  7. Activer Direct Connect et la compression H.264/UDP.
  8. Désactiver temporairement l’IDS ou l’SSL‑inspection pour le flux 3389.
  9. Mesurer l’amélioration ; si < 15 fps, ajouter 1–2 vCPU et 4 Go RAM à CAPAM.
  10. Escalader au support fournisseur avec les journaux et captures Wireshark.

Outils recommandés

  • Microsoft Remote Desktop Analyzer – décode les paquets RDP.
  • Get‑RdpSequencerLogs.ps1 – script PowerShell qui corrèle les événements RemoteFX.
  • Wireshark + filtre tcp.port == 3389 – inspecte la qualité de la session.
  • CAPAM Session Recorder – enregistre chaque trame RDP pour relecture.
  • Perfmon Data Collector Set – automatise la collecte pendant 48 h.

Bonnes pratiques spécifiques à CAPAM

CAPAM, en tant que VM, souffre rapidement de la contention CPU ; réservez 100 % des vCPU et désactivez CPU Hot‑Add pour éviter le vNUMA fragmentation. Placez les fichiers swap et session cache sur un datastore SSD séparé. Programmez un job de purge des enregistrements de session (> 180 jours) pour contenir la base de données interne. Enfin, planifiez un redémarrage hebdomadaire de l’appliance hors production : cela libère les sockets persistants et réinitialise la mémoire JVM.

Quand escalader au support

Escaladez dès que :

  • La latence CAPAM parser > 300 ms selon diagtool.sh –metrics.
  • Vous observez > 50 % de transcodage à la volée (« frame re‑encode »).
  • Le patch le plus récent est déjà appliqué et le mode Direct Connect activé.

Joignez alors : capture Wireshark, métriques CAPAM, export CSV perfmon, configuration GPO serveur, version client RDP, détails MTU, capture d’écran du freeze.

Conclusion

Une session RDP lente via CAPAM résulte presque toujours d’une chaîne de petits goulets : un codec inapproprié, quelques paquets fragmentés, un CPU virtuel saturé, un IDS trop curieux… En appliquant la grille d’analyse ci‑dessus, puis la checklist pas‑à‑pas, vous pourrez mesurer chaque changement et, in fine, retrouver une expérience utilisateur fluide tout en conservant le niveau de sécurité exigé par CAPAM.

Ressources complémentaires (sans lien direct) : Microsoft Learn « Using Performance Counters to Diagnose Application Responsiveness Issues on Remote Desktop Session Hosts », Microsoft Learn « Performance Tuning for Remote Desktop Session Hosts », et les discussions Stack Overflow sur le codec H.264 RDP.

Sommaire