Clarifying question around this statement:
"Also note that after November 2026 Windows Server update is installed, the registry key / workaround is no longer required."

Does this mean we need to manually remove the registry setting if we created it as a workaround after we Apply the November SU?

After applying the 65536 workaround our mailservers seemed to work fine. but last few days we had problems with outlook mobile clients. After rebooting all servers outlook mobile worked fine again. We did not (yet) install the november update.

Did anyone else have this problem? Could it be related to this article?

thx.

Nino_Bilic​  

Hi Nino.  With all of the vulnerabilities that the teams are working hard to remediate, is it reasonable to expect that Exchange SE HU/CU will be delayed until 2027?  In recent years the HU/CU hasn't been released in December in order to avoid the support staff working over the holidays.  That would mean if it is going to be released in the 2nd half of 2026, this is the month.  Any insight on this?

Of my own experience, we had 6 servers that needed a double reboot post applying that reg key for whatever reason. Signs were msot easily detected by running "get-mailboxdatabase -status" and you would get back an error along the lines of "Exchange can't get the size and the available space of the database" plus of course OWA access would fail.. Since then I've had no issues beyond the weird store status when running this command and wonndered if anyone else could try it and see if they get similar results.. This is Exchange SE sitting on Server 2025 (all latest patches applied) as part of a 6 node DAG. 

Get-ServerHealth <your_server> | Where-Object {$_.AlertValue -eq "unHealthy"} |Format-Table HealthSetName,Name,AlertValue -AutoSize

HealthSetName Name                                                    AlertValue
------------- ----                                                    ----------
Store         StoreMaintenanceAssistantMonitor                         Unhealthy
Store         DirectoryServiceAndStoreMaintenanceAssistantMonitor      Unhealthy
Store         StoreUrgentMaintenanceAssistantMonitor                   Unhealthy
Store         StoreOnlineIntegrityCheckMaintenanceAssistantMonitor     Unhealthy
Store         StoreScheduledIntegrityCheckMaintenanceAssistantMonitor  Unhealthy
Store         StoreCustomerExpectationMaintenanceAssistantMonitor      Unhealthy
Store         PhysicalDatabaseMaintenanceAssistantMonitor              Unhealthy
Store         StoreMaintenanceAssistantMonitor                         Unhealthy
Store         DirectoryServiceAndStoreMaintenanceAssistantMonitor      Unhealthy
Store         StoreUrgentMaintenanceAssistantMonitor                   Unhealthy
Store         StoreOnlineIntegrityCheckMaintenanceAssistantMonitor     Unhealthy
Store         StoreScheduledIntegrityCheckMaintenanceAssistantMonitor  Unhealthy
Store         StoreCustomerExpectationMaintenanceAssistantMonitor      Unhealthy
Store         PhysicalDatabaseMaintenanceAssistantMonitor              Unhealthy
Store         StoreMaintenanceAssistantMonitor                         Unhealthy
Store         DirectoryServiceAndStoreMaintenanceAssistantMonitor      Unhealthy
Store         StoreUrgentMaintenanceAssistantMonitor                   Unhealthy
Store         StoreOnlineIntegrityCheckMaintenanceAssistantMonitor     Unhealthy
Store         StoreScheduledIntegrityCheckMaintenanceAssistantMonitor  Unhealthy
Store         StoreCustomerExpectationMaintenanceAssistantMonitor      Unhealthy
Store         PhysicalDatabaseMaintenanceAssistantMonitor              Unhealthy

owa is working after restarting Exchange health manager service, still i should apply registry value update fix?

For those still having issues with OWA and ECP loading after adding the EpmapSavedContextCap reg entry, I just got through working with Microsoft.  In the end, we wound up running the UpdateCas.ps1 and UpdateConfigFiles.ps1 scripts from the Exchange default install location \Bin\ folder (elevated EMS).  The first one took quite a while.  Once both completed, restarted IIS and now both pages are working normally.

I am planning to install the October patches and apply this registry setting on my Exchange server over the next few days.

However, my environment has around 700 users who rely on Exchange services continuously. 

Could you confirm whether “65536” is sufficient? If I double the value, what impact will it have? What is the maximum value?

I sincerely hope to hear from Microsoft as soon as possible. Thanks.

The recommendation worked like a charm. 

Hello. We did not install any the update Windows Server ("KB5126655" / Windows Server 2022), only the KB5128928 ( .NET Framework 3.5, 4.8 und 4.8.1).

The problem appeared the day after the install.

Nino_Bilic​  

I found someone else mentioning that simply restarting the Microsoft Exchange Health Manager service would help to "fix" the problem for a while. And indeed it did. Immediately after stopping the service, the number of used context dropped from 512 to 0 and server immediately returned to normal. No server reboot required.

Maybe there is something in the Exchange code that's worth checking?

Any comments from Microsoft?