RDP si disconnette subito su Windows Server 2019: diagnosi completa e soluzioni

RDP su Windows Server 2019 si connette e si chiude subito? Questa guida pratica ti accompagna, passo dopo passo, nel diagnosticare e risolvere le disconnessioni immediate su un server Windows Server 2019 Desktop Experience in VM VMware 7.0.3, senza link esterni né giri a vuoto.

Indice

Scenario e sintomi

Fino a ieri tutto funzionava: tutti gli utenti accedevano senza problemi al server Windows Server 2019 (Desktop Experience) ospitato su VMware 7.0.3. Da un giorno all’altro, la sessione RDP sembra partire, ma si chiude subito. Il riavvio non ha aiutato e gli utenti appartengono correttamente al gruppo Remote Desktop Users. Questo comportamento è tipico quando qualcosa rompe la catena di handshake (NLA/TLS/CredSSP), le policy applicate contengono vincoli errati, le licenze RDS sono scadute o il sistema è a corto di risorse o afflitto da filtri di rete.

Perché accade: la catena RDP in breve

Quando un client si collega via RDP, la sequenza semplificata è questa:

Negoziazione trasporto: TCP 3389 (e, se abilitato, UDP 3389). Possibili filtri/MTU/UDP che fanno cadere la sessione.
TLS/SChannel: handshake crittografico, certificato server, suite di cifratura. Certificati scaduti o policy FIPS/cipher incongrue interrompono subito la connessione.
NLA/CredSSP: autenticazione a livello di rete (Kerberos/NTLM). Se fallisce, il client vede un “connessione chiusa” senza dettagli.
Broker locale (LSM/RCM): allocazione della sessione, verifica licenze RDS, limiti e timeout GPO.
Desktop: avvio shell grafica. Se il sistema è saturo o il driver grafico è problematico, la sessione muore.

Checklist rapida (da fare subito)

Passo	Cosa fare	Perché è utile
Esaminare i log eventi RDP	Controllare i registri: • `Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS / Operational` • `Terminal‑Services‑RemoteConnectionManager / Operational` • `TerminalServices‑LocalSessionManager / Operational` • `Registro Sicurezza`	I codici di disconnessione e gli ID evento indicano la causa (CredSSP/TLS, licenze, risorse, NLA).
Test di rete	`ping`, `tracert`, `Test‑NetConnection`, esame impostazioni NIC della VM	Esclude latenza, perdita di pacchetti o filtri firewall che chiudono la sessione.
Monitoraggio risorse	Task Manager o Performance Monitor durante un tentativo di login	Picchi o saturazioni di CPU/RAM possono far terminare il processo RDS.
Controllo criteri di gruppo RDS	GPO: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host (schede Connections e Security)	Impostazioni errate (timeout, cifratura obbligatoria, limiti di sessione) possono causare disconnect immediati.
Disabilitare temporaneamente NLA	Rimuovere il requisito da System Properties → Remote o via GPO/registro	Se NLA/TLS falliscono, la sessione si chiude senza spiegazioni lato client.

Procedura completa, spiegata bene

Controllo eventi: dove guardare e come leggerli

Apri Event Viewer sulla console VMware (non via RDP) e verifica i seguenti canali:

RdpCoreTS/Operational: segnala errori del trasporto e disconnessioni immediate, incluso il codice di motivo (disconnect reason code).
RemoteConnectionManager/Operational: gestisce connessioni e logon; utile per problemi di licenza e di limiti.
LocalSessionManager/Operational: crea e termina sessioni; vedi tentativi di avvio desktop falliti.
Windows Logs → Security: cerca 4625 (logon fallito), con dettagli su account bloccato, password scaduta, mancati diritti “Allow log on through RDS”, time‑skew Kerberos.
Windows Logs → System → Schannel: eventi critici di TLS/handshake/certificati (tipicamente 36874/36888/36886).

PowerShell per raccogliere rapidamente i principali eventi degli ultimi 24h:

# Avvia in console locale o PowerShell remoting via Console VMware
$since = (Get-Date).AddHours(-24)
$logs = @(
  'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational',
  'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational',
  'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational',
  'Security',
  'System'
)
foreach ($log in $logs) {
  Write-Host "===== $log =====" -ForegroundColor Cyan
  Get-WinEvent -FilterHashtable @{ LogName = $log; StartTime = $since } |
    Where-Object { $_.LevelDisplayName -in 'Error','Warning' } |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message |
    Format-Table -AutoSize
}

