The first reports came from administrators who had done what they were told to do. They installed the October security updates for Windows Server on October 13, the monthly patch date, restarted, and found that Outlook on the web would not let anyone sign in. The error was MapiExceptionMdbOffline, with the code ec=1142 attached, which is the message Exchange produces when it believes the mailbox database is not reachable. Event ID 1006 appeared in the application log shortly after.
By Monday Microsoft had confirmed the problem and published it on its release health dashboard and in a support article. The cause is not the October update for Exchange itself. It is the cumulative security update for Windows Server, in any of four versions: KB5126646 for Windows Server 2025, KB5126655 for Windows Server 2022, KB5126651 for Windows Server 2019 and KB5126868 for Windows Server 2016. Any on-premises Exchange server running on an affected build can be hit, across Exchange Server 2016, 2019 and the Subscription Edition.
The symptoms progress in a way that makes the first hour misleading. Mail queues grow through the day, so delivery slows rather than stopping, and a restart clears the backlog for a while. Servers under light load may show nothing at all, which is why some administrators reported a clean patch cycle and others reported an outage. On clusters, members of a database availability group can lose the ability to communicate, which puts failover at risk at the moment failover is most likely to be needed.
The mechanism is a limit that the updates impose on a Windows component. According to Microsoft’s description, the October builds cap the number of concurrently stored RPC Endpoint Mapper contexts at 512 by default. Exchange accumulates those contexts as it handles client connections, and under load it reaches the ceiling, after which new RPC connections fail.
The mailbox databases are healthy. The Exchange services are running. What has run out is a table that nobody configured and most administrators had never heard of.
That detail matters because of what it implies about who is affected. The exposure is a function of workload, so the largest and busiest servers go down first and the smallest may never show a symptom. It also explains why a restart helps temporarily, and why the interval between restarts shortens as the day goes on. It is not a corruption and not a data-loss event. It is exhaustion.
Microsoft’s guidance is specific and deliberately does not include rolling back. Administrators are told to keep the October updates installed and instead add a registry value on each affected server from an elevated command prompt, setting EpmapSavedContextCap under HKLM\SOFTWARE\Microsoft\Rpc to 65536, then restart and monitor. If the problem returns, the value goes higher. The company says the change has resolved the issue in the customer cases it has assisted.
The instruction not to uninstall is the part that captures the position on-premises customers are in. The October Windows Server updates carry fixes for vulnerabilities that Microsoft has judged serious enough to ship, and removing them restores those vulnerabilities along with the mail flow. An administrator therefore chooses between an unpatched server and a server that cannot deliver mail, and is asked to make that choice with a registry edit at whatever hour the queue starts to back up.
Cloud customers do not face the decision. Exchange Online runs on Microsoft’s build and Microsoft’s schedule, and the failures described this week do not reach it. The organizations affected are the ones that kept their mail servers in their own racks, usually for reasons of regulation, data residency, customization or the cost of migration, and that now carry an operational burden the hosted product has absorbed. That trade has always existed. It becomes visible when a monthly update goes wrong.
The larger pattern is the bundling of the monthly update. A cumulative security update for Windows Server is not a narrow fix for one flaw; it contains changes across the operating system, tested together and shipped on a schedule that does not vary with the complexity of what is inside. Exchange is a large, stateful application that exercises many of those components at once, and the interaction between a hardening change in the RPC layer and the connection behavior of a mail server is precisely the kind of thing that a lab test of a patch can miss and a production server at 10 a.m. cannot.
Microsoft has said it is investigating and will update the article. A proper fix will probably arrive as a revised update or a smaller hotfix, and administrators will apply it during a maintenance window they did not plan. In the meantime the workaround is a registry value that raises a limit, which is a way of buying time rather than a repair.
What the episode shows is that the patch has become its own category of risk. The monthly cycle exists because the alternative, shipping fixes whenever they are ready, produced worse outcomes. What it also produces is a single date on which hundreds of thousands of servers change at once, and a class of failure that arrives with the remedy rather than with the attack. For the people who run mail for a living, the calculation is now familiar: test in a ring, wait a week if the calendar allows, watch the queue, and keep the registry command where it can be found at two in the morning.
