Windows Server 2019 RD Gateway: disconnessioni dopo KB5043050/KB5041578/KB5040430 – cause, fix e workaround

Su Windows Server 2019, dopo i cumulativi KB5040430, KB5041578 e KB5043050, diversi ambienti registrano interruzioni simultanee delle sessioni RDP dietro RD Gateway una o due volte al giorno. In questa guida trovi diagnosi, workaround operativi e buone pratiche per stabilizzare il servizio.

Indice

Panoramica del problema

A partire dai cumulativi di settembre 2024, alcuni sistemi con ruolo Remote Desktop Gateway (RD Gateway) su Windows Server 2019 mostrano cadute improvvise di tutte le sessioni RDP pubblicate su porta 443. Il fenomeno si presenta in modo intermittente (tipicamente 1–2 volte al giorno) e non è legato a manutenzioni pianificate né a modifiche del bilanciamento.

KB coinvolti: KB5040430, KB5041578, KB5043050.
Servizio interessato: Remote Desktop Gateway (Tsgateway).
Impatto: caduta generalizzata delle sessioni RDP pubblicate; nuove connessioni rifiutate fino al riavvio del servizio.

Come si manifesta

Nel Visualizzatore eventi sono tipicamente presenti due indicatori chiave:

Event ID 700 – eccezione 3221225477 (che corrisponde a 0xC0000005, violazione di accesso): il service control manager registra un riavvio forzato del servizio RD Gateway.
Event ID 103 – errore 2148073494 (codice 0x80090016, Keyset non disponibile): RD Gateway non riesce ad accedere alla chiave privata del certificato SSL.

Percorso log: Applications and Services Logs → Microsoft → Windows → TerminalServices‑Gateway → Admin (e Operational).

<Esempio ridotto>
Log: TerminalServices-Gateway/Admin
Event ID: 700
Message: The RD Gateway service is restarting due to an unhandled exception (0xC0000005).

Event ID: 103
Message: The RD Gateway service does not have permission to access the SSL certificate (0x80090016).

Diagnosi rapida

Prima di intervenire, valida che il server sia effettivamente interessato:

Verifica cumulativi installati: Get-HotFix -Id KB5040430, KB5041578, KB5043050
Controlla gli eventi recenti (ultime 48 ore): $since = (Get-Date).AddDays(-2) Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-TerminalServices-Gateway/Admin'; Id=@(700,103); StartTime=$since } | Select-Object TimeCreated, Id, LevelDisplayName, Message
Conferma lo stato del certificato in certlm.msc (Computer locale → Personale → Certificati):
- La catena è completa (radice e intermedi) e non scaduta.
- La chiave privata esiste (ha una chiave privata associata).
- Il Thumbprint coincide con quello selezionato in RD Gateway Manager.

Cause probabili

Il comportamento è riconducibile a un bug introdotto dai cumulativi citati che, in condizioni specifiche, fa “perdere” a RD Gateway l’accesso alla chiave privata del certificato SSL (keyset). Quando ciò accade, il servizio segnala l’errore 0x80090016 e può terminare in access violation (0xC0000005), innescando il riavvio e la conseguente caduta delle sessioni.

Fattori che possono amplificare la frequenza del problema:

Permessi non corretti sulla chiave privata (account di servizio RD Gateway non presente tra i readers della chiave).
Certificato rigenerato o ribindato recentemente senza aggiornare i permessi sul nuovo container.
Timeout aggressivi su apparati intermedi (firewall/IPS/SSL inspection) che interrompono handshake o sessioni TLS lunghe tipiche di RD Gateway.

Soluzioni e misure temporanee

Area	Intervento	Dettagli operativi
Certificato SSL	Ribindare il certificato	In RD Gateway Manager → Properties → SSL Certificates seleziona di nuovo il certificato corretto (da store Computer). Verifica che il Thumbprint coincida con quello previsto.
	Permessi sulla chiave	In certlm.msc (Computer locale) → Personale → <Certicato> → All Tasks → Manage Private Keys: aggiungi `NT SERVICE\Tsgateway` (o in alternativa `NETWORK SERVICE`) con Read.
