Disconnessioni RDS Windows Server 2019: bug KB5041578 e codice 3489660929, cause e soluzioni

Su alcune farm RDS con Windows Server 2019 può verificarsi un “mass‑disconnect” simultaneo degli utenti con Event ID 40 e codice motivo 3489660929. Questa guida spiega come riconoscere il problema, perché accade (KB5041578) e come risolverlo in modo stabile senza fermare troppo a lungo la produzione.

Indice

Scenario e sintomi

In ambienti Remote Desktop Services (RDS) basati su Windows Server 2019, a intervalli irregolari (da pochi giorni a un paio di settimane) può capitare che tutte le sessioni utente su un singolo Session Host vengano disconnesse nello stesso istante. Al rientro, gli utenti ritrovano le applicazioni chiuse o in stato inconsistente, con perdita di lavoro non salvato e impatti estesi sui processi aziendali.

Nel Visualizzatore eventi del Session Host sono tipicamente presenti questi indicatori:

Event ID 40 – “Session n has been disconnected” (sorgente TerminalServices‑LocalSessionManager)
Reason code 3489660929 (valore esadecimale 0xD0000001)

A differenza di normali disconnessioni (logoff, idle timeout, manutenzione pianificata), l’evento si verifica senza preavviso, colpisce simultaneamente tutte le sessioni attive sullo stesso host e non lascia evidenze di crash applicativi o di rete palesi.

Perché accade

Le analisi sul campo hanno individuato come causa un bug introdotto dall’aggiornamento cumulativo KB5041578 (Windows Server 2019, agosto 2024 – build 17763.6189) che può generare disconnessioni forzate delle sessioni RDS con il reason code sopra indicato. In presenza di questo aggiornamento il fenomeno può ripresentarsi finché il pacchetto resta installato o finché un cumulativo successivo non applica la correzione ufficiale. Se l’update viene rimosso ma non bloccato, cumulativi successivi possono reintrodurlo automaticamente durante i cicli di patching, riproponendo il problema.

Segnali utili per la diagnosi

Nel log Microsoft‑Windows‑TerminalServices‑LocalSessionManager/Operational compaiono in rapida sequenza più Event ID 40 con lo stesso timestamp.
Nei log RemoteDesktopServices‑RdpCoreTS e RemoteConnectionManager non si trovano errori di autenticazione o handshake RDP congruenti con una causa di rete.
Non sono necessari riavvii dell’host per riprodurre l’errore: può avvenire anche su host con uptime elevato e in assenza di manutenzione.

Ipotesi scartate e prove effettuate

Prima di convergere sull’origine (KB5041578), diverse ipotesi comuni sono state testate. La seguente tabella riassume i principali tentativi e i relativi esiti.

Ipotesi / prova	Esito
Disattivazione del trasporto UDP per RDP (GPO: Turn off UDP on Client; Select RDP transport protocols = TCP only; chiavi di registro equivalenti)	Nessun miglioramento osservabile; il mass‑disconnect continua a presentarsi.
Driver di rete/WLAN difettosi, perdite di pacchetti o flapping (analisi System, Wireshark)	Non confermato; traffico stabile, nessuna correlazione temporale con le disconnessioni.
Parametri di rete e sicurezza: MTU, VPN overlay, dimensione token Kerberos, canali di sicurezza	Regolazioni provate senza esito; il problema persiste.
Aggiornamento cumulativo KB5041578 (13 agosto 2024, build 17763.6189) – Known issue	Confermato: origine del problema. Rimozione o patch correttiva risolvono.

Impatto operativo

Interruzione di massa delle sessioni RDP su un singolo host con effetto all‑at‑once.
Rischio di corruzione dati su applicazioni non transazionali o file non salvati.
Picchi di ricollegamento e login storm verso i broker/collection al ripristino.
Possibili code di stampa interrotte e transazioni applicative intermedie da rimettere in coda.

Soluzioni e work‑around verificati

Le seguenti azioni sono state validate in ambienti di produzione. In tabella il colpo d’occhio; più sotto le procedure passo‑passo.

Azione	Risultato	Quando usarla
Disinstallare KB5041578	Risolve immediatamente le disconnessioni.	Se è possibile rimuovere l’update in tempi rapidi.
Installare un cumulativo successivo con la correzione ufficiale (es. da novembre 2024 in poi)	Ripristina la stabilità senza bloccare il canale patch.	Se si desidera rimanere “patch current”.
Posticipare temporaneamente gli aggiornamenti qualitativi (GPO Defer Quality Updates)	Evita la reinstallazione del pacchetto difettoso in attesa della patch correttiva.	Soluzione ponte durante la finestra di mitigazione.
Aprire una sessione console sull’host (Hyper‑V/iLO/Drac) e riavviare i servizi RDS	Ripristino temporaneo delle connessioni fino al riavvio successivo o alla successiva occorrenza.	Mitigazione d’emergenza in orario di produzione.
Riavvio forzato dell’host (shutdown “dirty” se l’arresto pulito resta bloccato)	L’host rientra operativo ma il problema può ripresentarsi.	Ultima risorsa quando l’host è in stallo.

