RDP che si blocca su Windows Server 2019 (RDS): soluzione definitiva disattivando UDP e best practice

Schermo RDP che si blocca su Windows Server 2019 con RDS? In molte reti il colpevole è il trasporto UDP di RDP. In questa guida trovi una soluzione collaudata (forzare TCP via GPO) e una checklist completa per eliminare i freeze e stabilizzare le sessioni degli utenti.

Indice

Scenario e sintomi

In un’infrastruttura con Windows Server 2019 e ruolo Remote Desktop Services (RDS), alcuni utenti segnalano che l’immagine del desktop remoto si blocca in modo sporadico. Il cursore può muoversi oppure tutto resta immobile; l’audio può interrompersi. L’amministratore, avviando una sessione di shadowing o monitorando dal server, vede invece la sessione perfettamente reattiva. Il client “riparte” solo chiudendo e riconnettendo l’RDP.

Questo pattern è tipico di problemi sul canale grafico/ingressi lato client, spesso legati a RDP su UDP (perdita/riordinamento pacchetti, MTU/fragmentation, NAT/firewall ispezionanti, apparati SD‑WAN o VPN che trattano UDP in modo aggressivo).

Perché succede: RDP, UDP e reti “troppo intelligenti”

Dalla generazione RDP 8/10, il protocollo sfrutta un canale UDP (porta 3389 in accesso diretto; 3391 quando si passa da RD Gateway) per ottimizzare grafica, input e media in condizioni di buona banda e latenza. In molte reti enterprise però:

Firewall/NAT eseguono stateful inspection o ALG particolarmente severi sugli stream UDP;
MTU inconsistente tra segmenti WAN/VPN provoca frammentazione e perdita dei datagrammi;
Apparati di sicurezza (IPS/IDS), acceleratori WAN, proxy o policy QoS non allineate degradano o strozzano l’UDP;
La presenza di jitter e burst loss intermittenti colpisce molto più pesantemente UDP che TCP.

Risultato: lato server la sessione continua (quindi lo shadow è regolare), ma il client smette di aggiornare la grafica e “va in freeze” finché non ricostruisce la connessione.

Soluzione rapida e affidabile: forzare RDP su TCP

La correzione più efficace e a basso impatto è disattivare l’UDP lato client con la policy Turn Off UDP On Client. Così la sessione RDP userà solo TCP, che dispone di ritrasmissione, controllo di congestione e gestione dell’ordine dei pacchetti: è meno performante su reti perfette, ma molto più resiliente su reti reali o “rumorose”.

Applicazione tramite GPO di dominio (consigliato)

Apri Group Policy Management e crea una nuova GPO (es. “RDP‑Forza‑TCP”).
Modifica la GPO e vai in:
Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client.
Apri la policy Turn Off UDP On Client e impostala su Enabled.
Collega la GPO all’OU che contiene i computer client (non il server RDS).
Forza l’aggiornamento con gpupdate /force e riavvia i client interessati.

Applicazione locale su singolo PC (test/pilot)

Su un client, apri gpedit.msc.
Vai in Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client.
Abilita Turn Off UDP On Client, applica e riavvia.

Verifica che la policy sia effettiva

Controllo registro sul client:
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client
Valore fClientDisableUDP (DWORD) = 1.
Event Viewer (client): abilita e osserva i log in
Applications and Services Logs → Microsoft → Windows → TerminalServices‑ClientActiveXCore → Operational
e
Applications and Services Logs → Microsoft → Windows → RemoteDesktopServices‑RdpCoreTdx → Operational.
Dopo la riconnessione dovresti vedere il fallback su TCP e l’assenza di canali RDP‑UDP attivi.

Alternativa/ulteriore mitigazione lato server

Se vuoi essere assolutamente certo di non usare UDP in nessun caso, puoi impostare anche sul Session Host:

GPO: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections → Select RDP transport protocols = Use only TCP.
Se usi RD Gateway: in RD Gateway Manager → Transport Settings, disabilita la UDP Transport (se applicabile) per forzare il solo canale HTTPS/TCP.

Questa scelta è più “drastica” e impatta tutti i client; in molti casi basta la sola policy lato client.

Tabella riassuntiva: soluzioni proposte e passaggi operativi

Area	Azione consigliata	Dettagli / motivazione
Protocollo di trasporto	Disattivare UDP lato client	Abilitare in GPO Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client → Turn Off UDP On Client. • Costringe la sessione RDP a usare solo TCP, eliminando perdite/riordinamento di pacchetti che possono generare freeze. • Riavviare il PC client dopo la modifica.
Connessione di rete	Verificare qualità e stabilità	• Ping prolungato al server. • Test di velocità, latenza e jitter (anche in orari diversi). • Controllo di firewall, NAT, DNS, QoS e policy di sicurezza che possano interferire con UDP. • Attenzione a SD‑WAN, VPN e MTU/mss‑clamp.
Driver e patch	Aggiornare driver grafici e sistema	• Eseguire Driver Verifier su macchine sospette per individuare driver instabili. • Installare gli aggiornamenti Windows più recenti sia lato server sia lato client (RDP client incluso).
Gestione sessioni	Terminare mstsc.exe e ricreare profilo (se necessario)	• In Task Manager chiudere `mstsc.exe` per forzare la ricostruzione della sessione. • Se il problema è profilato‑utente, eliminare il profilo locale e farne generare uno nuovo al login (previo backup dei dati).
Timeout e politiche RDS	Controllare impostazioni di session timeout	Impostazioni troppo aggressive possono simulare un freeze; regolarle in RDS Session Collection Properties → Session (Idle/Active/Disconnected session limits).