Servizio RD Gateway	Riavvio programmato	Script PowerShell che esegua `Restart-Service Tsgateway -Force` in orari a basso traffico (vedi esempio sotto) e/o condizionato a poche connessioni attive.
Aggiornamenti	Rollback selettivo	Dove possibile, disinstalla temporaneamente l’ultimo cumulativo: `wusa /uninstall /kb:5043050` (aggiungi `/quiet /norestart` per uso automatizzato). Su WSUS/Intune, declina/metti in pausa il KB sull’OU interessata.
Monitoraggio	Event Viewer	Monitora TerminalServices‑Gateway/Admin e Operational; attiva un’Attività pianificata “al verificarsi dell’evento” sugli ID 103/700 per notifiche e azioni correttive.
Networking	Stabilità e firewall	Evita SSL inspection sulla 443 del gateway; verifica idle-timeout ≥ 60–120 min per flussi a lunga durata; assicurati che health‑probe/bilanciatore gestiscano restart brevi.
Assistenza Microsoft	Ticket Premier/CSS	Il problema è elencato tra i Known Issues dei KB citati: aprire un caso può anticipare un hotfix non ancora pubblico e registrare l’impatto in produzione.

Procedure passo‑passo

Ribindare in modo corretto il certificato SSL

Apri Remote Desktop Gateway Manager.
Click destro sul server → Properties → scheda SSL Certificates.
Scegli Select an existing certificate → Store: Local Computer / Personal.
Seleziona il certificato con CN/SAN uguale al FQDN pubblico del gateway e scadenza valida.
Conferma e salva. Suggerimento: annota il Thumbprint per controlli futuri.

Allineare i permessi sulla chiave privata

Se l’evento 103 indica 0x80090016, è spesso un problema di ACL della chiave.

Apri certlm.msc (store Computer locale), vai su Personale → Certificati e apri il certificato in uso.
Nella scheda Generale verifica “Dispone di una chiave privata associata”.
Nel tab Dettagli copia il Thumbprint.
All Tasks → Manage Private Keys → Add…:
- Aggiungi NT SERVICE\Tsgateway con Read.
- Se il server usa NETWORK SERVICE come logon del servizio, aggiungi anche NETWORK SERVICE con Read.
Assicurati che il servizio CNG Key Isolation (KeyIso) sia Running.

Nota: se il certificato è stato rinnovato con nuova chiave, il dialog “Manage Private Keys” agisce sul nuovo container; il ribind non eredita automaticamente i permessi della chiave precedente.

Riavvio programmato (mitigazione fino alla patch)

Un riavvio “guidato” del servizio limita l’impatto in orari controllati. Di seguito uno script PowerShell che:

verifica che le connessioni correnti siano sotto una soglia;
riavvia Tsgateway con log in Application;
gestisce eccezioni e scrive un codice evento personalizzato.

# C:\Scripts\Restart-RDGW.ps1
param([int]$MaxConn = 5)

$source = 'RDGW-Mitigation'
if (-not [System.Diagnostics.EventLog]::SourceExists($source)) {
New-EventLog -LogName Application -Source $source | Out-Null
}

function Get-RDGWCurrentConnections {

Elenca i contatori disponibili e prova a leggerne uno adatto.

$candidates = @(
'\Remote Desktop Gateway\Current Connections',
'\Remote Desktop Gateway\Active Connections',
'\Remote Desktop Gateway\Current Users'
)
foreach ($c in $candidates) {
try {
$v = (Get-Counter -Counter $c -ErrorAction Stop).CounterSamples[0].CookedValue
if ($v -ge 0) { return [int]$v }
} catch {}
}
return -1 # sconosciuto
}

$curr = Get-RDGWCurrentConnections
Write-EventLog -LogName Application -Source $source -EventId 9000 -EntryType Information `
-Message "Pre-restart check: connessioni correnti = $curr (soglia $MaxConn)."

if ($curr -ge 0 -and $curr -gt $MaxConn) {
Write-EventLog -LogName Application -Source $source -EventId 9002 -EntryType Warning `
-Message "Riavvio RDGW rimandato: connessioni correnti ($curr) > soglia ($MaxConn)."
exit 0
}

try {
Restart-Service -Name Tsgateway -Force -ErrorAction Stop
Start-Sleep -Seconds 5
Write-EventLog -LogName Application -Source $source -EventId 9001 -EntryType Information `    -Message "Servizio Tsgateway riavviato con successo."
} catch {
  Write-EventLog -LogName Application -Source $source -EventId 9003 -EntryType Error`
-Message ("Errore nel riavvio di Tsgateway: " + $_.Exception.Message)
exit 1
}

Task Scheduler → Create Task:

