Remote Desktop si blocca
dopo le patch di settembre: il fix

Aggiornato il 14 ottobre 2026

Il sintomo

Il session host funziona regolarmente per qualche ora, poi smette di accettare nuove connessioni. Le sessioni aperte non si chiudono, qwinsta non risponde e gli strumenti di amministrazione restano appesi. Microsoft descrive gli stessi effetti: connessioni RDP che falliscono dopo alcuni minuti, accessi che non vanno a buon fine, server fermi sulla schermata “Attendere la configurazione di Desktop remoto”, Microsoft Management Console, RDS Licensing Diagnoser ed Esplora file che non rispondono, pagina di Windows Update che gira a vuoto.

Il dettaglio che conta per chi gestisce un ambiente di produzione: il difetto si innesca con la chiusura delle sessioni. Si manifesta quindi in orario di lavoro, quando gli utenti entrano ed escono, e non nelle ore di inattività. Un server che passa la notte tranquillo può bloccarsi due volte nella stessa giornata lavorativa.

La causa e la cronologia

È una regressione introdotta dagli aggiornamenti cumulativi di sicurezza dell’8 settembre 2026, il Patch Tuesday del mese. Riguarda tutte le versioni supportate di Windows Server e i client Windows 10 e 11 con Desktop remoto attivo. La sequenza dei giorni successivi spiega perché molti amministratori sono rimasti senza una soluzione pulita per quasi una settimana.

• 18 settembre. Escono gli aggiornamenti cumulativi. Nelle ore seguenti i primi session host iniziano a bloccarsi.
• 211 settembre, sera. Microsoft apre il problema noto su Windows release health con stato “Mitigated”. Il workaround indicato è deallocare e riavviare la macchina virtuale: non una correzione, un modo per guadagnare qualche ora. Lo stesso giorno viene impacchettato il Known Issue Rollback, riconoscibile dal timestamp nel nome del file, ma non viene linkato né dalla pagina della KB né dalla dashboard. Noi lo abbiamo trovato passando dall’advisory Citrix CTX697101.
• 314 settembre, ore 19:00. Microsoft rilascia gli aggiornamenti out-of-band e porta il problema a “Resolved”. Per Windows Server sono disponibili solo nel Microsoft Update Catalog; per Windows 11 24H2, 25H2 e 26H1 arrivano anche da Windows Update e WSUS. Lo stesso out-of-band corregge anche un difetto Hyper-V sulle cartelle condivise con macchine virtuali Linux e, solo in parte, uno sui dispositivi audio USB multicanale.
• 422 settembre. Escono le anteprime facoltative di Windows 11 (KB5124010 per 24H2, 25H2 e 26H2, KB5124006 per 26H1): sono cumulative e contengono già la correzione. Per Windows Server non esce nulla di nuovo.
• 513 ottobre. Patch Tuesday di ottobre: i cumulativi KB5126646 (Server 2025), KB5126655 (Server 2022), KB5126651 (Server 2019) e KB5126868 (Server 2016) includono la correzione e arrivano da Windows Update e WSUS; nelle KB nessun problema noto su Remote Desktop. Per Windows Server 2022 è anche l’ultimo aggiornamento del supporto standard.

Cosa fare oggi

La strada corretta è installare il cumulativo del 13 ottobre, che contiene la correzione e arriva da Windows Update e WSUS; chi non può aspettare il ciclo mensile installa l’out-of-band della propria versione. Quattro punti da tenere presenti:

• Sui server va cercato nel Microsoft Update Catalog, con il numero di KB della tabella qui sopra: Windows Update non lo propone e WSUS non lo sincronizza, quindi negli ambienti gestiti va importato a mano in WSUS oppure distribuito con Configuration Manager o Intune. Sui client Windows 11 24H2, 25H2 e 26H1 arriva da Windows Update e WSUS come qualsiasi altro aggiornamento; sulla 23H2 va installato tra gli aggiornamenti facoltativi di Windows Update o importato dal Catalog.
• È cumulativo. Contiene tutte le correzioni di sicurezza del Patch Tuesday di settembre e il servicing stack aggiornato. Chi non ha ancora installato l’aggiornamento dell’8 settembre può installare direttamente l’out-of-band e saltare il passaggio difettoso.
• Se il Known Issue Rollback è già attivo, Microsoft conferma che non serve fare nulla prima di installare. Dopo il riavvio riporta il criterio su Non configurato e rimuovi l’MSI: le definizioni KIR hanno vita limitata e non devono restare nelle policy.
• Riavvia e verifica con utenti reali. Il difetto si innesca chiudendo le sessioni: a macchina ferma non si manifesta, quindi un server che regge la notte non dice niente. Serve una giornata di esercizio.

Se il server è già bloccato

Una macchina bloccata non accetta connessioni nemmeno dagli amministratori: il servizio Desktop remoto non risponde a nessuno, sessione amministrativa compresa. Non si risolve da remoto in RDP.

• 1Entra dalla console. La console della macchina virtuale in Hyper-V, VMware o Proxmox; la console seriale o il riavvio dal portale per una macchina in Azure; la console remota del server (iLO, iDRAC, IPMI) per un server fisico.
• 2Riavvia la macchina. Il riavvio la sblocca, ma non la corregge.
• 3Subito dopo, installa la patch. Prima che gli utenti rientrino, installa l’aggiornamento out-of-band o, se non puoi, applica il Known Issue Rollback descritto più avanti. Senza correzione il blocco si ripresenta alla prima serie di sessioni chiuse.

Se l’installazione sembra bloccata

Sui server il pacchetto è pesante: per Windows Server 2022 sono circa 560 MB, perché oltre all’aggiornamento cumulativo contiene il servicing stack update KB5122881. Installato come MSU scaricato dal Catalog lavora parecchio prima di mostrare progressi, e al riavvio attraversa più fasi di “Lavorare sugli aggiornamenti” in cui la percentuale resta ferma per minuti. È il comportamento normale di un pacchetto che unisce servicing stack e aggiornamento cumulativo, non un blocco.

Per sapere se sta ancora lavorando, apri una seconda sessione e segui il log del Component Based Servicing: se scrive, l’installazione procede.

Get-Content C:\Windows\Logs\CBS\CBS.log -Tail 20 -Wait

Un secondo segnale è il consumo di CPU dei processi TiWorker e TrustedInstaller. Considera un problema reale solo se il log resta immobile per mezz’ora e quei processi sono a zero. Nel frattempo non chiudere la finestra dell’installer, non forzare il riavvio e non spegnere la macchina: interrompere un servicing stack update a metà è il modo più rapido per dover riparare il component store.

Dopo il riavvio conferma di essere arrivato alla build giusta. Su Windows Server 2022 devi leggere 20348 e 5631.

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion') |
  Select-Object CurrentBuild, UBR

Se non puoi installare l’out-of-band subito: il Known Issue Rollback

Il Known Issue Rollback (KIR) è il meccanismo con cui Microsoft spegne una singola modifica difettosa senza disinstallare l’aggiornamento, che resta in produzione con tutte le sue correzioni di sicurezza. Per le aziende arriva come pacchetto MSI che aggiunge un criterio di gruppo. È la scelta giusta quando l’out-of-band deve passare da una finestra di manutenzione o da un ciclo di test e nel frattempo il server deve restare in piedi. Per Windows Server 2022 il pacchetto è KB5122882_260911_1847_1_KnownIssueRollback.msi.

• 1Scarica il pacchetto della tua versione e verifica la firma prima di installarlo. Deve risultare Valid con firmatario CN=Microsoft Corporation; in caso contrario non va installato.

Get-AuthenticodeSignature .\KB5122882_260911_1847_1_KnownIssueRollback.msi | fl Status, SignerCertificate

