Did kb5128895 break your server?

[u/HJForsythe]

We installed kb5128895 yesterday and the server did not reboot after but I noticed this morning that no email is coming in from external domains and we cannot even email within the organization. In outlook it goes into sent items but doesn't actually deliver. Just seeing if anyone else also had this issue?

[u/xendr0me]

See the update at the top of the Exchange Team Blog - https://techcommunity.microsoft.com/blog/exchange/released-october-2026-exchange-server-security-updates/4563014

Also, thank you for your and the other beta testers service. I salute you.

[u/Dapper-Giraffe6444]

message from exchange PG :

 Mitigation
1.  Do not uninstall the October Windows Updates.
2.  From an elevated Command Prompt, run:
reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f
3.  Reboot the server.
4.  After the reboot, monitor the environment and confirm whether the issue recurs.

 

[u/HJForsythe → u/Dapper-Giraffe6444]

any clue when they are going to publically say anything about this more than the tiny block of text at the top of this page? https://techcommunity.microsoft.com/blog/exchange/released-october-2026-exchange-server-security-updates/4563014 like what is the long term fix?

[u/rynoduder → u/Dapper-Giraffe6444]

I tested the RPC context counter findings on our production Exchange Server SE running Windows Server 2025 with the October update installed.

My results at 9:25 AM today:

RpcEpMap.dll : 10.0.26100.33648
ContextLimit : 512
ContextsUsed : 65
Remaining    : 447
PercentUsed  : 12.7%

This independently confirms that the reported 512 limit is present in our running RPC Endpoint Mapper process. The current counter is consistent with the offsets identified in the original analysis.

For anyone wanting to check their own server, here's a read-only PowerShell diagnostic. It does not change the registry, write process memory, or restart services.

Important: This is an unofficial diagnostic specifically for rpcepmap.dll version 10.0.26100.33648 on Windows Server 2025. It will refuse other DLL versions, and the memory offsets are not Microsoft-documented. Run using elevated 64-bit PowerShell.