Cosa cercare:

Messaggi “handshake TLS fallito” → certificato scaduto/non valido, ciphers troppo restrittivi, TLS 1.2 obbligatorio con client vecchi.
Eventi che citano licensing o grace period → RD Licensing non configurato o scaduto; i logon vengono chiusi subito.
Evento 4625 con status come 0xC000006D/0xC000006A (credenziali errate), 0xC0000234 (account bloccato), 0xC0000072 (account disabilitato), 0xC0000193 (password scaduta). Time‑skew Kerberos si riconosce spesso da motivazioni legate alla preautenticazione.

Test di rete mirati

La rete può troncare la sessione senza apparenti errori lato client. Esegui questi controlli:

# Dal client verso il server
Test-NetConnection -ComputerName SERVER2019 -Port 3389 -InformationLevel Detailed

Sul server: ascolto porte RDP

netstat -ano | findstr 3389

Rileva firewall locali

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select-Object DisplayName, Enabled, Direction, Action |
Format-Table -AutoSize

Traccia ICMP e instradamento

ping SERVER2019
tracert SERVER2019

Verifica MTU/PathMTU sospetti (se VPN)

netsh interface ipv4 show subinterfaces

Nota VMware/VMXNET3: in presenza di disconnect misteriosi, prova temporaneamente a disattivare Large Send Offload, Checksum Offload e RSS sulla NIC della VM:

# Elenca proprietà avanzate
Get-NetAdapterAdvancedProperty -Name "Ethernet"

Esempio: disattiva LSO

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

Se sospetti problemi con l’UDP (NAT o MTU), forza il solo TCP via GPO: Remote Desktop Session Host → Connections → Select RDP transport protocols → Enabled e Use TCP only.

Monitoraggio risorse in tempo reale

Apri il Task Manager dalla console VMware e guarda CPU, RAM, disco e scheda “Utenti” al momento del tentativo di login. In alternativa, usa Performance Monitor con questi contatori:

Processor(_Total)\% Processor Time
Memory\Available MBytes
PhysicalDisk\Avg. Disk sec/Read e /Write
Terminal Services counters (sessioni attive/disconnesse)

Se vedi spike o saturazioni costanti, investi su: riduzione servizi, ampliamento vCPU/RAM, cleanup di antivirus o agent con impatto su logon.

Verifica criteri RDS e diritti utente

Apri gpedit.msc o controlla le GPO di dominio:

Connections:
- Limit number of connections → impostalo su Not Configured o un numero sufficiente.
- Set time limit for disconnected sessions / active but idle → evita valori troppo aggressivi.
- Select RDP transport protocols → prova Use TCP only per escludere problemi UDP.
Security:
- Require user authentication for remote connections by using NLA → prova Disabled temporaneamente per diagnosticare CredSSP.
- Require use of specific security layer for remote (RDP) connections → Negotiate o SSL; evita RDP puro salvo test.
- Set client connection encryption level → Client Compatible nella maggior parte dei casi.
- System cryptography: Use FIPS compliant algorithms (in Security Options) → se Enabled può rompere ciphers/TLS.

Controlla anche i diritti locali (secpol.msc → Local Policies → User Rights Assignment):

Allow log on through Remote Desktop Services deve includere Administrators e/o Remote Desktop Users.
Deny log on through Remote Desktop Services non deve includere gli utenti interessati o gruppi ampi.

Report GPO veloce:

gpresult /h C:\Temp\RDP-GPO.html

Disabilitare NLA in sicurezza (solo per test)

Se l’handshake NLA è il problema, la sessione si chiude subito. Disattiva temporaneamente NLA per isolare la causa. Dalla console:

Apri SystemPropertiesRemote.exe → deseleziona “Consenti solo connessioni da computer che eseguono Desktop remoto con NLA”.
Oppure via registro/PowerShell:

Set-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name 'UserAuthentication' -Value 0

Riavvia servizio RDS per applicare

Stop-Service TermService -Force
Start-Service TermService

Se ora la connessione resta aperta, il problema è in TLS/CredSSP/certificato.

Servizi RDS e dipendenze

Assicurati che i servizi siano in stato Running e Automatic:

Get-Service TermService, UmRdpService, SessionEnv, Tsshutdn |
  Select-Object Name, Status, StartType

Se TermService non parte, controlla log System e RdpCoreTS. Antivirus/EDR aggressivi o driver grafici possono impedirne l’avvio.

Patch recenti e rollback mirato

Molti casi nascono da update di sicurezza su CredSSP/TLS/SChannel. Elenca gli aggiornamenti installati negli ultimi giorni:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20 Source, Description, HotFixID, InstalledOn

Se la timeline coincide con l’inizio dei problemi, prova disinstallazione mirata o rollback snapshot su ambiente di test per confermare la correlazione. Evita rimozioni indiscriminate: valuta impatti e dipendenze.

Certificato RDP: verifica e rigenerazione

Il servizio RDS usa un certificato server. Se scaduto, mancante o non corrisponde all’hash configurato, l’handshake TLS fallisce.

Leggi l’hash configurato per RDP:

$thumb = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name SSLCertificateSHA1Hash).SSLCertificateSHA1Hash -join ''
$thumb

Confronta col certificato in Local Computer\Personal:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Thumbprint -replace ' ' -eq $thumb } |
  Select-Object Subject, NotAfter, Thumbprint

Se manca o è scaduto, riassegna/rigenera:
- Importa un certificato valido (CN=FQDN del server) e imposta la chiave privata esportabile.
- Oppure elimina l’entry obsoleta e lascia che Windows rigeneri il self‑signed “Remote Desktop”.

In ambienti con ruolo RD Session Host o collezioni, usa la procedura guidata Select Remote Desktop Services SSL certificate o imposta via GPO la selezione del certificato per Remote Desktop.

Licenze RDS: la “grace period” è finita?

Senza un server licenze configurato, un RD Session Host concede un periodo di 120 giorni. Alla scadenza, molti client vedono la connessione chiudersi subito dopo l’autenticazione. Segnali:

Eventi in RemoteConnectionManager che indicano la scadenza della grace period o l’impossibilità di contattare un license server.
Messaggi del Licensing Diagnoser sul server.

Correzione corretta (consigliata):

Installa il ruolo Remote Desktop Licensing su un server idoneo.
Attiva le CAL e configura in GPO:
- Use the specified Remote Desktop license servers → FQDN del server licenze.
- Set the Remote Desktop licensing mode → Per User o Per Device.

Nota: non affidarti a “workaround” sul registro per ripristinare la grace. Va risolto alla radice configurando correttamente il licensing.

Console VMware: la prova del nove

Apri la console vSphere/ESXi e prova l’accesso locale. Se la GUI risponde, Explorer si avvia e il server è utilizzabile, i problemi sono circoscritti al percorso RDP (rete, TLS, NLA, policy). Se nemmeno la console è fluida, indaga su risorse/driver/servizi.

Sessioni bloccate o “zombie”

Sessioni disconnected in stato anomalo possono impedire nuovi logon (specialmente con limiti GPO severi). Sulla console:

qwinsta
Trova ID sessione > reset forzato
reset session <ID>

Oppure via PowerShell

quser
logoff  /server:localhost

Sicurezza aggiuntiva, agent e provider credenziali

Soluzioni MFA/SSO, EDR e provider di credenziali di terze parti integrati con NLA possono causare drop dopo update. Indizi: la disconnessione avviene dopo inserimento credenziali e non vedi desktop. Prova a:

Aggiornare l’agent alla stessa build del driver NLA supportato.
Disattivare temporaneamente l’agent (solo in finestra di manutenzione) per isolare la causa.

Tempo/ora e Kerberos

Uno scarto orario > 5 minuti tra server e controller di dominio rompe Kerberos e quindi NLA. In ambiente VMware, la time‑sync errata è frequente.

w32tm /query /status
w32tm /resync
Verifica NTP su DC e host ESXi; evita doppia sincronizzazione (Guest+VMware Tools).

Hardening TLS/SChannel

Se hai disabilitato TLS 1.0/1.1 o rimosso cipher suite legacy, assicurati che i client utilizzino TLS 1.2 e cipher supportati. Con FIPS attivo, alcune suite non sono disponibili e i client vecchi falliscono l’handshake. Per test rapidi, ripristina a un set compatibile e poi restringi gradualmente.

Grafica RDP: WDDM vs XDDM

