RDP “No Response From Server” su Windows Server 2022: causa, diagnosi e fix definitivo

Se durante l’accesso in Desktop Remoto a Windows Server 2022 la sessione parte ma dopo 10–15 s compare “No Response From Server”, qui trovi una diagnosi completa e una soluzione reale: nel caso descritto il colpevole era un Logon Agent MFA non configurato che bloccava il provider credenziali.

Indice

Panoramica del problema

In alcuni ambienti Windows Server 2022 on‑premises può capitare che il client RDP stabilisca la sessione, mostri per alcuni secondi la schermata di logon, quindi interrompa l’handshake con il messaggio “No Response From Server”. Il comportamento è subdolo: rete e condivisioni SMB funzionano, l’host risponde al ping, le risorse non risultano saturate, e — dettaglio ancor più fuorviante — con un tool di remote desktop di terze parti l’accesso procede regolarmente con le stesse credenziali.

Il caso reale descritto qui riguarda un server fisico Windows Server 2022 e due VM Hyper‑V sullo stesso host. I server in cloud, con immagine più pulita, non mostravano alcuna anomalia. L’analisi dei log ha evidenziato, nel canale TerminalServices‑LocalSessionManager / Operational, avvisi del tipo:

RDP_SEC: An error was encountered when transitioning from FStatePassthrough … 0x8007139F
“The network characteristics detection function has been disabled because of Reason Code: 2 (Server Configuration)”

La risoluzione effettiva è stata la disinstallazione completa di SecurEnvoy Windows Logon Agent, componente destinato a introdurre un fattore di autenticazione aggiuntivo ma mai configurato correttamente. Rimossa la componente, l’RDP ha ripreso a funzionare immediatamente su host fisico e VM.

Contesto e sintomi osservati

Durata: la disconnessione avviene 10–15 s dopo la comparsa della schermata di logon.
Ambiente: Windows Server 2022 (host fisico e VM Hyper‑V). Nessun problema su istanze cloud con build standard.
Controprova: con un software di assistenza remota di terze parti (non basato su RDP) l’accesso funziona al primo colpo usando le stesse credenziali.
Log: nessun errore critico nei registri System e Application; avvisi nel canale TerminalServices‑* come riportato sopra.
Verifiche preliminari: RDP abilitato, utenze autorizzate, NLA disattivato per prova, Windows Firewall temporaneamente disabilitato: nessun cambiamento.

Perché il client RDP mostra “No Response From Server”

Quando apri una sessione RDP, lato server avvengono più passaggi in rapida sequenza:

Stabilisce la connessione TCP e lo scambio TLS.
Avvia l’autenticazione (NLA/CredSSP o fallback) e prepara la LogonUI.
Carica i Credential Provider registrati nel sistema per presentare i metodi di accesso (password, smart card, PIN, MFA, ecc.).
Consegna al client la schermata di logon e attende l’input/risposta.

Se un Credential Provider di terze parti intercetta il flusso e rimane in stato “indeterminato” (ad esempio perché non è configurato, non contatta il suo backend MFA o entra in timeout), la LogonUI non completa il ciclo e il client interpreta l’assenza di risposta come “No Response From Server”. Da qui gli avvisi “transitioning from FStatePassthrough” nel log del Local Session Manager: il server resta bloccato in una fase intermedia del cambio di stato.

Diagnosi dettagliata

Verifiche di base effettuate

RDP abilitato: fDenyTSConnections = 0 e regole firewall attive.
Autorizzazioni: l’utente appartiene ai gruppi permessi per RDP (Remote Desktop Users o equivalenti)
NLA: test sia con NLA attivo sia disattivato.
Firewall: disattivazione temporanea per escludere filtri.
Rete: ping e SMB ok, nessun packet loss, latenze nella norma.
Risorse: CPU, RAM e I/O ampiamente sotto soglia; nessuna pressione sul commit.

Analisi Event Viewer

Per ottenere segnali utili, abilita i canali Operational di Remote Desktop Services:

wevtutil sl Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /e:true
wevtutil sl Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational /e:true
Get-WinEvent -LogName Microsoft-Windows-TerminalServices-LocalSessionManager/Operational -MaxEvents 50 ^
| Format-List TimeCreated, Id, LevelDisplayName, Message

I messaggi ricorrenti nel caso analizzato erano:

RDP_SEC: An error was encountered when transitioning from FStatePassthrough … 0x8007139F
The network characteristics detection function has been disabled because of Reason Code: 2 (Server Configuration)

Il secondo è un avviso informativo legato alla configurazione: non è il colpevole. Il primo, invece, è sintomo di uno stallo nella pipeline di autenticazione.

Ipotesi scartate

Problemi di rete: esclusi da ping, SMB e monitor delle interfacce.
Conflitti firewall: esclusi dalla disabilitazione temporanea e dai log.
Esaurimento risorse: metriche nella norma; nessun evento OOM.