Procedure passo‑passo

Verifica rapida della presenza di KB5041578

Eseguire uno dei comandi seguenti in una console con privilegi elevati:

wmic qfe | findstr /i "5041578"
Get-HotFix -Id KB5041578

Se il pacchetto è presente e i sintomi coincidono (Event ID 40 + reason 3489660929, disconnessioni simultanee), procedere con una delle due strade “stabili”: rimozione immediata o aggiornamento a un cumulativo che integra il fix.

Rimozione di KB5041578

Mettere l’host in drain mode (nessun nuovo accesso) per ridurre l’impatto sugli utenti, quindi attendere lo svuotamento delle sessioni non critiche: change logon /drain quser logoff <IDSessione> /v In alternativa, usare Server Manager > Remote Desktop Services > Collections per impedire nuovi accessi all’host.
Rimuovere l’update: wusa /uninstall /kb:5041578 /quiet /norestart Se wusa segnala che l’aggiornamento non è disinstallabile, utilizzare DISM elencando prima i pacchetti: DISM /Online /Get-Packages | findstr /i "PackageforRollupFix" quindi rimuovere il pacchetto corrispondente alla build in uso: DISM /Online /Remove-Package /PackageName:<NomePacchetto> /Quiet /NoRestart
Programmare un riavvio controllato fuori orario o in una finestra concordata: shutdown /r /t 60 /c "Rimozione KB5041578 - riavvio pianificato"
Al rientro, verificare:
- assenza di KB5041578 (Get-HotFix);
- stabilità delle sessioni per alcuni giorni;
- ripresa del carico standard senza picchi anomali su CPU/IO.

Aggiornamento a un cumulativo con la correzione

Pianificare l’installazione di un cumulative update successivo (ad es. rilasci di novembre 2024 o successivi) che includa il fix.
Applicare il CU su un host pilota “canary” della farm in drain mode, monitorando:
- log RDS (LocalSessionManager, RdpCoreTS),
- contatori prestazionali (sessioni attive, logon/sec),
- telemetrie applicative sensibili alla perdita di sessione.
Estendere a scaglioni sugli altri host, rispettando finestre di manutenzione e tempi di rientro.

Bloccare temporaneamente i qualitativi per evitare la reintroduzione

In attesa della correzione, è prudente differire gli aggiornamenti qualitativi per un periodo limitato (es. 30 giorni), così da impedire la reinstallazione del pacchetto problematico.

Impostazioni consigliate via GPO (per OU dei Session Host):

Computer Configuration > Administrative Templates > Windows Update > Windows Update for Business
Select when Quality Updates are received: Enabled, Deferral 30 giorni
Valutare anche una exclusion list temporanea via WSUS/ConfigMgr se in uso.

Ricordare di rimuovere la deroga non appena il CU correttivo è distribuito e validato.

Mitigazioni di emergenza in produzione

Sessione console sull’host tramite Hyper‑V/ILO/DRAC per sbloccare i servizi RDS: Get-Service TermService, UmRdpService | Restart-Service -Force Utile se l’host accetta connessioni solo parzialmente o servizi risultano “hung”. Effetto temporaneo.
Riavvio forzato quando l’arresto pulito resta bloccato: shutdown /r /f /t 0 Considerare come ultima risorsa: non previene la ricomparsa del problema.

Buone pratiche consigliate

Verificare la presenza di KB5041578 o dei suoi sostituti
wmic qfe | findstr /i "5041578" Se presente ed è in corso il fenomeno, rimuovere l’update o aggiornare a un CU che include la correzione.
Gestire con criterio gli aggiornamenti qualitativi
- Differire solo per il tempo strettamente necessario (es. 30 giorni) tramite GPO/WSUS.
- Dopo ogni nuovo CU, monitorare per qualche giorno la stabilità delle sessioni.
Documentare una procedura di recovery rapida
- Accesso console locale/Hyper‑V per riavviare servizi/host.
- Messaggistica predefinita per avvisi agli utenti e finestre di manutenzione.
- Playbook di drain mode per svuotare in sicurezza un host.
Seguire le note di rilascio di Windows Server 2019 (LTSC) per sapere quando il fix è stato incluso e consolidato nei cumulativi successivi.

Playbook di diagnosi e verifica

Raccolta log mirata

Applications and Services Logs > Microsoft > Windows > TerminalServices‑LocalSessionManager > Operational
… > RemoteDesktopServices‑RdpCoreTS/Operational
… > RemoteConnectionManager/Operational
System per eventuali stop dei servizi o errori driver

Esportazione rapida per analisi correlata:

wevtutil epl Microsoft-Windows-TerminalServices-LocalSessionManager/Operational C:\Temp\TS_LSM.evtx
wevtutil epl Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational C:\Temp\RdpCoreTS.evtx
wevtutil epl Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational C:\Temp\RCM.evtx