Driver grafici problematici possono chiudere la sessione dopo la fase di logon. Prova a disabilitare l’uso del driver WDDM per le sessioni RDS:

# GPO: Remote Desktop Session Host → Remote Session Environment
"Use WDDM graphics display driver for Remote Desktop Services Sessions" → Disabled

Il fallback al driver legacy può stabilizzare l’ambiente (utile su VM con driver video non perfetti).

Playbook operativo: dal sintomo alla diagnosi

Segnale/Evento	Probabile causa	Azione consigliata
Disconnessione immediata, Security 4625 con account ok	NLA/CredSSP/TLS	Disabilita NLA per test, verifica certificato RDP, controlla Schannel e time‑sync.
Eventi su licensing / grace period scaduta	Licenze RDS non configurate	Installa RD Licensing, configura license server e modalità, applica GPO.
Client dietro VPN/SD‑WAN, UDP problematico	MTU/NAT/UDP 3389 bloccato	Forza “TCP only” via GPO; verifica MTU; controlla firewall.
Picchi CPU/RAM durante logon	Risorse insufficienti o agent	Aumenta risorse, ottimizza servizi/AV, verifica driver grafici.
Schannel 36888/36874	Certificato/cipher/TLS incompatibili	Rigenera/assegna certificato valido; rivedi hardening TLS.
Connessione attiva solo per amministratori	Diritti utente/GPO	Allow/Deny log on through RDS corretti; controlla RDP‑Tcp “Permissions”.

Comandi utili “copia e incolla”

# 1) Verifica servizio RDS
sc query TermService

2) Abilita log di debug di RDP Core (temporaneo, solo se necessario)

Event Viewer → aumentare livello diagnostico (attenzione al rumore)

3) Forza solo TCP (GPO locale, via registro)

New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' `
-Name 'TransportPolicy' -PropertyType DWord -Value 1 -Force

4) Riavvia i servizi RDS in modo ordinato

Stop-Service UmRdpService -Force
Stop-Service TermService -Force
Start-Service TermService
Start-Service UmRdpService

5) Elenco sessioni e reset

qwinsta
reset session 

6) Test porta 3389 dal server su se stesso (loopback)

Test-NetConnection -ComputerName localhost -Port 3389

7) Firewall "Remote Desktop" rapido

Get-NetFirewallRule -DisplayGroup "Remote Desktop" | ft DisplayName, Enabled, Direction, Action -Auto

8) Esporta report GPO effettive

gpresult /h C:\Temp\RDP-GPO.html

9) Verifica ora/Kerberos

w32tm /query /status
w32tm /resync

10) Controlla attività Security 4625

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
Select-Object TimeCreated, Message | more

Controlli sul lato client

Usa mstsc.exe aggiornato (Windows 10/11 recenti). Abilita “Non salvare credenziali” per escludere cache corrotte.
Verifica che il client supporti TLS 1.2. Su client legacy, abilitalo nelle opzioni Internet/registro.
Se il client è dietro firewall stretto, consenti TCP 3389 (e UDP 3389 se usato).

Best practice preventive

Licensing: configura il server licenze RDS prima che la piattaforma entri in produzione; monitora la scadenza CAL.
Certificati: usa certificati validi (CN=FQDN) con rinnovo automatico e monitoraggio scadenze.
Patch management: test in ambiente staging per update che toccano TLS/SSP/cred provider.
Hardening misurato: applica SChannel/cipher policy con rapida possibilità di rollback.
Osservabilità: centralizza i log RDP/SChannel/Security; allerta su pattern di disconnect.
VMware Tools e driver: mantieni aggiornati; verifica periodicamente NIC e opzioni offload.
Time‑sync: una sola fonte autorevole (NTP) per host e guest; evita doppie sincronizzazioni.

Sequenza consigliata “in produzione”

Accedi da console VMware (mai fare troubleshooting di RDP “via RDP”).
Event Viewer: salva un pacchetto di log di 24–48h.
Disabilita NLA (solo test) e prova: se funziona, focalizza su TLS/cert/NLA.
Forza TCP‑only e riprova: se funziona, c’è un problema su UDP/MTU/NAT.
Licensing: esegui Diagnoser e conferma configurazione server licenze e modalità CAL.
Certificato: rigenera/riassegna; controlla SSLCertificateSHA1Hash.
Policy: rivedi Connections/Security, diritti Allow/Deny log on through RDS.
Risorse/driver: controlla CPU/RAM/disk, prova WDDM → Disabled per RDS.
EDR/MFA: aggiorna/pausa test; isola componente difettoso.

