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

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”. Disponibili solo nel Microsoft Update Catalog.

Cosa fare oggi

La strada corretta è installare l’aggiornamento out-of-band della propria versione. Quattro punti da tenere presenti:

• Va cercato nel Microsoft Update Catalog, con il numero di KB della tabella qui sopra. Non viene proposto da Windows Update e WSUS non lo sincronizza: negli ambienti gestiti va importato a mano in WSUS oppure distribuito con Configuration Manager o Intune.
• È 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 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.

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. Da quel momento nessun episodio, ma il periodo di osservazione è ancora troppo breve per considerare chiusa la questione. Quattro ore dopo Microsoft ha pubblicato l’out-of-band: il passo successivo è installarlo nella prossima finestra di manutenzione e togliere il criterio.

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.