La causa radicata

Sull’host fisico e sulle VM era stato installato in passato SecurEnvoy Windows Logon Agent per introdurre un fattore di autenticazione aggiuntivo, ma mai configurato. Il suo Credential Provider restava registrato nel sistema e si attivava alla preparazione della LogonUI, bloccando il flusso in attesa di una configurazione che non arrivava. Rimosso l’agente, la sessione RDP è tornata immediatamente operativa.

Casi simili possono verificarsi con altri agent di MFA o controllo accessi lato logon (Duo, Okta Credential Provider, RSA, servizi di controllo remoto che installano driver di hook sulla desktop session, ecc.). Il tratto comune è l’inserimento di un provider credenziali o di un filtro che partecipa alla fase di logon remoto.

Procedura di risoluzione consigliata

Accesso di emergenza

Se l’RDP è bloccato, accedi da console Hyper‑V (o KVM/iLO/iDRAC, oppure fisicamente). Evita interventi al buio: serve almeno una sessione locale per agire in sicurezza.

Individuare agent di logon installati

Dal server, elenca rapidamente software potenzialmente coinvolti senza usare classi WMI che innescano repair MSI:

$paths = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$apps = foreach($p in $paths){ Get-ItemProperty $p -ErrorAction SilentlyContinue }
$apps | Where-Object { $_.DisplayName -match 'SecurEnvoy|Duo|Okta|RSA|Auth|Credential|Remote' } |
  Select-Object DisplayName, Publisher, DisplayVersion, InstallDate, UninstallString

Controlla anche i Credential Provider registrati:

$cpRoot='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers'
Get-ChildItem $cpRoot | ForEach-Object {
  $guid=$_.PSChildName
  $clsid="HKLM:\SOFTWARE\Classes\CLSID\$guid"
  $name=(Get-ItemProperty -Path $clsid -ErrorAction SilentlyContinue).'(Default)'
  [pscustomobject]@{ GUID=$guid; Name=$name }
} | Sort-Object Name | Format-Table -AutoSize

Vedere un provider riconducibile a un agente MFA non configurato è un indizio pesante.

Rimozione pulita dell’agente

Backup: crea un punto di ripristino o, più realisticamente su server, uno snapshot/Checkpoint Hyper‑V della VM interessata. Esporta anche le chiavi di registro dei provider: reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers" C:\Temp\cp.reg.
Disinstalla dall’apposito pannello o via riga di comando usando l’UninstallString rilevata. Esempio per pacchetto MSI: msiexec /x {PRODUCT-CODE} /qn /norestart.
Riavvia il servizio TermService o, se richiesto, l’intero server.

Verifica post‑fix

Conferma che la chiave del provider terzo non sia più presente sotto Credential Providers.
Controlla che RDP sia attivo e le regole firewall siano abilitate: Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0 Enable-NetFirewallRule -DisplayGroup "Remote Desktop" Get-Service -Name TermService | Select Status, StartType
Apri una sessione RDP da un client noto: l’accesso dovrebbe riuscire immediatamente.

Workaround d’emergenza se non puoi disinstallare subito

In scenari critici, quando non è possibile rimuovere l’agente all’istante, puoi tentare un disable temporaneo solo se hai accesso console e dopo aver preso un backup del registro:

Esporta la chiave Credential Providers come sopra.
Individua la sottochiave del provider di terze parti e rimuovila temporaneamente (o rinominala) per escluderla dal caricamento.
Riavvia TermService. Se l’accesso torna operativo, pianifica la rimozione completa del prodotto.

Nota: la gestione diretta dei provider è un’operazione avanzata; preferisci sempre la disinstallazione ufficiale del vendor.

Tabella riassuntiva della diagnosi

Segnale	Interpretazione	Azione consigliata
RDP si avvia e dopo 10–15 s cade con “No Response From Server”	Timeout/impasse nella pipeline di logon	Ispeziona Credential Provider attivi e agent di logon
Log LSM: “FStatePassthrough … 0x8007139F”	Errore in transizione di stato durante l’autenticazione	Verifica provider terzi e componenti MFA
Ping e SMB funzionano	Rete e firewall non sono la causa principale	Concentra l’analisi su logon e credenziali
Terze parti di remote desktop funzionano	Bypassano la pipeline CP di Windows	Conferma ipotesi: problema sul provider di logon
Server cloud ok, on‑prem no	Build diversa, agent non presenti in cloud	Confronta inventario software e provider

Approfondimento tecnico

Il Windows Logon Agent di prodotti MFA registra un Credential Provider (CP) COM, che si presenta a LogonUI con un set di tile e flussi d’autenticazione. In RDP, la LogonUI gira nella sessione 0 e orchestrata dal Local Session Manager e da Winlogon. Se il CP non è inizializzato o attende un backend non raggiungibile, il suo GetSerialization/AuthenticateUser può non restituire risposta utile: il server non ha credenziali serializzate da inoltrare a LSA, la UI resta bloccata e il client vede l’assenza di risposta.

