Exchange Server non risponde dopo gli update di ottobre di Windows Server: workaround RPC

Articolo aggiornato al 18 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Microsoft rilascia nuove correzioni.

Gli utenti non riescono più ad aprire Outlook sul web, Outlook resta disconnesso, le mail restano nella Posta in uscita e le code di trasporto continuano a crescere. Nell’Interfaccia di amministrazione di Exchange, però, i database risultano montati e tutto sembra a posto. Riavviate il server, la posta riparte, e dopo circa un giorno il problema si ripresenta identico.

In questi giorni stanno arrivando molte segnalazioni di questo tipo da chi ha ancora Exchange on-premises, e Microsoft ha confermato il problema: la causa non è l’aggiornamento di sicurezza di Exchange, ma l’aggiornamento cumulativo di Windows Server del 13 ottobre 2026, che ha introdotto un limite sulla memoria usata dall’Endpoint Mapper RPC. Sotto carico Exchange lo esaurisce e smette di rispondere. Esiste un workaround tramite registro, che vi spiego passo passo.

Chi è coinvolto

Sono interessati Exchange Server 2016, 2019 e Subscription Edition (SE) installati su server che hanno ricevuto gli aggiornamenti cumulativi di ottobre:

Windows Server 2025: KB5126646
Windows Server 2022: KB5126655
Windows Server 2019: KB5126651
Windows Server 2016: KB5126868

Non serve aver installato anche l’aggiornamento di sicurezza di Exchange di ottobre perché il problema si presenti. Il sintomo più riconoscibile è l’errore in OWA “MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142)”, accompagnato dall’evento 1006 nel registro Applicazione. Chi ha un DAG può vedere anche copie dei database che smettono di replicarsi e switchover che non vanno a buon fine. Il blocco non arriva subito: compare dopo alcune ore di uptime, di solito intorno alle 22-30, tanto prima quanto più il server è carico.

Perché succede

Secondo le note ufficiali degli aggiornamenti, l’update di ottobre ha aggiunto un limite predefinito alla memoria che l’Endpoint Mapper può usare per gestire le richieste di Endpoint Lookup: 512 chiamate simultanee. Per la maggior parte dei server è più che sufficiente, ma un carico come quello di Exchange, che vive di chiamate RPC, lo satura. A quel punto i servizi di Exchange non riescono più a parlare con i database, anche se questi sono formalmente montati.

Il workaround indicato da Microsoft nel blog del team Exchange consiste nell’alzare questo limite con il valore di registro EpmapSavedContextCap. Microsoft lo definisce una mitigazione temporanea, non la correzione definitiva.

Prima di iniziare

Io sconsiglio di disinstallare l’aggiornamento di Windows: lo sconsiglia anche Microsoft, perché togliereste tutte le correzioni di sicurezza di ottobre da un server che spesso è esposto su Internet, e la rimozione di un pacchetto cumulativo combinato con lo stack di servizio non è banale. La strada del registro è più rapida e reversibile.

Verificate di avere un backup recente e funzionante del server e dei database.
Pianificate un riavvio completo: senza riavvio la modifica non ha effetto, e riavviare solo i servizi di Exchange non basta.
Se avete un DAG, lavorate su un nodo alla volta.

Per prima cosa controllate che l’aggiornamento sia presente (sostituite il KB con quello della vostra versione) e se il valore esiste già:

Get-HotFix -Id KB5126655
reg query "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap

La procedura

Esportate la chiave RPC così com’è, per poter tornare indietro:

reg export "HKLM\SOFTWARE\Microsoft\Rpc" C:\Temp\rpc-backup.reg /y

Se avete un DAG, spostate i database attivi su un altro nodo prima di toccare il server (qui SRV01 è il server su cui lavorate, SRV02 l’altro membro):

Move-ActiveMailboxDatabase -Server SRV01 -ActivateOnServer SRV02

Da un prompt dei comandi avviato come amministratore create il valore DWORD con dato decimale 65536 (esadecimale 0x10000):

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Riavviate il server. Se avete un DAG, attendete che le copie tornino in stato “Healthy” prima di passare al nodo successivo:

Get-MailboxDatabaseCopyStatus -Server SRV01 | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState

Nei due giorni successivi tenete d’occhio le code di trasporto e il registro Applicazione. Visto che il blocco arriva dopo circa un giorno, io non considero chiuso il problema prima di aver superato almeno 36 ore di uptime senza errori:

Get-Queue | Where-Object {$_.MessageCount -gt 0} | Format-Table Identity,Status,MessageCount,LastError
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1006; StartTime=(Get-Date).AddDays(-2)} | Where-Object {$_.Message -like '*MdbOffline*'}

Attenzione: l’evento 1006 viene registrato da più componenti di Exchange, quindi contano solo le voci che citano MdbOffline.

Come tornare indietro

Quando Microsoft rilascerà la correzione definitiva conviene rimuovere il valore, per non lasciare in giro personalizzazioni di cui tra un anno nessuno si ricorderà. Se il valore non esisteva prima, basta eliminarlo e riavviare; se esisteva, reimportate il file rpc-backup.reg:

reg delete "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /f

Io annoto sempre la modifica nella documentazione del cliente, con data e motivo: è il modo più semplice per non trasformare un workaround in debito tecnico.

Se il problema persiste

Microsoft precisa che su alcuni server il valore potrebbe non bastare e che, per i casi più ostinati, è disponibile un’ulteriore mitigazione tramite il supporto Microsoft per le aziende. Il mio consiglio è di non andare per tentativi alzando il valore a caso: raccogliete i log e aprite una richiesta di supporto. Nel frattempo, se la posta non può fermarsi, l’unica difesa affidabile è un riavvio programmato ogni notte, ben dentro la finestra delle 22 ore, nodo per nodo se avete un DAG. Sui server Exchange che non avete ancora aggiornato, valutate se rimandare l’update di ottobre di qualche giorno, sapendo che è comunque un compromesso sulla sicurezza.

Vi è capitato di trovare Exchange bloccato dopo gli aggiornamenti di ottobre? Raccontate nei commenti su quale versione di Windows Server e se il valore di registro ha risolto: possono essere utili ad altri.