Windows Server, Desktop remoto e RDP bloccati dopo gli aggiornamenti di settembre

Gli aggiornamenti di sicurezza di settembre 2026 per Windows Server stanno creando problemi in alcune infrastrutture Remote Desktop Services (RDS). Le prime segnalazioni, emerse poche ore dopo il Patch Tuesday dell’8 settembre, descrivono host RDS che smettono progressivamente di accettare nuove connessioni, sessioni che non riescono a chiudersi e servizi legati alla gestione degli utenti che finiscono in uno stato di attesa apparentemente irreversibile. Il comportamento anomalo riguarda almeno Windows Server 2019, Windows Server 2022 e Windows Server 2025, anche se al momento Microsoft non ha inserito il problema tra quelli ufficialmente riconosciuti.

Non sembra trattarsi del classico errore RDP dovuto a rete, certificati o autenticazione. Diversi amministratori descrivono invece una sorta di blocco progressivo dello stack che gestisce le sessioni: inizialmente il server funziona, poi un’operazione di disconnessione o chiusura sembra non completarsi e, da quel momento, altre richieste iniziano ad accodarsi. Il risultato può essere pesante: connessioni ferme su “Connecting” o “Securing remote connection“, Task Manager che non risponde, logout impossibili e persino riavvii che non arrivano a concludersi.

Le segnalazioni sono comparse subito dopo l’installazione degli aggiornamenti cumulativi di settembre: KB5122876 per Windows Server 2019, KB5122882 per Windows Server 2022 e KB5122871 per Windows Server 2025. Per Server 2022, KB5122882 porta il sistema alla build 20348.5622; per Server 2025, KB5122871 aggiorna alla build 26100.33438; Server 2019 passa invece alla build 17763.9245.

Windows Server e RDP: cosa succede dopo gli aggiornamenti di settembre 2026

In tanti ambienti composti da host Windows Server 2022 e 2025 sotto lo stesso “cappello” RDS, le macchine hanno iniziato a mostrare uguale comportamento dopo l’installazione degli aggiornamenti cumulativi.

Le nuove connessioni RDP rimangono ferme prima di raggiungere la schermata di accesso. Nel registro TerminalServices-RemoteConnectionManager/Admin compare l’evento 20498, associato al messaggio secondo cui Remote Desktop Services impiega troppo tempo a completare la connessione del client.

Non sembra bloccarsi soltanto la connessione RDP in ingresso. Il problema coinvolge la gestione dello stato delle sessioni sul server: è proprio questo dettaglio a spiegare perché strumenti apparentemente scollegati da Desktop remoto possano iniziare a comportarsi male.

Durante il problema, il servizio RDP risulterebbe fermo all’interno della funzione RDPSERVERBASE!WDLIB_Close. L’ipotesi è quella di un’attesa che non termina correttamente durante la chiusura di una sessione e che finisce per coinvolgere il Local Session Manager, componente centrale nella gestione delle sessioni utente di Windows.

Desktop remoto e connessioni RDP in blocco dopo l’aggiornamento: procedura pratica di diagnosi

Il primo controllo può partire da una console PowerShell amministrativa. È bene verificare, innanzi tutto, la build con winver oppure con Get-ComputerInfo | Select WindowsProductName,WindowsVersion,OsBuildNumber.

Subito dopo conviene interrogare i due servizi più importanti per RDP con Get-Service TermService,UmRdpService.

TermService gestisce Remote Desktop Services, mentre UmRdpService si occupa della redirezione di dispositivi e porte in modalità utente. Il semplice stato “Running“, però, non basta: un servizio può risultare formalmente attivo e avere comunque thread interni bloccati.

Un test molto utile consiste quindi nell’eseguire qwinsta oppure query user. Se il comando restituisce immediatamente l’elenco delle sessioni, LSM e la parte principale della gestione RDS stanno almeno rispondendo.

Se invece qwinsta rimane fermo insieme a Task Manager, logout e nuove connessioni, l’indizio diventa molto più forte: il blocco interessa probabilmente il percorso che gestisce lo stato delle sessioni e non soltanto il listener TCP sulla porta 3389.

Vale la pena controllare anche la porta con Get-NetTCPConnection -LocalPort 3389 -State Listen. La presenza del listener non garantisce che RDS sia sano, ma aiuta a distinguere due scenari. Se la 3389 non risulta in ascolto, bisogna prima verificare configurazione e servizi; se invece la porta è aperta ma le connessioni restano ferme e contemporaneamente qwinsta non risponde, il problema è compatibile con il blocco descritto da tanti amministratori dopo le patch di settembre.

Controllare gli eventi prima di riavviare il server

Prima di forzare un riavvio conviene salvare gli eventi, perché dopo il recupero della macchina una parte delle informazioni più interessanti può diventare difficile da correlare.

Nel Visualizzatore eventi (Windows+R, eventvwr.msc) bisogna aprire Applications and Services Logs, Microsoft, Windows, TerminalServices-RemoteConnectionManager, Operational o Admin a seconda della versione, quindi cercare in particolare l’evento 20498 già citato in precedenza.