General: Esegui con privilegi elevati.
Triggers: ogni 6–12 ore in orario notturno/lunch break.
Actions: powershell.exe -ExecutionPolicy Bypass -File "C:\Scripts\Restart-RDGW.ps1" -MaxConn 3.

Alternativa minima (senza script):

Restart-Service Tsgateway -Force

Rollback dell’aggiornamento problematico

Se il contesto lo consente (e con adeguata finestra di manutenzione), esegui un rollback mirato:

wusa /uninstall /kb:5043050 /quiet /norestart
facoltativo: riavvio controllato
shutdown /r /t 60 /c "Rollback KB5043050 - RD Gateway stability"

Consigli:

mantieni aggiornati gli altri ruoli critici sul server (es. Defender, .NET security), valutando il rischio residuo;
su WSUS/Intune imposta approval differenziato/ritardo per i server RD Gateway rispetto ad altri ruoli;
documenta l’eccezione di patching con riferimento alla finestra temporale e al piano di rientro.

Monitoraggio e risposta ad eventi

Automatizza notifiche e azioni “al verificarsi dell’evento”:

Task Scheduler → Create Task → Triggers → On an event.
Log: Microsoft-Windows-TerminalServices-Gateway/Admin, Event ID 103, 700.
Action: invia e‑mail/Teams e opzionalmente avvia lo script di riavvio.

Query di controllo (ultime 24 ore) e conteggi:

$since=(Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-TerminalServices-Gateway/Admin'; Id=103; StartTime=$since} |
 Group-Object Id | Select-Object Name,Count

Rafforzare networking e bilanciamento

No SSL inspection sulla VIP/443 del gateway: RD Gateway usa tunnel TLS persistenti; l’intercettazione rompe la sessione.
Idle timeout TCP/HTTPS ≥ 60–120 min; Server timeout backend ≥ 5 min per gestire riavvii brevi.
Se usi un Load Balancer: health‑probe layer 7 “tollerante” (HTTP 200/403 su endpoint noti) e rimozione rapida del nodo unhealthy.

Hardening e buone pratiche

Certificato alternativo pronto (es. emesso da CA interna) per uno switch rapido se quello attuale risultasse corrotto.
CRL/OCSP: abilita e verifica il caching offline e la raggiungibilità dei CDP/OCSP, così da evitare handshake lenti e time‑out.
- Test tattico: certutil -url "C:\path\gateway.cer" e prova i punti CRL/OCSP elencati.
TLS moderni: su Windows Server 2019 applica TLS 1.2 only (TLS 1.3 non è supportato nativamente). Disattiva TLS 1.0/1.1 e suite deboli. Impostazioni di esempio (Registro di sistema) # Disabilita TLS 1.0/1.1, abilita TLS 1.2 (Server) New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Force | Out-Null New-ItemProperty -Path ...\TLS 1.0\Server -Name Enabled -Type DWord -Value 0 -Force | Out-Null New-ItemProperty -Path ...\TLS 1.0\Server -Name DisabledByDefault -Type DWord -Value 1 -Force | Out-Null New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Force | Out-Null New-ItemProperty -Path ...\TLS 1.1\Server -Name Enabled -Type DWord -Value 0 -Force | Out-Null New-ItemProperty -Path ...\TLS 1.1\Server -Name DisabledByDefault -Type DWord -Value 1 -Force | Out-Null New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null New-ItemProperty -Path ...\TLS 1.2\Server -Name Enabled -Type DWord -Value 1 -Force | Out-Null New-ItemProperty -Path ...\TLS 1.2\Server -Name DisabledByDefault -Type DWord -Value 0 -Force | Out-Null
Test di carico mirato: se i riavvii coincidono con picchi, verifica CPU/RAM/handle del processo e valuta la distribuzione del carico su più RD Gateway.
Windows release health: monitora regolarmente le note di rilascio per workaround ufficiali e date dei fix successivi.

Script e comandi utili

Controllo e riparazione associazione chiave

Se la chiave privata risulta “non associata” dopo un rinnovo, puoi tentare una riparazione:

# Sostituisci con il tuo thumbprint (senza spazi)
$tp = 'THUMBPRINTDELCERTIFICATO'
certutil -repairstore my $tp

Elenco e esportazione rapida del certificato in uso

Get-ChildItem -Path Cert:\LocalMachine\My |
  Where-Object Subject -like 'gateway.dominio.tld' |
  Select-Object Subject, NotAfter, Thumbprint

Esporta solo la parte pubblica (no chiave privata)

$cert = Get-ChildItem Cert:\LocalMachine\My$tp
Export-Certificate -Cert $cert -FilePath C:\Temp\RDGW.cer

Abilitare Recovery del servizio

Imposta il riavvio automatico ai primi tre errori:

sc failure tsgateway reset= 86400 actions= restart/60000/restart/60000/restart/60000

Query rapida Schannel

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; StartTime=(Get-Date).AddDays(-1)} |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Rilevare rapidamente sessioni attive prima del riavvio