Controlli post‑remediation

Verificare che non compaiano nuovi Event ID 40 con lo stesso pattern “di massa”.
Controllare il numero di sessioni attive (quser) e il tasso di logon (PerfMon: Terminal Services).
Monitorare i timestamp delle disconnessioni per almeno 7‑10 giorni dopo la rimozione/aggiornamento.

Checklist rapida per i team di esercizio

Conferma sintomi: Event ID 40 + reason 3489660929, disconnessioni simultanee.
Verifica patch: Get-HotFix -Id KB5041578.
Decisione immediata: rimozione KB o aggiornamento a CU con fix.
Prevenzione: differimento temporaneo dei qualitativi per evitare reintroduzione.
Mitigazione: sessione console e restart servizi RDS; come ultima risorsa riavvio forzato.
Validazione: monitoraggio sessioni/log per alcuni giorni post‑intervento.

Domande frequenti

Disabilitare l’UDP risolve?

No. Restringere il trasporto a TCP‑only può aiutare a diagnosticare o eliminare variabili di rete, ma non rimuove la causa radice legata al bug del cumulativo. Il mass‑disconnect può ripresentarsi.

Il problema è di rete o di driver?

Le analisi non hanno mostrato correlazioni affidabili con flapping di rete o driver difettosi. In assenza di altri sintomi, la pista di rete non è prioritaria rispetto alla gestione degli aggiornamenti.

Basta il riavvio dell’host?

Il riavvio ripristina temporaneamente l’operatività, ma non previene il ripetersi del problema se l’update difettoso è ancora presente o viene reinstallato.

Come evito che il problema torni dopo il patching mensile?

Usare GPO/WSUS per differire i qualitativi finché un CU con fix è approvato e validato. Dopo il roll‑out del CU corretto, rimuovere la deroga e tornare a una postura “patch current”.

Esempi di automazione utile

Controllo giornaliero dei pacchetti “a rischio”

$kb = "KB5041578"
if (Get-HotFix -Id $kb -ErrorAction SilentlyContinue) {
  Write-Output "ATTENZIONE: $kb presente su $env:COMPUTERNAME"
  # Inviare un alert al sistema di monitoraggio aziendale
}

Raccolta eventi di disconnessione per audit

$from = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{
  LogName = "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational";
  ID = 40; StartTime = $from
} | Export-Csv C:\Temp\RDS_Disconnects.csv -NoTypeInformation

Raccomandazioni architetturali per farm RDS

Distribuire le patch a scaglioni: introdurre un canary host per la validazione prima del roll‑out totale.
Usare il drain mode in manutenzione per evitare logoff improvvisi degli utenti.
Separare i ruoli (Broker, Gateway, Web Access, Session Host) per ridurre blast radius.
Definire SLO utente (es. perdita massima di sessione < X/mese) e allineare i processi di patching.

Conclusioni operative

Il mass‑disconnect con reason code 3489660929 su Windows Server 2019 è riconducibile a un bug noto del cumulativo KB5041578. Le uniche risposte stabili sono:

rimuovere l’aggiornamento difettoso oppure
installare un cumulativo successivo che integri la correzione ufficiale.

I tentativi collaterali (forzare TCP‑only, ritoccare MTU, variare parametri Kerberos) possono servire per escludere concause, ma non eliminano la radice del problema. Fino alla distribuzione del fix, è buona pratica differire temporaneamente i qualitativi, monitorare attentamente la stabilità delle sessioni e predisporre un playbook di recovery rapido con sessione console e riavvio controllato dei servizi/host. Con una strategia di patch management accorta e validazioni progressive, la continuità di servizio RDS può essere preservata senza rinunciare alla postura di sicurezza “patch current”.

Appendice: comandi e percorsi utili

Verificare l’installazione di un KB: Get-HotFix -Id KB5041578 wmic qfe | findstr /i "5041578"
Rimozione con WUSA: wusa /uninstall /kb:5041578 /quiet /norestart
Rimozione con DISM: DISM /Online /Get-Packages | findstr /i "PackageforRollupFix" DISM /Online /Remove-Package /PackageName:<NomePacchetto> /Quiet /NoRestart
Impostazioni GPO per qualità: Computer Configuration → Administrative Templates → Windows Update → Windows Update for Business → Select when Quality Updates are received (Deferral 30 giorni)
Log da controllare:
- Microsoft‑Windows‑TerminalServices‑LocalSessionManager/Operational
- Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS/Operational
- Microsoft‑Windows‑TerminalServices‑RemoteConnectionManager/Operational
- System

Nota finale: se nella tua farm RDS sono presenti host eterogenei (versioni, livelli di patch, ruoli), crea una matrice di compatibilità e applica i cambiamenti iniziando sempre dall’host canary. Questo riduce drasticamente il rischio di impatto massivo e accelera l’individuazione di regressioni.