RDP: disconnessioni casuali su Windows Server 2022 dietro Kemp LoadMaster — cause, diagnosi e soluzioni

RDP che si disconnette a ondate, senza picchi di CPU o RAM, punta quasi sempre a problemi di rete o bilanciamento. Questa guida pratica, su Windows Server 2022 e Kemp LoadMaster, mostra come isolare e risolvere drop intermittenti con Event ID 40.

Indice

Panoramica del problema

Scenario reale: due host Windows Server 2022 (virtualizzati) pubblicano Remote Desktop Services dietro due Kemp LoadMaster, con circa 20 utenti simultanei. I sintomi osservati sono ondate di disconnessioni che colpiscono 3‑4 utenti alla volta, da 1 a 4 volte al giorno. La riconnessione avviene in pochi secondi e, nel frattempo, CPU e RAM dei server restano stabilmente < 50 %.

Nei log compare Event ID 40 del canale TerminalServices‑LocalSessionManager con i codici 0x80070079 (“semaphore timeout”) e 0x80070040 (“network name no longer available”). I due codici, tipicamente, rimandano a un’interruzione o a un timeout sul percorso di rete più che a un problema applicativo dei server RDS.

Perché succede

RDP è resistente alla perdita di singoli pacchetti, ma sopra certe soglie di latency, jitter e packet loss i timer interni scadono e la sessione viene considerata non più valida. Se in mezzo esiste un bilanciatore, i suoi idle timeout, i controlli di integrità o la persistenza potrebbero chiudere i flussi prima che il server invii traffico di mantenimento.

Mappa delle cause possibili

CategoriaMotivo probabileIndicazioni pratiche
ReteLatenza elevata o perdita di pacchetti che supera la soglia di tolleranza RDPI codici 0x80070079 e 0x80070040 indicano time‑out e interruzione del percorso; cercare jitter, micro‑interruzioni, MTU errata o link‑flap
Load balancerTimeout TCP/UDP o health‑check aggressivi che resettano la sessioneGli utenti colpiti stanno passando sullo stesso nodo/VIP; verificare idle timeout, persistenza e come vengono trattati i flussi RDP‑UDP
Server RDSMeno probabile: driver NIC obsoleti, offload problematici o keep‑alive RDP non ottimaliNessun picco di risorse; comunque verificare driver, impostazioni TCP e GPO RDP

Strategia di troubleshooting a impatto crescente

Il principio è isolare prima il livello responsabile (reteload balancerserver) e poi ottimizzare timer e parametri in modo coerente, evitando reset indesiderati.

Aggiornamento e patching

  • Applicare le ultime Cumulative Update di Windows Server 2022, firmware/hypervisor (vSwitch, NIC fisiche) e release Kemp LoadMaster.
  • Aggiornare i driver di rete delle VM RDS. In caso di comportamenti anomali, testare con offload disattivati sul NIC della VM: LSO/LSOv2, RSC, RSS (solo prova mirata).
# Ispeziona rapidamente stato offload e RSS
Get-NetAdapter | Format-Table Name, Status, LinkSpeed
Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Where-Object {$_.DisplayName -match 'Offload|RSC|RSS'} |
  Format-Table Name, DisplayName, DisplayValue

Esempio: disabilita LSO v2 per IPv4/IPv6 (i nomi possono variare)

Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload v2 (IPv4)" -DisplayValue "Disabled"
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload v2 (IPv6)" -DisplayValue "Disabled"

Test di rete end‑to‑end

  • Ping continui e pathping tra client ↔ VIP del LoadMaster e tra LoadMaster ↔ server RDS per individuare jitter e perdita.
ping -t <VIP_RDP>
pathping -n <VIP_RDP>
ping -f -l 1472 <VIP_RDP>   # verifica MTU/fragmentation
  • iperf3 per throughput e jitter (TCP e UDP) in finestre temporali che includano gli orari dei drop.
# TCP (download dal server)
iperf3 -c <serverorvip> -t 60 -R
UDP (attenzione ai firewall/NAT)
iperf3 -c <serverorvip> -u -b 10M -l 1200 -t 60
  • Abilitare Syslog/SNMP su switch e firewall per rilevare link‑flap, CRC errors, saturazioni o rinegoziazioni sui percorsi utilizzati dagli utenti colpiti.

Verifica LoadMaster

