Exchange cau 24 hores després del pedaç d'octubre, i la mitigació desfà el pedaç

Cinc-cents dotze entre vint-i-tres coma set dona vint-i-una hores i mitja. Aquesta divisió és el temps que el teu servidor d'Exchange aguanta des que instal·les l'actualització de Windows Server d'octubre fins que les bústies comencen a desconnectar-se. Si vas aplicar el pedaç dimarts a la tarda, el correu es va aturar dimecres a mig matí, amb la finestra de canvi tancada, l'acta signada i ja ningú no mirava cap al pedaç.

Què van posar les actualitzacions del 13 d'octubre

Les actualitzacions de seguretat de Windows Server publicades el 13 d'octubre del 2026 —KB5126646 per a Windows Server 2025, KB5126655 per al 2022, KB5126651 per al 2019 i KB5126868 per al 2016— introdueixen un límit nou a l'Endpoint Mapper, la peça del subsistema RPC de Windows que resol quin port dinàmic atén cada servei. El límit és de 512 contextos de cerca desats alhora, i viu a RpcEpMap.dll.

La nota de Microsoft al tauler d'estat de Windows ho explica com un límit de memòria: «l'actualització d'octubre del 2026 va introduir un límit per defecte en la quantitat de memòria que fa servir l'Endpoint Mapper en gestionar crides de resolució d'extrems. Per a càrregues de treball com Exchange Server, el límit per defecte de 512 crides simultànies de resolució d'extrems pot no ser suficient amb càrrega alta». Aquesta redacció és, en bona part, la raó que ningú no lligui la fallada amb el pedaç: «simultànies» sona a una cosa que s'allibera sola quan la càrrega baixa, i el que el límit compta són contextos desats, que s'acumulen i no es deixen anar. D'aquí les vint-i-una hores. No és un pic de càrrega: és un dipòsit que s'omple. I la nota deixa fora per què apareix aquest límit. Qui ho ha posat per escrit és Michel de Rooij, que localitza el canvi a RpcEpMap.dll i el relaciona amb CVE-2026-96300: un consum descontrolat de recursos (CWE-770) en el mateix servei Endpoint Mapper d'RPC, puntuat 5,9, que permet a qualsevol equip capaç de parlar amb aquest servei esgotar-li la memòria i tombar-lo. Si aquesta lectura és correcta —i encaixa amb tota la resta—, el límit de 512 és la correcció d'aquella fallada. Microsoft no ho diu a la pàgina de l'actualització.

Per què triga un dia a notar-se

Denis Grebner ho va mesurar en un servidor de correu en producció i va publicar els números a Franky's Web: 135 contextos en 5,68 hores de servei, 23,7 per hora. Amb un límit de 512 i sense que res els alliberi, el comptador arriba al sostre a les 21,6 hores —i el servidor que va mesurar va caure a les 21 hores i 27 minuts—. Els casos documentats situen la caiguda entre les 20 i les 24 hores segons la càrrega. A partir d'aquí, l'Endpoint Mapper deixa de lliurar extrems i les peces d'Exchange que parlen entre si per RPC —que són gairebé totes— es queden sense manera de trobar-se.

Vint-i-una hores de retard trenquen el procediment de canvi sencer. Una finestra de manteniment típica dura dues hores, tres si l'equip és generós. S'instal·la, es reinicia, es comprova que entra el correu web, que surt un missatge de prova i que les bases estan muntades, i es tanca l'acta. Totes aquestes comprovacions passen. Passen perquè en aquell moment el servidor porta vint contextos dels 512 i no hi ha res a veure.

Què veuràs quan s'ompli

Els símptomes arriben per parts i cap no diu «RPC». El que s'està veient:

• Usuaris que no poden iniciar sessió a Outlook on the Web, i clients Outlook que perden la connexió amb la bústia.
• Missatges que es queden a la safata de sortida i cues que creixen sense lliurar.
• Còpies de base de dades d'un DAG que deixen de replicar.
• Al registre d'aplicació, Event ID 1006 de MSExchange Mailbox Replication amb MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142).
• El que apunta al lloc correcte: Event ID 4082 de MSExchangeRepl, on el gestor de xarxa de replicació falla amb OpenCluster(...) failed with 0x6d9 i, al final de la traça, «There are no more endpoints available from the endpoint mapper».

Mentre tot això passa, les bases de dades continuen apareixent connectades i muntades al centre d'administració d'Exchange. És a dir, el teu tauler diu que el servei està bé mentre les bústies són inaccessibles. Si la teva monitorització comprova l'estat de muntatge de les bases en lloc de fer una connexió de client de debò, no te n'assabentaràs per aquí: te n'assabentaràs pel telèfon.