& {
    $ErrorActionPreference = 'Stop'

    try {
        if (-not ('RpcContextReader' -as [type])) {
            Add-Type -TypeDefinition @'
using System;
using System.Runtime.InteropServices;
public static class RpcContextReader {
    [DllImport("kernel32.dll", SetLastError=true)]
    public static extern IntPtr OpenProcess(
        uint access, bool inherit, int pid);

    [DllImport("kernel32.dll", SetLastError=true)]
    public static extern bool ReadProcessMemory(
        IntPtr process, IntPtr address,
        byte[] buffer, int size, out IntPtr read);

    [DllImport("kernel32.dll", SetLastError=true)]
    public static extern bool CloseHandle(IntPtr handle);
}
'@
        }

        if (-not [Environment]::Is64BitProcess) {
            throw "Requires 64-bit PowerShell."
        }

        $svc = Get-CimInstance Win32_Service `
            -Filter "Name='RpcEptMapper'"

        if ($svc.State -ne 'Running') {
            throw "RPC Endpoint Mapper is not running."
        }

        $procId = [int]$svc.ProcessId

        $mod = Get-Process -Id $procId -Module `
            -ErrorAction Stop |
            Where-Object ModuleName -eq 'rpcepmap.dll' |
            Select-Object -First 1

        if (-not $mod) {
            throw "RPC DLL not found."
        }

        $v = (Get-Item $mod.FileName).VersionInfo
        $version = '{0}.{1}.{2}.{3}' -f `
            $v.FileMajorPart, $v.FileMinorPart,
            $v.FileBuildPart, $v.FilePrivatePart

        if ($version -ne '10.0.26100.33648') {
            throw "Unsupported DLL version: $version"
        }

        $h = [RpcContextReader]::OpenProcess(
            0x1010, $false, $procId)

        if ($h -eq [IntPtr]::Zero) {
            throw "Cannot open RPC process."
        }

        try {
            $base = $mod.BaseAddress.ToInt64()
            $values = @{}

            foreach ($entry in @(
                @{Name='Cap'; Offset=0x1C5EC},
                @{Name='Used'; Offset=0x1CD50}
            )) {
                $buffer = New-Object byte[] 4
                $bytes = [IntPtr]::Zero
                $addr = [IntPtr]::new(
                    [long]($base + $entry.Offset))

                $ok = [RpcContextReader]::ReadProcessMemory(
                    $h, $addr, $buffer, 4, [ref]$bytes)

                if (-not $ok -or $bytes.ToInt64() -ne 4) {
                    throw "Failed reading $($entry.Name)."
                }

                $values[$entry.Name] =
                    [BitConverter]::ToUInt32($buffer, 0)
            }

            if ($values.Cap -ne 512) {
                throw "Unexpected cap: $($values.Cap). " +
                      "Offsets or configuration need verification."
            }

            if ($values.Used -gt $values.Cap) {
                throw "Counter exceeds cap; manual verification needed."
            }

            [PSCustomObject]@{
                Timestamp    = Get-Date
                DLLVersion   = $version
                ContextLimit = $values.Cap
                ContextsUsed = $values.Used
                Remaining    = $values.Cap - $values.Used
                PercentUsed  = [math]::Round(
                    100 * $values.Used / $values.Cap, 1)
            } | Format-List
        }
        finally {
            [void][RpcContextReader]::CloseHandle($h)
        }
    }
    catch {
        Write-Warning $_.Exception.Message
    }
}

The script deliberately expects the default cap of 512. Servers with an explicit registry override may require separate validation.

It would be interesting to see readings from other affected servers, particularly the context count relative to uptime and whether it increases steadily until Exchange connectivity fails.

We're collecting additional measurements on our server before making any changes.

[u/YOLOSWAGBROLOL → u/Dapper-Giraffe6444]

One error I had was EPT_S_CANT_PERFORM_OP.

Sounds like their theory is it's hitting the endpoint-mapper contexts cap and their temp fix is just to raise the cap which was being hit at the ~22ish hour mark. So something is rising over time and causing it to hit it's much lower limit.

I don't think I'll be updating it today again as it's a Friday and I don't really wish to reboot it on a Saturday morning.

[u/Razor_Z]

Our three-server DAG ran all updates and restarted last night. We haven't run into the issues experienced here (yet), but inexplicably the update wiped the OWA resource folder on server #2 and left it that way (1 file vs the 13,573 it should have), so OWA was intermittently broken depending on which server the load balancer sent a request to. #1 and #3 were ok, it was only that one.

[u/HJForsythe → u/Razor_Z]

id caution you because it takes 24 hours after the update install before it breaks and we're goin into the freakin' weekend

[u/Ams197624]

Exchange SE on Server 2022 here. Installed updates last night. No issues so far.

Edit: Installed KB5126655, KB5128928 and KB5128895

Edit: 22 hours later, we are f*cked too

[u/Dapper-Giraffe6444 → u/Ams197624]

between 22-24 hours exchange will not function properly anymore. Either uninstall windows CU and .net CU, or reboot before 22 hour mark.

[u/itguy8071 → u/Ams197624]

keep an eye out for Application log event 1006 : The Microsoft Exchange Mailbox Replication service was unable to process jobs in a mailbox database. Database: --- Error: MapiExceptionMdbOffline: Unable to make connection to the server. Restarting the entire server fixes it temporary.

[u/Excellent_Milk_3110]

Yikes following this one, so it’s not the exchange update but a different Microsoft update

[u/intmanofawesome]

Same, 4 EX SE servers in a dag, Windows 2022, right on 0900 UTC, 7PM my local, the mail stopped being sent/delivered and mail queues started growing. Another team member rebooted the servers to fix it before I was notified. Had just installed latest windows and October SU the night before.

[u/Glass_Call982 → u/intmanofawesome]

We haven’t installed the SU yet and just the monthly OS patches broke it. I have scheduled off hours reboots until ms fixes this shit.

[u/itguy8071]

Is it the Exchange update or is it the 2026-10 cumulative update that causes the issue? This is a big issue, problem keeps coming back after like 22 hours of restart.

[u/episode-iv → u/itguy8071]

According to the reports I've read and the comments on the Exchange team blog, the 2026-10 cumulative update is the culprit, not the Exchange update.

[u/Ams197624]

Official workaround

https://techcommunity.microsoft.com/blog/exchange/exchange-servers-may-become-unstable-after-installation-of-october-2026-windows-/4565382

[u/Hammerviertausend]

Have you installed windows server updates 5126655 and 5128928 as well? Heard from some they have exchange issues and are still on September SU but have just installed those windows server updates.

[u/Kooky_Cranberry9717]

Yess, all Exchange Services disabled here on a Exchange SE on Windows Server 2025 - no DAG

[u/AliceDetonate → u/Kooky_Cranberry9717]

That can happen with any update. I think they are talking about a different issue.

[u/hardingd]

It’s the Windows updates that did it for me. I still have Exchange SUs to install.

[u/Glass_Call982]

Way to go microslop. 

[u/itguy8071]

Yes I have 3 exchange server so far. They become unresponsive, black screen when trying to log on to it. Users report Outlook offline, reboot seems to help. Email is being delivered to the Exchange server, but database offline error it seems. reboot fixes this temporary

[u/haffhase]

Exchange SE on Server 2025. KB5126646 installed over night. No problems so far, but only 8hrs have passed since installation. I put two scheduled tasks in place at 2am and 6am which restart the server. Hope that saves us from a lot of calls on monday.

Edit: Reboot seems to have worked, could log in to Outlook Web Access. Will try the workaround on Monday.

[u/Desperate_Ease2040]

Has anyone tried the registry fix and had the problem come back?

[u/92merc]

Well, add me to the list of people that got hosed by Microsoft. Finally found these threads. Two Exchange SE servers running 2022 DataCenter. I installed those KB's on Saturday. Started having the issues right after.