Concentrarsi su tre aree: timeout, persistenza e health‑check.

  • Idle Connection Timeout: se inferiore all’intervallo di keep‑alive RDP/TCP, il bilanciatore chiude i flussi inattivi. Aumentarlo di qualche minuto sopra i keep‑alive effettivi.
  • TCP Keep‑alive e modalità di bilanciamento: preferire bilanciamento di Layer 4 per RDP puro su 3389 e una persistenza coerente (es. Source IP) per evitare salti di backend in riconnessione.
  • Controlli di integrità: troppo aggressivi o con timeout brevi possono marcare un nodo come non sano e resettare flussi attivi. Allungare tempo di fail e abilitare graceful draining.
  • RDP‑UDP: verificare come viene gestito il traffico UDP 3389; su reti instabili, conviene forzare temporaneamente solo TCP per stabilizzare.

Test chiave: per 48 ore fate collegare un sottoinsieme rappresentativo di utenti direttamente su un nodo RDS (bypass LoadMaster). Se i drop spariscono, il fuoco è sul bilanciatore; se restano, spostare l’analisi sulla rete/virtualizzazione.

Ottimizzazione RDP

Allineare i timer per evitare che il dispositivo “nel mezzo” arrivi per primo alla conclusione che un flusso sia inattivo.

  1. Keep‑alive RDP via GPO (Server): impostare Set keep‑alive connection interval su un valore inferiore agli idle timeout del LoadMaster (esempio: 2–4 minuti). Percorso:
    Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Set keep‑alive connection interval
  2. Selettore protocollo RDP: in reti non affidabili, impostare Select RDP transport protocols su Use only TCP per escludere UDP fino a stabilizzazione.
    ... > Connections > Select RDP transport protocols
  3. Timer TCP a livello OS (Server): regolare i parametri di keep‑alive del TCP stack in millisecondi (valori di partenza, da adattare in produzione con cautela). HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveTime (DWORD) 120000 ; 2 minuti KeepAliveInterval (DWORD) 1000 ; 1 secondo TcpMaxDataRetransmissions (DWORD) 8 ; prudenziale

Ricordare che i keep‑alive sono heart‑beat a basso traffico: non sostituiscono una connessione “attiva”, ma impediscono che dispositivi intermedi scadano prima del server.

Raccolta log dettagliati

Correlare l’istante del drop su tutti i livelli. Abilitare i canali seguenti ed esportare i log in UTC.

  • Server:
    • Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS/Operational
    • Microsoft‑Windows‑TerminalServices‑LocalSessionManager/Operational
    • Microsoft‑Windows‑Tcpip/Operational
  • Client: eventi TermDD 50/56 e canali RDP client per distinguere server ended connection vs network error.
# Abilita canali di diagnostica
wevtutil sl Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational /e:true
wevtutil sl Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /e:true
wevtutil sl Microsoft-Windows-TCPIP/Operational /e:true

Estrai Event ID 40 con i due codici e mostra timeline