La mitigació de Microsoft, i la lletra petita

Microsoft recomana apujar el límit des d'un símbol del sistema amb privilegis i reiniciar:

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

Són 65536, cent vint-i-vuit vegades el límit original, i Microsoft afegeix que si el problema persisteix es pot apujar més. El fabricant no et dona el número correcte, et dona un número gran i la instrucció d'engrandir-lo. Ningú no sap quin és el teu número perquè depèn de la teva càrrega, i això inclou qui va escriure la nota.

Microsoft és explícita a més en dues coses, i convé no fondre-les. Primera, l'imperatiu: «no desinstal·leu les actualitzacions de Windows Server d'octubre del 2026». És a dir, el pedaç que voldràs treure a les tres de la matinada és justament el que et demanen que deixis posat. Segona, que la causa no és a les actualitzacions d'Exchange: «els problemes reportats no estan relacionats amb la instal·lació de les actualitzacions de seguretat d'octubre del 2026 per a Exchange Server». A la pàgina de la mateixa actualització hi afegeixen que Suport de Microsoft pot facilitar una mitigació addicional als equips afectats, i que el cas continua en investigació. I hi ha un tercer punt que no és a la nota però sí al que explica qui ho ha patit: reiniciar el servidor neteja els contextos i fa desaparèixer el símptoma, durant unes altres vint hores. Aquesta és la trampa que converteix una fallada en una llegenda d'oficina —«va bé, el vaig reiniciar dilluns»— i la raó que hi hagi gent que ha passat el cap de setmana a sobre dels seus servidors.

La contrapartida, dita en veu alta

Si el límit de 512 és la correcció de CVE-2026-96300, apujar-lo a 65536 és desfer gairebé tota aquella correcció. És la conseqüència directa i convé que estigui escrita al tiquet, no sobreentesa. Dit això, la nostra recomanació és que apliquis la mitigació. Un correu aturat és una avaria d'avui, mesurable en persones que no treballen; el CVE és una denegació de servei de 5,9 que requereix que algú tingui línia oberta amb el teu Endpoint Mapper. No són riscos de la mateixa mida un dimecres a la tarda.

Però amb dues condicions que no són negociables. La primera: el port 135/TCP no ha d'estar publicat a internet. Si ho està, el teu problema d'avui no és el valor de registre, és el port, i el CVE és la menor de les coses que et poden passar per allà. La segona: aquest EpmapSavedContextCap és ara una dependència no documentada de la disponibilitat del teu correu. No viatja en cap pedaç, no surt en cap inventari de programari i desapareix el dia que algú reinstal·li aquell servidor des d'una plantilla. Posa-li un responsable, posa-li data de revisió i apunta-ho on s'apunten les coses que cal desfer.

Què fer aquesta setmana

• Comprova quina KB té instal·lada cada servidor Windows que allotgi Exchange. Si és una de les quatre de dalt, estàs afectat.
• Busca Event ID 4082 i 1006 al registre d'aplicació dels últims set dies, encara que ningú no s'hagi queixat. Un servidor que es reinicia cada nit per una altra raó pot portar dies fregant el sostre sense creuar-lo.
• Aplica el valor de registre i reinicia. En un DAG, node a node.
• Registra el canvi com a temporal, amb la data en què cal revisar-lo i el motiu (CVE-2026-96300) escrit al costat. Un valor sense motiu escrit sobreviu anys.
• Verifica des de fora que 135/TCP no respon des d'internet. Avui, no de memòria.
• Canvia la comprovació de la teva monitorització: que faci una connexió de client real a la bústia, no que llegeixi l'estat de muntatge de la base. Aquesta fallada deixa el tauler en verd.
• I apunta al calendari revisar la nota del tauler d'estat de Windows: quan surti la correcció definitiva, cal treure el valor.

Dues hores de validació per a una fallada de vint-i-una

La validació va durar dues hores. La fallada en va trigar vint-i-una a néixer. Una finestra de canvi que acaba abans que la fallada existeixi certifica que la instal·lació va acabar, i això és tot el que certifica. Aquest desfasament hi continuarà sent quan aquest pedaç concret sigui un record.

El que sí que funciona és poc glamurós: un servidor primer i la resta després, amb una separació més gran que el temps que triga la fallada més lenta que coneixes. Si tens un DAG, tens el laboratori posat —actualitza un node, espera quaranta-vuit hores, actualitza el següent—. Si només tens un servidor de correu, la separació l'has de comprar en un altre lloc: als anells de desplegament de la resta del parc, on el lloc de treball va al davant i t'avisa. D'això en vam parlar fa poc a propòsit de qui prova els canvis abans que tu, i el raonament és el mateix aquí.