Questo spiega perché lo stesso utente, con lo stesso account, riesce ad accedere mediante strumenti di controllo remoto che installano propri servizi/driver e instaurano sessioni indipendenti dall’RDP e dalla LogonUI.

Casi analoghi

Provider MFA non configurati o parzialmente rimossi (Duo, Okta, RSA, Entrust, ecc.).
Software di supporto remoto che inserisce driver di hook sulla desktop session e si integra con Winlogon.
Filtri Credential Provider personalizzati lasciati in ambiente dopo test incompleti.

Buone pratiche di prevenzione

Inventario software: monitora con regolarità la presenza di agent di autenticazione sui server RDP‑enabled e documenta finalità, versione, stato di configurazione.
Change management: qualunque soluzione MFA deve passare da un ambiente di staging con test di logon locale e RDP, inclusi scenari di rollback.
Event Viewer proattivo: mantieni attivi i canali Analytic e Debug dei componenti TerminalServices‑* durante le finestre di rilascio per cogliere anomalie dell’handshake RDP.
Rollback rapido: per ogni Credential Provider di terze parti prevedi una procedura d’emergenza: accesso console Hyper‑V o fisico, script di disinstallazione, chiavi di registro da ripristinare.
Baseline: conserva una build di riferimento “pulita” (gold image) per confronto rapido di servizi, provider e pacchetti.

Checklist operativa

RDP attivo e regole firewall in stato Enabled.
Abilita log TerminalServices‑* e acquisisci gli eventi durante un tentativo di accesso fallito.
Elenca applicazioni e provider credenziali installati; cerca agent di logon/MFA.
Disinstalla l’agente sospetto e riavvia TermService.
Verifica accesso RDP da un client affidabile.
Documenta la modifica e pianifica eventuale re‑introduzione controllata del MFA.

Comandi utili

Stato RDP e regole firewall

(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server').fDenyTSConnections
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Log RDP

wevtutil sl Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /e:true
wevtutil sl Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational /e:true
Get-WinEvent -LogName Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational -MaxEvents 50 ^
| Format-List TimeCreated,Id,LevelDisplayName,Message

Elenco provider credenziali

$cpRoot='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers'
Get-ChildItem $cpRoot | ForEach-Object {
  $guid=$_.PSChildName
  $clsid="HKLM:\SOFTWARE\Classes\CLSID\$guid"
  $name=(Get-ItemProperty -Path $clsid -ErrorAction SilentlyContinue).'(Default)'
  [pscustomobject]@{ GUID=$guid; Name=$name }
} | Sort-Object Name | Out-GridView

Scansione disinstallazioni

$uninstallPaths=@(
 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$apps = foreach($p in $uninstallPaths){ Get-ItemProperty $p -ErrorAction SilentlyContinue }
$apps | Where-Object { $_.DisplayName -match 'SecurEnvoy|Duo|Okta|RSA|Auth|Credential' } |
  Select DisplayName,DisplayVersion,Publisher,UninstallString | Format-Table -Auto

Verifica servizi RDP

Get-Service -Name TermService | Select-Object Status,StartType
Get-Process -Name logonui -IncludeUserName

Domande frequenti

Disattivare NLA risolve?
Non necessariamente. Se il blocco avviene nel caricamento dei Credential Provider, la disattivazione di NLA non rimuove la causa: al massimo cambia la fase in cui si manifesta.

Perché i log dicono “network characteristics detection function disabled”?
È un avviso legato alla configurazione del server. Non è un errore bloccante; segnala funzioni di ottimizzazione/telemetria disattivate per policy.

Perché con un tool di terze parti entro senza problemi?
Perché molti strumenti di controllo remoto instaurano sessioni attraverso i propri servizi/driver e non passano dalla pipeline RDP+LogonUI+Credential Provider di Windows.

Posso rimuovere i provider a mano dal registro?
Sì, ma è un’operazione avanzata da eseguire solo da console e con backup. La strada maestra resta la disinstallazione ufficiale del prodotto.

Conclusioni

Nel caso analizzato, l’errore RDP “No Response From Server” non era dovuto a rete, firewall o risorse: il fattore scatenante era un Logon Agent di terze parti rimasto orfano di configurazione. La rimozione dell’agente (SecurEnvoy Windows Logon Agent) ha risolto istantaneamente su host e VM. Se incontri gli stessi sintomi — sessione che si avvia, schermata di logon per qualche secondo e disconnessione — indaga subito i Credential Provider e l’inventario software: spesso è lì che si nasconde la causa.

In sintesi: riconoscere che il problema è nella pipeline di logon (e non nella rete) riduce il tempo di diagnosi. Un inventario software aggiornato e una procedura di rollback per i provider di terze parti sono le contromisure più efficaci per evitare che una semplice prova di MFA blocchi l’accesso RDP ai server.