$filter = @{
LogName = 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational'
Id      = 40
}
Get-WinEvent -FilterHashtable $filter |
Where-Object { $_.Message -match '0x80070079|0x80070040' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Sort-Object TimeCreated
# Traccia di rete mirata durante il problema
netsh trace start scenario=NetConnection capture=yes report=yes tracefile=C:\Trace\rdp-drop.etl
... riprodurre il problema, poi
netsh trace stop

Metodo di esclusione rapida

Passo A: bypass del LoadMaster con un gruppo di utenti e monitoraggio per 48 h. Esito 1: nessuna disconnessione → rivedere idle timeout, persistenza, health‑check e gestione UDP nei Kemp. Esito 2: disconnessioni persistono → focalizzarsi su rete/virtualizzazione.

Passo B: se il problema è lato rete, cercare correlazioni con eventi infrastrutturali (flap, upgrade, backup, job batch, saturazione WAN). Passo C: se lato virtualizzazione, verificare vSwitch, NIC fisiche/driver, team/LACP, VMQ, SR‑IOV e impostazioni dell’appliance virtuale del LoadMaster.

Impostazioni di base consigliate

Questi valori sono di partenza per ambienti RDS dietro bilanciatore. Vanno provati e adattati sul campo.

ComponenteParametroValore inizialeNote
GPO RDSKeep‑alive connection interval2–4 minDeve essere inferiore all’Idle Timeout del LB
RDP trasportoSelect RDP transport protocolsUse only TCP (temporaneo)Riabilitare UDP solo a rete stabilizzata
TCP StackKeepAliveTime / Interval120 s / 1 sRegistro OS; valutare impatto su scala
LoadMasterIdle Connection Timeout≥ Keep‑alive + 3–5 minEvitare chiusure premature dei flussi
LoadMasterHealth‑checkIntervalli non aggressiviAbilitare draining sui failover
NIC VM RDSOffload LSO/RSCDisabilitare in testRe‑enable se non c’entra con i drop

Runbook operativo

  1. Stato di salute: confermare CPU, RAM, disco e latenza storage in norma su entrambi i server. Annotare versioni OS/driver/LB.
  2. Campionamento utenti: identificare 5–7 utenti frequentemente colpiti e attivare logging lato client (eventi TermDD, RDP client logs).
  3. Misure di rete: ping‑t e pathping dal client verso VIP e, se possibile, direttamente verso i backend; salvare timestamp UTC.
  4. Bypass LB: per un sottoinsieme, collegamento diretto al nodo RDS; confrontare i log.
  5. Parametri: applicare keep‑alive RDP via GPO e adeguare timer LB. In reti rumorose, forzare solo TCP.
  6. Offload: disattivare temporaneamente LSO/RSC sulla VM RDS più colpita; osservare per 24–48 h.
  7. Tracce: durante un drop, catturare netsh trace e annotare ID sessione, VIP, backend assegnato, stato health‑check.
  8. Condivisione evidenze: se il problema segue il nodo LB, aprire ticket al supporto Kemp con timeline e pacchetti; altrimenti coinvolgere networking o Microsoft con la stessa evidenza strutturata.

Pattern ricorrenti e come riconoscerli

  • Disconnessioni a grappolo (3–4 utenti insieme): indicano spesso un reset lato VIP o un failover/riavvio del nodo LB, oppure un problema di uplink condiviso.
  • Riconnessione istantanea: suggerisce che i server RDS sono sani e che si tratta di un reset di trasporto piuttosto che di un crash del servizio.
  • Nessun carico anomalo: esclude cause di esaurimento risorse (Session Host sotto stress) e sposta l’attenzione su rete/LB.
  • Event ID 40 con 0x80070079: coerente con time‑out di rete, spesso legato a perdita o ritardo eccessivo in specifiche finestre temporali.
  • Event ID 40 con 0x80070040: tipico di interruzione del percorso o risoluzione del nome/connessione che viene meno per breve periodo.

Approfondimenti di rete

MTU e frammentazione

Un path MTU non uniforme causa ritrasmissioni e talvolta blocchi sui dispositivi di sicurezza. Usare ping -f -l per scoprire la dimensione massima senza frammentazione e regolare di conseguenza gli endpoint coinvolti.

QoS e priorità

Se in rete è attiva la QoS, assicurarsi che il traffico RDP non venga declassato durante finestre di congestione. Marcature DSCP incoerenti lungo il percorso possono aumentare la latenza in modo selettivo.

Flap fisici e power saving

Su host fisici o switch di accesso, disattivare il Green Ethernet e il risparmio energetico delle NIC che potrebbero introdurre micro‑interruzioni. Verificare i contatori di CRC e alignment errors.

Virtualizzazione e vSwitch

  • vNIC/vSwitch: controllare il binding corretto, gli offload hardware e il teaming (LACP/Static). Un cambio di stato del team può resettare sessioni attive.
  • VMQ/RS‑IOV: in alcuni scenari riducono la latenza ma, se configurati male, provocano starvation di code; testare con impostazioni conservative.
  • Scheduling host: picchi brevi di CPU ready time sull’hypervisor possono impattare il networking della VM; monitorare i contatori specifici dell’hypervisor.

Esempi di verifica rapida in PowerShell

# 1) Test porta RDP verso VIP e backend
Test-NetConnection -ComputerName <VIP_RDP> -Port 3389 -InformationLevel Detailed
Test-NetConnection -ComputerName <RDS_NODE> -Port 3389 -InformationLevel Detailed

2) Log periodico di ping con timestamp UTC

$target = ""
1..600 | ForEach-Object {
"$((Get-Date).ToUniversalTime().ToString('o')) `t $(Test-Connection $target -Count 1 -Quiet)" |
Out-File C:\Temp\rdp-ping.log -Append
Start-Sleep -Seconds 5
}

