Microsoft’s Exchange team reported October 16 that certain October Windows Server updates can cause instability in Exchange 2016, 2019, and Subscription Edition. Symptoms include Outlook on the web failures, growing mail queues, and database-availability-group problems. Microsoft says severity and time to onset vary with server load.
The affected Windows updates are KB5126646, KB5126655, KB5126651, and KB5126868. Microsoft distinguishes this issue from October’s Exchange security updates. Its guidance advises retaining the Windows updates and applying a documented RPC registry mitigation, followed by a reboot and monitoring. Administrators should consult that guidance for the procedure; a temporary recovery does not establish a permanent fix.
NAOAT analysis
This incident changes what a successful maintenance check needs to mean. A server that accepts a login immediately after restarting may still accumulate a workload problem later. Verification should therefore include both an immediate functional test and observation during the subsequent operating period, rather than closing the change solely because services started.
For an email environment, the most useful evidence is an end-to-end transaction. A test message should reach the intended mailbox, and the team should examine whether queues clear under ordinary activity. A healthy web interface and a running transport process are useful signals, but neither alone proves delivery.
The change record should preserve the operating-system update, Exchange version, mitigation state, and observation window separately. That makes it possible to compare affected and unaffected servers without assuming that every update installed on the same day caused the problem. It also helps the next shift understand why a server is operating with a temporary configuration.
For service providers, customer communication should distinguish restored mail flow from completed remediation. The former is an observed service outcome; the latter requires a durable resolution and a decision about any temporary setting. This recommended distinction keeps an apparently successful reboot from becoming the last documented action in a recurring incident.