• 2Installa l’MSI. Non modifica nulla nel sistema: copia soltanto i file ADMX e ADML in C:\Windows\PolicyDefinitions. Se usi un Central Store per i criteri di dominio, copia lì i due file.
• 3Imposta il criterio su Disabilitato. Apri l’editor dei criteri di gruppo locale, o crea la GPO di dominio, e sotto Configurazione computer, Modelli amministrativi individua la voce del Known Issue Rollback con il numero della KB. Va impostata su Disabilitato, non su Abilitato: disabilitare il criterio significa disabilitare la modifica difettosa, cioè eseguire il rollback. Su questo punto circolano indicazioni sbagliate.
• 4Riavvia. Senza riavvio la modifica non ha effetto.

Alternativa senza MSI, con un avvertimento

Il criterio non fa altro che scrivere un valore DWORD nel registro. Si può scrivere direttamente, ma solo su Windows Server 2022 build 20348.5622, perché l’identificativo numerico dell’override cambia da build a build:

$k = 'HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides'
New-ItemProperty -Path $k -Name '1300465806' -Value 0 -PropertyType DWord -Force

Poi riavvia. Su qualsiasi altra build installa l’MSI e leggi l’identificativo dentro il file ADMX corrispondente, senza copiare quello indicato qui. L’identificativo 1501792398 che circola nei forum non è quello di Server 2022.

Verifica e rollback

Dopo il riavvio il valore deve risultare presente sotto la chiave FeatureManagement\Overrides. La verifica di efficacia però non è quella: richiede una giornata di esercizio con utenti reali che aprono e chiudono sessioni. A macchina ferma il difetto non si innesca e l’esito non è significativo.

Per tornare indietro basta cancellare il valore di registro, oppure riportare il criterio su Non configurato, e riavviare. È anche il passaggio da fare, con calma, dopo aver installato l’out-of-band.

Altri problemi aperti di settembre

Gli aggiornamenti di settembre hanno altri problemi noti ancora aperti, che Microsoft elenca anche negli articoli degli out-of-band. Non sono il blocco di Desktop remoto, ma possono confondersi con esso:

• Schermo nero dopo l’accesso su Azure Virtual Desktop con FSLogix. Riguarda Windows 11 24H2, 25H2, 26H1 e 26H2 dall’anteprima del 27 agosto (KB5120998) in poi; aperto il 25 settembre, Microsoft lo ha mitigato con un suo Known Issue Rollback. È un problema diverso da questo.
• Audio USB. Dal 25 settembre Microsoft considera il difetto dei dispositivi USB Audio Class 1.0 risolto solo in parte: l’out-of-band ha corretto l’audio multicanale, ma restano errori Code 10, assenza di audio e impostazioni del volume che non rispondono, su client e server.
• Cronologia file. Può smettere di funzionare chiedendo di ricollegare l’unità. Per ora non c’è una correzione.
• Credential Guard. Su Windows 11 24H2 e successivi può rompere la relazione di trust con il dominio; Microsoft indica un workaround con registro o criteri e la riparazione del canale sicuro. Non riguarda i server.

Dall’esperienza sul campo

Abbiamo applicato il Known Issue Rollback il 14 settembre alle 15:02 su un session host Windows Server 2022 che si bloccava due volte al giorno, in pieno orario di lavoro. Al 17 settembre, dopo tre giornate lavorative piene con gli utenti che entrano ed escono, non si è più verificato un solo blocco: su una macchina che si piantava due volte al giorno è un dato solido, non un’impressione. Quattro ore dopo l’applicazione Microsoft ha pubblicato l’out-of-band, che stiamo installando sui server interessati: dove il criterio è attivo si installa prima l’aggiornamento e si toglie il criterio dopo il riavvio.

Il dettaglio che nessuna guida dice: il pacchetto lavora molto a lungo prima di dare segni di avanzamento, e il log del Component Based Servicing è l’unico modo affidabile per distinguere un’installazione lenta da una piantata. Vale la pena aprirlo prima di iniziare a preoccuparsi.

La lezione, per chi gestisce server virtualizzati e ambienti Remote Desktop, è sempre la stessa: il Patch Tuesday va installato, ma con una finestra di osservazione e un piano di rollback già pronto. Il KIR esiste proprio per questo, purché si sappia dove trovarlo e come si attiva. È il tipo di lavoro che copriamo con il servizio di supporto e operations.