3) Eventi TermDD lato client (se ammesso)

Get-WinEvent -LogName 'System' | Where-Object { $_.Id -in 50,56 } |
Select-Object TimeCreated, Id, Message

Come leggere i risultati

OsservazioneInterpretazioneAzione
Ping stabile verso backend, instabile verso VIPVIP/LB introduce perdita o resetAumentare timeout/persistenza, rivedere health‑check, aggiornare firmware LB
Ping e iperf stabili, ma drop RDPTimer RDP/TCP non allineati o offload difettosiRidurre keep‑alive, disabilitare temporaneamente offload, forzare TCP‑only
Drop coincidono con errori su switch o uplinkProblema fisico o di saturazioneRimediare a cavi/porte, ricalibrare QoS, aumentare banda
Drop solo su uno dei due nodi LBConfigurazione o health‑check del nodo difettosoAllineare configurazioni, aprire ticket al vendor del LB

Timeline e correlazione

Unificare tutti i timestamp in UTC (server, LoadMaster, switch, client). Creare una timeline con: ID sessione RDP, VIP usato, backend assegnato, stato nodi LB, errori di rete, Event ID 40 e TermDD 50/56. Questa matrice permette escalation efficaci verso Microsoft o Kemp.

Prossimi step raccomandati

  • Se la disconnessione non si verifica bypassando il LoadMaster, aprire ticket al supporto Kemp e rivedere impostazioni di bilanciamento, persistenza e timeout.
  • Se il problema persiste anche senza bilanciamento, concentrare l’analisi su virtualizzazione (vSwitch, NIC fisiche, driver) e dorsale di rete (switch core, cablaggi, QoS).
  • Conservare una timeline con timestamp UTC di log server, network e client: è essenziale per escalation strutturate.

In sintesi, i codici 0x80070079 e 0x80070040 puntano quasi sempre a interruzioni sul percorso di rete. Il metodo più rapido per circoscrivere la causa è escludere temporaneamente il load balancer e monitorare la stabilità: da lì si decide se intervenire sulle impostazioni Kemp o sul trasporto di rete sottostante.

Checklist finale

  • Ultime CU applicate a OS, hypervisor, LoadMaster.
  • Driver NIC aggiornati; offload controversi testati/disabilitati.
  • Ping, pathping e iperf3 raccolti nei periodi dei drop.
  • Timer allineati: GPO keep‑alive < Idle Timeout LB.
  • RDP‑UDP disabilitato in rete “rumorosa”, riabilitato a problema risolto.
  • Log abilitati e salvati: RdpCoreTS, LSM, TCPIP; TermDD lato client.
  • Bypass LB effettuato e comparativa documentata.
  • Timeline UTC completa per escalation.

FAQ operative

Meglio aumentare l’Idle Timeout o ridurre i keep‑alive? Entrambi: portare i keep‑alive a un intervallo ragionevole (pochi minuti) e allo stesso tempo configurare l’Idle Timeout del LB in modo più alto, così il LB non anticipa la scadenza.

Forzare TCP peggiora le prestazioni? In reti affidabili, l’uso di UDP offre una latenza percepita migliore. In fase di troubleshooting, però, disabilitare UDP semplifica la matrice dei problemi e spesso stabilizza le sessioni.

Serve modificare i timer TCP di sistema? Non sempre. I timer GPO di RDP bastano in molti casi. I timer TCP diventano utili quando dispositivi intermedi applicano politiche particolarmente conservative.

Gli offload vanno sempre disabilitati? No. Disattivarli è una manovra diagnostica. Se non cambia nulla, è meglio riabilitarli per mantenere le massime prestazioni.

Conclusioni

Le disconnessioni casuali RDP in ambienti Windows Server 2022 dietro Kemp LoadMaster raramente sono imputabili ai Session Host, specie in assenza di saturazione risorse. Il più delle volte sono micro‑interruzioni di rete o timer non allineati tra RDP, TCP e bilanciatore. Con la metodologia proposta—patching, misure end‑to‑end, bypass mirato, allineamento dei timer e raccolta log—si arriva rapidamente a un punto decisionale: intervenire sul LoadMaster o sul trasporto di rete. Una volta stabilizzata la base, si può riabilitare UDP e ottimizzare finemente le prestazioni senza sacrificare l’affidabilità.

Indice