FAQ rapide

Perché vedo “Verifica identità…” e poi la finestra si chiude?
Quasi sempre è NLA/TLS. Un certificato invalidato o un’incompatibilità di ciphers interrompe l’handshake: il client non mostra errori dettagliati e la sessione termina.

Gli amministratori accedono, gli utenti no. Perché?
Controlla i diritti Allow/Deny log on through RDS e limiti GPO su sessioni/timeout. Anche la scadenza licenze RDS può influire diversamente in base al tipo di CAL.

Posso “risolvere” cancellando la chiave di grace period nel registro?
Non è raccomandato. La soluzione stabile è configurare correttamente il server licenze e la modalità CAL.

Disabilitare NLA è sicuro?
Solo come test diagnostico temporaneo. Ripristina NLA appena individuata la causa. NLA riduce notevolmente i rischi di attacchi a RDP.

Esempio di script di raccolta diagnostica

Questo script PowerShell (da console) raccoglie log e informazioni chiave in C:\Temp\RDP-Diagnostica:

$out = 'C:\Temp\RDP-Diagnostica'
New-Item -Path $out -ItemType Directory -Force | Out-Null

Eventi principali (48h)

$since = (Get-Date).AddHours(-48)
$channels = @(
'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational',
'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational',
'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational',
'Security','System'
)
foreach ($c in $channels) {
Get-WinEvent -FilterHashtable @{LogName=$c; StartTime=$since} |
Export-Clixml -Path (Join-Path $out ("{0}.xml" -f ($c -replace '[\/]','-')))
}

Stato servizi

Get-Service TermService,UmRdpService,SessionEnv | Export-Csv (Join-Path $out 'servizi.csv') -NoTypeInformation

Firewall RDP

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select DisplayName, Enabled, Direction, Action |
Export-Csv (Join-Path $out 'firewall.csv') -NoTypeInformation

Info certificato RDP

$thumb = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name SSLCertificateSHA1Hash).SSLCertificateSHA1Hash -join ''
"RDP Cert Thumbprint: $thumb" | Out-File (Join-Path $out 'cert.txt')

GPO risultanti

gpresult /h (Join-Path $out 'gpresult.html')

Ora/NTP

w32tm /query /status | Out-File (Join-Path $out 'w32tm.txt')

Sessioni

qwinsta | Out-File (Join-Path $out 'sessioni.txt')

Conclusioni e sintesi

La disconnessione immediata delle sessioni RDP su Windows Server 2019 è quasi sempre la spia di un errore in fase di handshake (TLS/NLA/CredSSP), di una configurazione GPO troppo restrittiva, di licenze RDS scadute/non configurate o di problemi di rete/risorse. Un approccio sistematico — log eventi mirati, test di rete e trasporto (forzare TCP), verifica di NLA/certificati, servizi e licensing — consente di individuare la causa primaria e ripristinare l’accesso remoto in tempi rapidi.

Appendice: controlli “uno‑shot”

NLA OFF, test → funziona? Colpevole NLA/TLS/cert.
TCP‑only → funziona? Colpevole UDP/MTU/NAT.
Licensing Diagnoser pulito → esclude grace scaduta.
Schannel senza errori → esclude TLS/cert.
Security 4625 assente → autentica OK, guarda risorse/driver.

Sintesi finale. La disconnessione immediata in RDP è tipicamente legata a errori di autenticazione (NLA/TLS), risorse insufficienti, configurazioni di criteri, licenze RDS o problemi di rete. Un’analisi mirata dei log eventi, seguita da test di rete e verifica di policy, servizi e certificati, permette di individuare la causa primaria e ripristinare l’accesso remoto al server.

Checklist finale

Event Viewer: RdpCoreTS, RCM, LSM, Security, Schannel.
Test‑NetConnection 3389, firewall RDP “On”, TCP‑only se necessario.
NLA OFF per test, poi ON con certificato valido.
GPO Connections/Security verificate, diritti RDS corretti.
Licensing configurato, CAL attive.
Sessioni zombie resettate, risorse OK.
Time‑sync corretto, VMware Tools aggiornati.