Dopo gli aggiornamenti cumulativi di settembre 2026, alcuni amministratori segnalano blocchi di Remote Desktop Services su Windows Server 2019, 2022 e 2025. Il sintomo tipico è un server che continua a funzionare ma smette di accettare nuove sessioni RDP dopo alcune ore; in altri casi le sessioni esistenti non riescono a disconnettersi correttamente.
Le segnalazioni sono emerse dopo il Patch Tuesday dell’8 settembre e coinvolgono KB5122876 su Windows Server 2019, KB5122882 su Server 2022 e KB5122871 su Server 2025. Al momento non c’è una conferma Microsoft che attribuisca ufficialmente i blocchi RDS a questi cumulativi, quindi conviene trattare il problema come un’anomalia segnalata sul campo e procedere con verifiche controllate, soprattutto sui server di produzione.
Quali aggiornamenti Windows Server sono coinvolti
Le segnalazioni raccolte da BleepingComputer il 10 settembre 2026 indicano lo stesso comportamento su tre generazioni di Windows Server. Non significa che ogni macchina aggiornata sia destinata a bloccarsi, ma permette di restringere rapidamente il controllo quando RDP smette di funzionare subito dopo la manutenzione mensile.
| Versione | Aggiornamento di settembre 2026 | Build |
|---|---|---|
| Windows Server 2019 | KB5122876 | 17763.9245 |
| Windows Server 2022 | KB5122882 | 20348.5622 |
| Windows Server 2025 | KB5122871 | 26100.33438 |
Microsoft documenta ufficialmente i tre cumulativi nelle rispettive pagine di supporto. Per esempio, KB5122871 per Windows Server 2025 include correzioni di sicurezza e miglioramenti anche nell’area Desktop remoto, in particolare per il reindirizzamento audio. La presenza di una modifica RDP nel changelog, però, non prova da sola quale componente stia causando i blocchi segnalati.
Come si presenta il problema RDS dopo le patch
Il comportamento riportato dagli amministratori è più insidioso di un semplice errore immediato dopo il riavvio. Remote Desktop può funzionare normalmente per alcune ore e poi iniziare a rifiutare o bloccare le connessioni. Il client resta in attesa, la sessione non viene stabilita e anche logout o disconnessioni possono non completarsi.
In alcune segnalazioni compare un errore di connessione con codice 0x3 ed Extended Error Code 0x11. Altri amministratori descrivono un blocco tra componenti RDP e Local Session Manager. Sono indizi utili per correlare l’incidente, non una diagnosi universale: firewall, gateway, licenze RDS, DNS, certificati e problemi di rete possono produrre sintomi simili.
Cosa controllare prima di rimuovere l’aggiornamento
Se il problema è comparso dopo il Patch Tuesday, la prima cosa da verificare è la cronologia degli aggiornamenti del server e l’orario in cui RDS ha iniziato a degradarsi. Non conviene disinstallare subito il cumulativo: le patch di settembre contengono correzioni di sicurezza importanti e il rollback riaprirebbe vulnerabilità appena chiuse.
- Verifica versione e KB installata. Controlla se il server è 2019, 2022 o 2025 e se è presente il relativo cumulativo di settembre.
- Controlla Event Viewer. Cerca eventi anomali nei log di Remote Desktop Services, TerminalServices-LocalSessionManager e TerminalServices-RemoteConnectionManager nell’intervallo in cui sono iniziate le disconnessioni.
- Escludi un problema del solo client. Prova una seconda postazione amministrativa e, se l’architettura lo consente, verifica il percorso attraverso RD Gateway separatamente dal collegamento diretto.
- Controlla lo stato del server. CPU, memoria, storage e rete devono essere normali: un host in saturazione può imitare un guasto RDS.
- Conserva una via di gestione alternativa. Prima di riavviare servizi o server remoti, assicurati di avere console hypervisor, iLO/iDRAC, Azure Serial Console o un altro canale amministrativo equivalente.
Un riavvio può ripristinare temporaneamente il servizio nelle segnalazioni viste finora, ma se il blocco torna dopo alcune ore non va considerato un fix definitivo. In un ambiente con molti Session Host conviene verificare se il problema appare solo sui nodi già aggiornati, lasciando un campione controllato per il confronto.
Disinstallare KB5122871, KB5122882 o KB5122876 risolve?
Secondo le segnalazioni raccolte finora, il rollback del cumulativo ha ripristinato Remote Desktop su alcuni sistemi. Questo dato è utile per identificare una possibile correlazione, ma non rende la disinstallazione la scelta predefinita. Rimuovere il pacchetto significa eliminare anche le correzioni di sicurezza di settembre.
Su un server di produzione la decisione dovrebbe quindi passare da change management, valutazione dell’esposizione e disponibilità di mitigazioni compensative. Se RDS è completamente indisponibile e il servizio è critico, un rollback temporaneo può essere valutato dall’amministratore come misura d’emergenza; va poi ripristinata la patch non appena Microsoft pubblica un fix o una mitigazione supportata. Evita invece di bloccare gli aggiornamenti a tempo indefinito su tutta la flotta.
Non confondere il bug con la vulnerabilità RDS di settembre
Il problema di affidabilità descritto qui è distinto dalle vulnerabilità corrette nello stesso Patch Tuesday. Nel nostro approfondimento sulle patch Windows di settembre 2026 e le falle già sfruttate abbiamo visto anche CVE-2026-69525 in Remote Desktop Services, una vulnerabilità critica inclusa nel pacchetto di sicurezza.
Questo rende la scelta più delicata: disinstallare un cumulativo per recuperare RDS può ripristinare il servizio ma contemporaneamente togliere protezioni di sicurezza. Per questo la priorità è capire se il blocco osservato coincide davvero con l’aggiornamento e limitare eventuali rollback allo stretto necessario.
Microsoft ha già pubblicato un fix?
Alla data dell’11 settembre 2026, Microsoft non ha ancora confermato pubblicamente che i blocchi RDS segnalati siano causati dai cumulativi di settembre e non risulta una mitigazione ufficiale specifica per questo problema nelle informazioni disponibili al momento. BleepingComputer riferisce di aver chiesto chiarimenti a Microsoft senza aver ricevuto risposta al momento della pubblicazione.
Gli amministratori dovrebbero quindi monitorare le pagine ufficiali dei rispettivi KB e il Windows Release Health dashboard. Se Microsoft riconoscerà il problema, la correzione potrebbe arrivare come Known Issue Rollback, aggiornamento out-of-band o fix incluso in un successivo cumulativo, a seconda della causa individuata.
Come ridurre il rischio sui server ancora da aggiornare
Chi non ha ancora distribuito il Patch Tuesday su una flotta RDS dovrebbe evitare due estremi: installare ovunque senza test o sospendere indefinitamente gli aggiornamenti di sicurezza. La strategia più prudente è validare il cumulativo su un gruppo pilota rappresentativo, mantenere il monitoraggio per diverse ore e solo dopo ampliare il deployment.
Se il pilot mostra blocchi riproducibili, documenta build, ruolo RDS, orario dell’incidente, eventi di sistema e percorso di connessione. Queste informazioni rendono più semplice confrontare il caso con gli aggiornamenti che Microsoft potrà pubblicare e riducono il rischio di attribuire alla patch un problema di rete o configurazione non correlato.
Domande frequenti
Quali versioni di Windows Server sono coinvolte?
Le segnalazioni disponibili riguardano Windows Server 2019, 2022 e 2025 dopo i cumulativi di settembre 2026.
Quali KB devo controllare?
KB5122876 per Server 2019, KB5122882 per Server 2022 e KB5122871 per Server 2025.
Il rollback è una soluzione definitiva?
No. In alcune segnalazioni ripristina RDS, ma rimuove anche le correzioni di sicurezza del Patch Tuesday. Va valutato solo come misura temporanea e controllata.
Microsoft ha confermato il bug?
Al momento della verifica dell’11 settembre 2026 Microsoft non aveva ancora confermato pubblicamente la causa dei blocchi RDS segnalati.
In sintesi
Le patch di settembre 2026 sono associate a segnalazioni di Remote Desktop Services che smette di accettare connessioni su Windows Server 2019, 2022 e 2025. I KB da controllare sono KB5122876, KB5122882 e KB5122871. Il rollback sembra ripristinare il servizio in alcuni casi, ma rimuove anche correzioni di sicurezza: va quindi considerato solo dopo aver escluso altre cause e con una strategia di mitigazione.
Finché Microsoft non pubblica un’indicazione ufficiale, la scelta migliore per gli ambienti critici è testare gli aggiornamenti su un gruppo pilota, mantenere un accesso amministrativo alternativo e seguire le pagine dei KB per eventuali aggiornamenti sul problema.