Da PowerShell si può fare una prima verifica anche senza aprire l’interfaccia grafica. Ad esempio:

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 100 | Where-Object Id -eq 20498.

Se il canale presente sul sistema usa una denominazione differente, Get-WinEvent -ListLog *TerminalServices* permette di individuarlo rapidamente.

È utile controllare nello stesso momento anche System e gli eventi Winlogon. Una sequenza in cui compaiono errori RDS, logout che non terminano e servizi che entrano in STOP_PENDING offre un quadro significativo.

Provare a recuperare TermService senza riavviare l’intero server

Se il server risponde ancora dalla console e non ospita sessioni che devono essere preservate, si può tentare il riavvio di Remote Desktop Services con Restart-Service TermService -Force.

L’operazione può interrompere le sessioni RDP attive e va quindi eseguita soltanto dopo aver verificato chi è collegato.

Dopo il riavvio è bene controllare nuovamente Get-Service TermService,UmRdpService, quindi eseguire qwinsta e provare una nuova connessione. Se TermService torna correttamente operativo e qwinsta risponde, il server può essere recuperato senza reboot, almeno temporaneamente.

Il caso più difficile è quello in cui TermService resta indefinitamente in STOP_PENDING. Si può verificarlo con sc queryex TermService: oltre allo stato, il comando mostra il PID del processo che ospita il servizio.

Arrivati qui bisogna considerare l’intervento come un recupero di emergenza. Se il normale arresto del servizio non termina e il server deve comunque essere riavviato, la terminazione forzata del processo con taskkill /PID NUMERO_PID /F può sbloccare la sequenza, ma non va trattata come una normale procedura amministrativa.

Prima occorre identificare con precisione il PID restituito da sc queryex e verificare quali altri servizi condividano eventualmente lo stesso processo.

Su una macchina virtuale completamente congelata resta infine il reset dall’hypervisor. È l’ultima scelta: equivale a togliere alimentazione al sistema operativo e può far perdere dati non ancora scritti su disco.

Disattivare temporaneamente la redirezione audio RDP

Gli aggiornamenti di settembre modificano esplicitamente il codice relativo alla redirezione audio di Desktop remoto.

Non esiste ancora una conferma Microsoft che colleghi quella modifica ai blocchi delle sessioni, ma il legame temporale rende interessante un test molto semplice: disabilitare la redirezione audio su uno o più Session Host di prova e confrontarne il comportamento con quello degli altri server.

Il criterio si trova in Configurazione computer, Modelli amministrativi, Componenti di Windows, Servizi Desktop remoto, Host sessione Desktop remoto, Reindirizzamento dispositivi e risorse. La voce “Consenti reindirizzamento riproduzione audio e video“, impostata su Disabilitato, impedisce il trasferimento della riproduzione multimediale dalla sessione remota al client.

Dopo la modifica eseguire gpupdate /force e, per una prova pulita, riavviare l’host quando possibile.

Rollback della patch: come farlo davvero con DISM

Se il server torna a funzionare soltanto dopo la rimozione dell’aggiornamento, oppure si blocca nuovamente dopo ogni riavvio, il rollback dell’aggiornamento cumulativo diventa l’intervento più concreto in attesa di una correzione Microsoft.

Da un prompt amministrativo bisogna dapprima eseguire il seguente comando per individuare l’aggiornamento appena installato e annotarne il nome completo:

DISM /Online /Get-Packages /Format:Table

In alternativa PowerShell permette di esaminare i pacchetti con Get-WindowsPackage -Online.

Una volta identificato con certezza il package corretto, Microsoft prevede la sintassi DISM /Online /Remove-Package /PackageName:NOME_COMPLETO_DEL_PACCHETTO.

L’alternativa PowerShell è Remove-WindowsPackage -Online -PackageName "NOME_COMPLETO_DEL_PACCHETTO".

Terminata la rimozione, si deve riavviare il server e controllare nuovamente build, TermService, qwinsta e Visualizzatore eventi. Il test più importante consiste nel riprodurre la normale sequenza di lavoro: collegamento di più utenti, disconnessione, riconnessione, logout e nuova apertura delle sessioni. Un semplice login riuscito subito dopo il reboot non dimostra che il problema sia scomparso.

Microsoft per ora non riconosce il problema tra quelli noti

Al 10 settembre 2026, le pagine ufficiali di KB5122871 e KB5122882 non riportano indicazioni su blocchi RDS/RDP/Desktop remoto nella sezione dei problemi conosciuti.

La mancanza di un riconoscimento ufficiale non dimostra che la problematica sia assente: le prime segnalazioni sono arrivate soltanto poche ore dopo il rilascio delle patch e il campione di installazioni reali cresce molto rapidamente nei giorni successivi al Patch Tuesday.

Il dato più rilevante, per ora, è la ripetibilità osservata in diversi ambienti: sistemi funzionanti con gli aggiornamenti di agosto hanno iniziato a manifestare blocchi dopo quelli di settembre e, in più casi, tornano stabili dopo il rollback.