Effetti collaterali attesi

Disabilitare UDP: in genere gli utenti non notano differenze visibili; su reti con latenza molto bassa si può osservare una minima riduzione della fluidità grafica, ma l’affidabilità aumenta sensibilmente.
Aggiornamenti driver/OS: potrebbero richiedere riavvii programmati o finestre di manutenzione.
Nuovo profilo utente: perdita di personalizzazioni locali; salvare dati e profili applicativi prima di procedere.

Risultato ottenuto in un caso reale

Dopo l’applicazione della policy Turn Off UDP On Client nella OU dei PC aziendali, per settimane non sono stati registrati ulteriori blocchi d’immagine. Le sessioni RDS hanno mantenuto una stabilità costante, con soddisfazione degli utenti e nessun impatto significativo sulle prestazioni percepite.

Diagnostica: come confermare che il problema è UDP

Contatori e log utili

Event Viewer (client):
Applications and Services Logs → Microsoft → Windows → TerminalServices‑ClientActiveXCore → Operational
Applications and Services Logs → Microsoft → Windows → RemoteDesktopServices‑RdpCoreTdx → Operational
Cerca messaggi che indicano RDP‑UDP attivato o errori sul canale UDP e verifica la presenza di fallback su TCP.
Performance Monitor: aggiungi contatori relativi a rete e RDP (es. TCPv4\Segments Retransmitted, Network Interface\Output Queue Length, contatori RemoteFX/RDP se disponibili) per correlare i freeze con picchi di perdita/jitter.

Test di rete ripetibili

Ping prolungato al Session Host o alla VIP del bilanciatore (se presente): ping -t nomeoipdelserver Cerca spike di latenza o perdita.
PathPing per misurare perdita lungo il percorso: pathping nomeoipdelserver
MTU discovery per individuare fragmentazione (in VPN è comune): ping -f -l 1472 nomeoipdelserver Riduci il valore finché il ping passa senza frammentazione (es. 1400‑1420). Una MTU troppo bassa/variabile impatta l’UDP.
Controllo QoS: verifica DSCP/policy su apparati WAN e se l’UDP 3389/3391 riceve la stessa classe dell’HTTPS/TCP.

Shadowing come “cartina al tornasole”

Se durante lo shadowing l’admin vede tutto fluido mentre l’utente riporta il freeze, è molto probabile che il problema sia tra client e rete (non sul Session Host). Questo avvalora l’ipotesi di maltrattamento dell’UDP da parte dell’infrastruttura di rete.

Best practice di hardening e manutenzione

Patch management: mantieni aggiornati sia i Session Host che i client (incluso il Remote Desktop client preinstallato in Windows).
Driver grafici: su host con GPU, usa driver certificati per data center; sui client, evita driver legacy che possono causare TDR o glitch con WDDM.
Timeout RDS: imposta valori coerenti con l’uso (Idle/Active/Disconnected) per evitare “stati ambigui” che gli utenti percepiscono come freeze.
Profilazione utenti: se i freeze riguardano pochi utenti ricorrenti, valuta la ricreazione del profilo locale (cache RDP corrotta, chiavi MSTSC, plug‑in terzi).

Impatto sulle prestazioni: cosa aspettarsi passando a TCP

La maggior parte dei casi d’uso (Office, ERP, browser, gestione documentale, line‑of‑business) non subisce regressioni percepibili. In presenza di alta latenza e grafica molto dinamica (CAD, video), il canale UDP può offrire un vantaggio teorico; ma se la tua rete perde o reordina pacchetti, il guadagno è nullo o negativo. La stabilità vince sulla micro‑ottimizzazione: meglio una sessione fluida su TCP che una più “scattante” ma soggetta a freeze su UDP.

FAQ

Devo disattivare l’UDP anche sul server?
Non necessariamente. Nella maggior parte dei contesti è sufficiente la policy Turn Off UDP On Client, che forza i client aziendali ad andare in TCP puro. Se vuoi chiudere ogni via, imposta Select RDP transport protocols = Use only TCP sui Session Host.

E se uso RD Gateway?
L’RDP può sfruttare UDP anche attraverso RD Gateway (porta 3391). Se vuoi garantire coerenza, disabilita l’UDP lato client (come sopra) o, in aggiunta, disattiva il trasporto UDP nelle impostazioni del Gateway.

Gli utenti da Mac/iOS/Android?
I client Microsoft per queste piattaforme supportano UDP. Se hai freeze su questi dispositivi, applica un criterio simile (quando disponibile) o forza TCP lato server/Gateway.