Si encara tens Exchange 2016 o 2019

La fallada els afecta igual —2016, 2019 i Subscription Edition són a la llista—, però la sortida no és la mateixa. El suport d'Exchange Server 2016 i 2019 va acabar el 14 d'octubre del 2025. La pàgina de Microsoft ho enumera sense eufemismes: des d'aquella data no hi ha suport tècnic, ni correccions d'errors que afectin l'estabilitat i usabilitat del servidor, ni correccions de seguretat, ni actualitzacions de zona horària. L'única versió on-premises suportada és Exchange Server SE.

Dit d'una altra manera: aquesta setmana apliques el valor de registre i en surts, però la propera incidència que necessiti una correcció del producte no en tindrà. És el mateix raonament que apliquem a propòsit de l'Exchange que vas deixar encès, el servidor que continua al bastidor perquè cal per gestionar els destinataris: des d'octubre del 2025, aquell servidor no té ningú a qui trucar.

I no, anar-se'n al núvol no és la resposta fàcil

El 12 d'octubre del 2026, vuit dies abans d'escriure això, un canvi de configuració va fer que el centre d'administració d'Exchange Online retornés errors interns als administradors durant unes 5,4 hores, fins que Microsoft va revertir el canvi. Ningú no va tocar cap registre, ningú no va reiniciar res i ningú no va poder fer res mentre va durar.

El que canvia en moure's a Microsoft 365 no és que desapareguin les caigudes: és quin tipus de fallada et toca i qui passa el cap de setmana amb ella. Perds el servidor que se t'omple de contextos RPC i el valor de registre que ningú no recorda; guanyes una dependència que no pots reiniciar: quan cau, l'única palanca que tens és un número d'incidència. Quan ens ho trobem, el canvi sol tenir sentit —desapareix un inventari de màquines i desapareixen nits—, però té sentit amb els ulls oberts i un pla per als dies en què el tauler està en vermell i tu no tens comandament. Això últim, que és el que ningú no inclou a la proposta de migració, és el que posem per escrit abans de moure la primera bústia.

Fonts i mètode: la cita de Microsoft sobre el límit per defecte és a la mateixa pàgina de l'actualització, a l'apartat de problemes coneguts de KB5126646 (Windows Server 2025, compilació 26100.33650, 13 d'octubre del 2026), consultada el 20 d'octubre del 2026; allà mateix consta que Suport de Microsoft pot facilitar una mitigació addicional. L'imperatiu literal sobre no desinstal·lar les actualitzacions de Windows Server i la frase sobre les actualitzacions d'Exchange surten de l'avís de l'equip d'Exchange a Tech Community del 16 d'octubre del 2026 — techcommunity.microsoft.com. La llista de símptomes i l'ordre exacta procedeixen de la cobertura de BleepingComputer del 19 d'octubre del 2026 — bleepingcomputer.com. Els números de KB per versió de Windows Server, la finestra de 20-24 hores i el detall que les bases continuen apareixent muntades al centre d'administració procedeixen de l'article de Frank Zöchling a Franky's Web; el mesurament de 23,7 contextos per hora (135 contextos en 5,68 hores), la projecció de 21,6 hores i la caiguda real de 21 h 27 min són de Denis Grebner, publicades al fil tècnic d'aquest mateix article; tots dos a frankysweb.de; els Event ID 1006 i 4082 i el codi 0x6d9 procedeixen de l'anàlisi de Michel de Rooij — eightwone.com, que és també qui situa el límit a RpcEpMap.dll i el relaciona amb CVE-2026-96300; la nota pública de Microsoft que hem llegit no enllaça explícitament totes dues coses. La descripció de CVE-2026-96300 (consum descontrolat de recursos, CWE-770, 5,9) procedeix de la seva fitxa pública. Les dates i condicions de fi de suport d'Exchange Server 2016 i 2019 són de la pàgina oficial de Microsoft — learn.microsoft.com. La caiguda del centre d'administració d'Exchange Online del 12 d'octubre del 2026 i la seva durada aproximada estan recollides per Petri — petri.com. Insistim que la projecció de 21,6 hores no és nostra; el que és nostre és la lectura d'aquell número: és més llarg que qualsevol finestra de canvi que hàgim vist signar. No tenim telemetria pròpia d'aquest incident: tot l'anterior és lectura de documentació pública i dels informes de qui sí que ho ha patit. El que sí que és nostre és el criteri: la recomanació d'aplicar la mitigació, les dues condicions que li posem i la llista d'aquesta setmana.