Usa i contatori “Remote Desktop Gateway” per una soglia conservativa (esempio 3–5 connessioni) e coordina il riavvio con la finestra notturna.

Checklist operativa (quick‑win)

Conferma presenza dei KB: Get-HotFix.
Controlla Event ID 700/103 negli ultimi 7 giorni.
Ribinda il certificato in RD Gateway Manager.
Assegna Read su chiave privata a NT SERVICE\Tsgateway (o NETWORK SERVICE).
Abilita recovery del servizio e imposta un riavvio programmato (condizionato alle connessioni).
Valuta rollback di KB5043050 in ambienti idonei e sospensione della distribuzione fino al fix.
Rafforza TLS (solo 1.2) e controlla firewall/idle‑timeout.
Apri ticket a Microsoft per ricevere eventuali hot‑patch preliminari.

Domande frequenti

Il problema riguarda solo Windows Server 2019?

La casistica più ricorrente è su 2019 con i cumulativi indicati. Ambienti differenti e catene di certificazione diverse possono però mitigare o mascherare il sintomo.

Posso usare TLS 1.3 per evitare l’errore?

No. Windows Server 2019 non implementa nativamente TLS 1.3 per HTTP.SYS/RD Gateway; la raccomandazione è forzare TLS 1.2 e disabilitare 1.0/1.1.

È sufficiente ribindare il certificato una volta sola?

Se la causa è la perdita dei permessi sulla nuova chiave privata (post‑rinnovo), il ribind può bastare, ma devi sincronizzare i permessi sul container della chiave. In caso di bug lato servizio, il ribind da solo potrebbe non prevenire futuri reset.

Il rollback dei KB è sicuro?

È un workaround con impatto sul livello di patching: valuta il rischio e mantieni aggiornati gli altri ruoli. Prediligi un rollback selettivo e temporaneo con piano di rientro non appena disponibile il fix.

Strategia di rientro

La via maestra resta l’aggiornamento cumulativo che corregge il problema. Nel frattempo:

Applica i workaround (ribind/permessi, riavvii guidati, recovery del servizio).
Imposta monitoraggio proattivo su Event ID 103/700 e su contatori “Current/Active Connections”.
Documenta e isola il perimetro (VIP dedicata, no SSL inspection, timeout adeguati).
Prepara rollback controllato con check list e test post‑rollback (handshake TLS, catena CRL/OCSP, connessioni RDP attraverso RD Gateway).
Mantieni un canale aperto con Microsoft Support per accedere a eventuali hot‑patch.

In sintesi

Il malfunzionamento è legato a un bug introdotto dai cumulativi di settembre 2024 che può mandare in crash RD Gateway quando l’accesso al certificato SSL viene meno. Fino alla disponibilità della correzione definitiva:

verifica e ribinda il certificato, assicurando permessi corretti sulla chiave privata per l’account di servizio;
implementa un riavvio programmato (o auto‑recovery) del servizio e, se accettabile, un rollback mirato dell’ultimo KB problematico;
mantieni monitoraggio serrato via Event Viewer e un ticket ufficiale per ricevere fix anticipati;
rafforza il profilo TLS 1.2 only, ottimizza CRL/OCSP e rimuovi gli ostacoli di rete (SSL inspection, timeout).

Con queste misure riduci sensibilmente l’impatto in produzione senza rinunciare del tutto alla postura di sicurezza del server.

Appendice: safe‑rollout del prossimo cumulativo

Prepara una copia del certificato (PFX protetto) e verifica anticipatamente i permessi sul nuovo keyset.
Applica l’update su un nodo pilota in NLB o su un ambiente di test che riproduca CRL/OCSP/firewall reali.
Monitora per 48–72 ore: Event ID 103/700, Current/Active Connections, tempi di handshake TLS.
Se stabile, deployment graduale per cluster/regioni; in caso contrario, rollback immediato e escalation con log raccolti.