Come misuro il miglioramento?
Confronta: numero di riconnessioni RDP, reclami su freeze, errori nei log RdpCoreTdx, e stabilità percepita nelle fasce orarie critiche.

Roadmap di rollout consigliata

Pilot: abilita Turn Off UDP On Client su un gruppo di test (utenze maggiormente colpite).
Validazione: monitora log, feedback utenti e KPI (freeze/riconnessioni) per 5‑7 giorni.
Rollout: estendi la GPO a tutta l’OU dei client; programma eventuali riavvii.
Hardening: valuta l’allineamento di patch, driver grafici e timeout RDS; rivedi QoS/SD‑WAN.
Stabilizzazione: lascia i contatori attivi per osservare trend a medio termine.

Checklist operativa

☑ Policy Turn Off UDP On Client abilitata e applicata ai client interessati.
☑ fClientDisableUDP=1 presente a registro sui client.
☑ Verifica log TerminalServices‑ClientActiveXCore / RdpCoreTdx per sessioni solo TCP.
☑ Ping/PathPing: nessuna perdita anomala; MTU coerente lungo il percorso.
☑ Timeout Idle/Active/Disconnected calibrati nella Collection RDS.
☑ Driver grafici e OS aggiornati (client e server).
☑ Profili utente “problematici” ricreati dove necessario.

Appendice: esempi di comandi utili

PowerShell – impostare/controllare la chiave di registro lato client

# Eseguire come amministratore sul client
$path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client"
if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
New-ItemProperty -Path $path -Name "fClientDisableUDP" -PropertyType DWord -Value 1 -Force | Out-Null
Write-Host "UDP disabilitato per RDP sul client."

PowerShell Remoting – applicazione rapida a più PC

# Richiede WinRM abilitato e permessi adeguati
$computers = @("PC001","PC002","PC003")
Invoke-Command -ComputerName $computers -ScriptBlock {
  $p = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client"
  if (-not (Test-Path $p)) { New-Item -Path $p -Force | Out-Null }
  New-ItemProperty -Path $p -Name "fClientDisableUDP" -PropertyType DWord -Value 1 -Force | Out-Null
  gpupdate /force | Out-Null
  "[$env:COMPUTERNAME] fClientDisableUDP impostato a 1"
}

CMD – verifica MTU lungo il percorso

REM Riduci -l finché il ping passa senza frammentare
ping -f -l 1472 nomeoipdelserver

Gestione sessioni dal server

quser /server:nomehost
logoff &lt;ID_SESSIONE&gt; /server:nomehost

Quando (e come) tornare a UDP

Se dopo interventi su rete/SD‑WAN vuoi riesplorare l’UDP per ottenere la massima fluidità, procedi così:

Ripristina la policy (mettila su Not Configured o Disabled e fai gpupdate + riavvio).
Misura con attenzione (log client, contatori, feedback utenti) per almeno una settimana.
Se ricompaiono freeze, torna a TCP only. In infrastrutture miste, puoi valutare scoping della GPO per escludere sedi con rete “buona”.

Diagnostica avanzata (opzionale)

Eventi approfonditi: abilita i canali Microsoft‑Windows‑TerminalServices‑ClientActiveXCore e RemoteDesktopServices‑RdpCoreTdx per registrare drop/timeout a livello di protocollo e cambio di trasporto.
Packet capture: con strumenti come netsh trace o analizzatori di rete, filtra su udp.port == 3389 (o 3391 con RDG) per verificare perdita/riordinamento.
QoS/DSCP: verifica che UDP e TCP di RDP non siano in classi differenti; allinea le policy su tutti i segmenti.

Conclusioni

Quando gli utenti vedono schermate RDP bloccate ma l’admin in shadowing osserva una sessione fluida, la radice del problema quasi sempre è nel trasporto UDP lungo la rete. Forzare RDP su TCP con la policy Turn Off UDP On Client è un intervento semplice, reversibile e, nella pratica, risolutivo. Completando il lavoro con le verifiche di rete, aggiornamenti e un tuning ragionato dei timeout, otterrai sessioni RDS stabili e una percezione d’affidabilità nettamente superiore da parte degli utenti.

Perché UDP in RDP?
Da Windows Server 2012 e client RDP 8 in poi, RDP utilizza un canale UDP per ottimizzare audio/video e input su connessioni veloci; in ambienti con firewall o dispositivi di sicurezza che manipolano i pacchetti, il flusso UDP può degradarsi causando freeze.

Diagnostica avanzata
Abilita gli eventi Microsoft‑Windows‑TerminalServices‑ClientActiveXCore e RemoteDesktopServices‑RdpCoreTdx nel Visualizzatore eventi per registrare drop o timeout a livello di protocollo e confermare eventuali fallback da UDP a TCP.

Risultato riportato
Dopo l’applicazione della policy Turn Off UDP On Client non sono stati registrati ulteriori blocchi, confermando che la soluzione ha risolto il problema nel contesto descritto.