Another Microsoft 365 migration added to my checklist!

Microsoft has announced the retirement of the widely used Search-UnifiedAuditLog PowerShell cmdlet on October 15, 2027, following the general availability of the Microsoft Graph AuditLogQuery API.

If you use this cmdlet in scripts, you have about a year to plan and test your migration to AuditLogQuery.

Personally, Search-UnifiedAuditLog has been my go-to for quickly checking audit events. Purview's audit search can take several minutes, even for a simple query, so I'll miss having that quick PowerShell option.

https://blog.admindroid.com/search-unifiedauditlog-cmdlet-retirement/

I'm in the process of updating a single Exchange 2019 server to SE.

The server was running CU12 with extended protection enabled, all worked fine and saw no impact when I enabled extended protection.

I completed the update to CU15 yesterday, and instantly Outlook (Classic) clients started requesting credentials constantly.

I disabled extended protection and Outlook clients connected as ususal.

I have checked both client and server registry's and the LmCompatibilityLevel key doesn't exist, so I guess that adding this setting as 5 is my first job?

Can anyone suggest any other reason as to why extended protection worked with CU12 but not with CU15?

Clients are Windows 11, running Outlook Classic fully patched.

Thanks!

Environment: 2-node DAG, Exchange SE (SU11), Windows Server 2025 with KB5126646, hybrid with EXO.

We hit the known issue twice (~24h apart): MapiExceptionMdbOffline (ec=1142), Win32 0x6D8, DBs showing "Mounted" but Test-MAPIConnectivity failing, queues stuck to the DBs, passive copies going Failed. A reboot fixed it temporarily each time.

While troubleshooting I noticed lsass.exe handles were very high at the time of failure:

- Active node: ~44,000 handles

- Passive node: ~37,000 handles

handle64 -s -p lsass.exe shows almost all of it is Semaphore handles (~27,000 Semaphore out of ~32,000 total).

Today I applied Microsoft's workaround on both nodes:

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

+ reboot (proper DAG maintenance mode). Value confirmed 0x10000.

After the reboot, the LSASS Semaphore count is still climbing at about the same rate as before the fix:

- 14:33 – Semaphore 7,433 (total 12,324)

- 14:36 – Semaphore 8,251 (total 13,205)

- 14:44 – Semaphore 9,975 (total 15,016)

Roughly 200–340 per minute during business hours.

Questions:

1. Has anyone else seen the LSASS Semaphore handle growth with this issue? Does it keep growing for you after the EpmapSavedContextCap fix, or does it level off?

2. Is this growth actually what leads to the Store outage, or is it a separate side effect and the registry fix addresses the real failure (endpoint mapper) regardless?

3. For those who had to raise the limit further – what value did you use, and how long until it recurred at 65536?

We also didn't track LSASS handles before the October update, so I have no baseline for what's normal on these servers. Any numbers from your environments would help.

Thanks

Looks like Microsoft has put out a statement acknowledging the issues related with Exchange and the October 2026 Windows Server update.

Does anyone know what the "additional mitigations" are, that are available through Microsoft Support? If adding the EpmapSavedContextCap registry key is the workaround, what's the deal with "additional mitigating" options being made available only through support request?

Running Exchange Server 2019 CU15 on Windows Server 2019 with October 2026 updates installed (KB5126651).

Initially, Exchange would stop functioning properly after approximately 24 hours, requiring a reboot. Microsoft recommended adding EpmapSavedContextCap=65536 to address the RPC issue.

After applying the workaround and rebooting, we started experiencing different symptoms:

• Outlook intermittently freezes for 20–30 seconds when sending emails.
• Internal and external messages experience approximately 120-second delivery delays.
• Message tracking shows messages processing normally initially, then waiting about two minutes before multiple messages are delivered simultaneously.
• Exchange services, databases, and mail queues appear healthy.
• No significant CPU, memory, or disk performance issues.

Outlook and email delivery were responsive between reboots before applying the registry workaround.

We've removed the registry value and are preparing to restart and test again.

Is anyone else experiencing these delays after applying Microsoft's RPC workaround? Has anyone found a solution?

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?

Hi everyone,

I'm trying to understand a strange issue during an Exchange 2019 to Exchange Server SE migration.

Environment

• Exchange 2019
• Exchange Server SE
• Current Outlook versions (Microsoft 365 Apps)
• Internal and external namespaces:
  • owa.company.com
  • autodiscover.company.com

Original setup

The DNS record for Outlook/OWA pointed to Exchange 2019.

Clients connected like this:

Outlook ->Exchange 2019 -> Exchange SE

Everything worked fine.

What we changed

We swapped the IP addresses of the two Exchange servers so that the existing DNS records would resolve directly to Exchange SE.

Result: Outlook -> Exchange SE

Immediately after the change, many users started receiving Outlook credential prompts. After entering the password, Outlook continues to prompt for credentials repeatedly.

Symptoms

• Outlook repeatedly asked for username/password.
• OWA was working.
• Rolling back the IP swap immediately resolved the issue.

Checks performed

MAPI virtual directories

Both servers:

Get-MapiVirtualDirectory

Internal and External URL:

https://owa.company.com/mapi

on both Exchange 2019 and Exchange SE.

EWS virtual directories

Both servers:

https://owa.company.com/EWS/Exchange.asmx

Autodiscover

Get-ClientAccessService | fl AutoDiscoverServiceInternalUri

Both servers configured with:

https://autodiscover.company.com/autodiscover/autodiscover.xml

Test-OutlookWebServices

Executed against Exchange SE:

Test-OutlookWebServices

Results:

Autodiscover      Success

EWS               Success

Availability      Success

OAB               Success

Outlook Anywhere

Both servers configured identically:

Get-OutlookAnywhere | fl Server,Auth

Result:

ExternalClientAuthenticationMethod : Negotiate

InternalClientAuthenticationMethod : Ntlm

IISAuthenticationMethods           : Basic, Ntlm, Negotiate

Extended Protection

EWS:

Allow

on both servers.

MAPI:

Require

on both servers.

Get-MapiVirtualDirectory | fl Identity,ExtendedProtection

OAuth

Get-OrganizationConfig | fl OAuth*

Result:

OAuth2ClientProfileEnabled : False

Certificates

Exchange SE has a valid IIS certificate:

CN=owa.company.com

Services: IIS, SMTP

No certificate warnings were observed.

What confuses me

From everything I can see:

• URLs are identical.
• Authentication configuration appears identical.
• Extended Protection configuration is identical.
• Autodiscover works.
• EWS works.
• Modern Outlook clients.
• Exchange SE works correctly when tested directly.

Yet moving client traffic directly from Exchange 2019 to Exchange SE resulted in Outlook credential prompts, and reverting the change immediately fixed the issue.

Questions

Has anyone seen similar behavior during an Exchange 2019 → Exchange SE migration?

Possible areas I'm currently considering:

• Kerberos / SPN issues
• IIS Authentication differences not visible through Exchange cmdlets
• HTTPProxy authentication failures
• Extended Protection edge cases
• NTLM/Kerberos negotiation issues
• Something related to Exchange 2019 proxying requests differently than Exchange SE

Any ideas or similar experiences would be greatly appreciated.

Goodevening everyone,

We have some issues with AD split permissions and mail delivery to shared mailboxes.

Our environment consists of 6 Exchange servers (Server 2019 cu15): 4 are in a database availability group (DAG), and the other 2 are standalone.

Our L3 team enabled AD split permissions without considering the consequences. We needed this so that the Exchange admins can no longer create AD objects.

Since then, we have had problems sending mail to shared mailboxes. Mail from a shared mailbox to a user mailbox works fine, but mail to a shared mailbox results in an immediate NDR:

554 5.2.0 STOREDRV.Deliver.Exception: cannot open mailbox

So far we have recreated the DAG and the databases. Today I also installed a 6th Exchange server as a test, to see whether a freshly installed server would not have the issue.

Does anyone know where we should look before we tear down our setup and start from scratch?

https://techcommunity.microsoft.com/blog/exchange/released-october-2026-exchange-server-security-updates/4563014

⚠️EDIT 16/10 ⚠️
⚠️ BE AWARE! READ BELOW! ⚠️
👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇
https://techcommunity.microsoft.com/blog/exchange/exchange-servers-may-become-unstable-after-installation-of-october-2026-windows-/4565382

Where I work, we've got one employee who has been with the company something like 12 years, and receives a HIGH volume of email. We had to set his email online archiving rules to archive content every 30 days, just to make sure his 100GB email quota didn't get exceeded!

I guess this worked for years, because we pretty much forgot about him and his mailbox situation, until last week. We started getting complaints other people couldn't email him or send him meeting invites reliably without getting bounce-back errors.

When we investigated, it showed him as having about 350GB of "Recoverable Items".

Normally, I can fix that withe PowerShell command: start-managedfolderassistant -Identity "user@address.com" -HoldCleanUp

However, I seem to be unable to run it against his mailbox? Every time I try, it pauses a long time, followed by a page of error messages starting with:

Write-ErrorMessage : ||Grpc.Core.RpcException: Status(StatusCode="Unavailable", Detail="Error starting gRPC call. HttpRequestException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

We're speaking with his boss about a need to do more of his work outside of email (such as using MS Teams chat for more of the regular updates he gets), and we can potentially copy some of his older archived mail into shared mailboxes we could set up for him. But we've got to get his mailbox back into reliable working order first. What's the next step here?

Internal Server ErrorInternal Server Error

It's Monay night here WTF!!!

Dead , anyone else having these issues.

Hi Brains Trust,

I have a user with a large on prem mailbox, total size was over 400gig.

I setup an online archive in 365 with a retention policy/tag set to archive mail items older than 720 days (2 years).

We are in full hybrid, with Hybrid Modern Authentication.

The process was working very happily, until one day, it wasn't. The current online archive size is 267.6 GB, however, mail has stopped archiving.

ELCLastSuccessTimestamp is not updating

I'm getting an internal server error from the MRM diag logs. The exchange server was 2016 fully patched. I went to the extreme of building a new Exchange SE server (fully patched), moving the mailbox onto it, and still have the problem. Has anybody experienced the below error or have any suggestions on how to resolve the problem? We setup an online archive for another random user which is working. This then proves that the general system is ok, there is something about this one user.

Export-MailboxDiagnosticLogs my.user -ComponentName MRM

MailboxLog : 9/10/2026 8:36:21 AM Exception: Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcEwsException: ELC

EWS failed with error type: 'FailedToUpdateFolder'. Details: Export failed with error type:

'ExchangeWebServiceCallFailed'. Message: An internal server error occurred. Try again later., RPC call

failed to sync public folder. ---> Microsoft.Exchange.EDiscovery.Export.ExportException: Export failed

with error type: 'ExchangeWebServiceCallFailed'. Message: An internal server error occurred. Try again

later., RPC call failed to sync public folder.

--- End of inner exception stack trace ---

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcBaseServiceClient`2.InternalCallService[Base

ResponseMessageType](Func`1 delegateServiceCall, Action`1 responseProcessor, Func`2 exceptionHandler,

Func`1 authorizationHandler, Action`1 urlRedirectionHandler)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcEwsClient.CallEws(Func`1 delegateEwsCall,

Func`3 responseMessageProcessor, Func`2 exceptionHandler, ExchangeVersionType requestServerVersion,

String mailboxEmailAddress)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcEwsClient.CallService(Func`1

delegateEwsCall, Func`3 responseMessageProcessor, Func`2 exceptionHandler)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcEwsClient.UpdateFolder(FolderChangeType

folderChange)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.RemoteArchiveProcessorBase.UpdatePropertiesOnFo

lderInArchive(FolderTuple sourceInPrimary, FolderTuple targetInArchive)

at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate,

Action`1 catchDelegate)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.FolderHelper.SyncFolders(IArchiveProcessor

archiveHandler, FolderTuple sourceRoot, FolderTuple targetRoot, String traceId)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.FolderArchiver.SyncHierarchies()

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcTagSubAssistant.MapPolicyForArchive(MailboxD

ataForTags mailboxDataForTags)

at

Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcTagSubAssistant.InvokeInternal(MailboxSession

mailboxSession, MailboxDataForTags mailboxDataForTags)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcTagSubAssistant.Invoke(MailboxSession

mailboxSession, MailboxDataForTags mailboxDataForTags)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ELCAssistant.InvokeCore(MailboxSession

mailboxSession, List`1 customDataToLog, StatisticsLogEntry logEntry, ElcParameters parameters)

at Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ELCAssistant.<>c__DisplayClass30_0.<InvokeInter

nalAssistant>b__0()

at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate,

Action`1 catchDelegate)

I'm seeing approximately 40% storage overhead associated with BigFunnel indexing across all of my Exchange mailbox databases.

The behavior is remarkably consistent across databases, regardless of their age or how frequently mailboxes have been migrated into or out of them.

Some databases are less than a month old, with their first mailboxes migrated into them shortly after creation, so I wouldn't expect accumulated database whitespace or repeated mailbox migrations to explain the consistency.

Environment:

• 2 Exchange SE servers in a DAG
• Both servers were upgraded in place from Exchange Server 2019
• 2019 servers were built fresh and then had all mailboxes migrated from a 2016 dag a year ago
• There were some problems with indexing failing or not completing shortly after that migration
• Every mailbox database is exhibiting similar BigFunnel storage overhead

Questions:

1. Is approximately 40% BigFunnel indexing overhead normal for Exchange 2019/SE?
2. If not, what could cause the indexes to consume this much space consistently across databases?
3. Are there any diagnostic counters or tools that can help identify which components of BigFunnel are consuming the space?
4. If this is abnormal, is there a supported way to reduce the overhead without migrating all mailboxes to new databases? I'm skeptical that migration would help, since I'm seeing similar ratios even on recently created databases with only a few mailboxes migrated into them.

I'm particularly interested in hearing from anyone who has measured BigFunnel's actual storage overhead in a production Exchange 2019/SE environment.

Example of one database's stats

DatabaseSizeGB and AvailableNewMailboxSpaceGB are from Get-MailboxDatabase -Status. The BigFunnel figures are from examining the ESE table sizes.

MailboxCount                            :  290
DatabaseSizeGB                          : 2490.38 
AvailableNewMailboxSpaceGB              :    0.57 

Sum_TotalItemSizeGB                     : 1724.8
Sum_BigFunnelPostingListTableTotalSizeGB:  707.06
Sum_BigFunnelLargePOITableTotalSizeGB   :   36.62
Sum_BigFunnelFilterTableTotalSizeGB     :    2.54
Sum_BigFunnelTableSizeGB                :  746.22

BigFunnelPctOfTotalItemSize             :   43.3%
Sum_ItemPlusBigFunnelGB                 : 2471.03

So for this database

Mailbox item size       1724.80 GB
BigFunnel tables         746.22 GB
                       ----------
Combined                2471.02 GB

Physical EDB            2490.38 GB

So the BigFunnel tables are approximately 43.3% of the summed mailbox TotalItemSize.

The combined mailbox item size and identified BigFunnel tables also come quite close to the physical EDB size (2471 GB vs. 2490 GB), so this does not appear to simply be hundreds of GB of database whitespace.

I'm seeing similar proportions across the other mailbox databases.

Edit/ removed some redundancy

Hi, question for the community I'd like a second opinion on:

I'm working on decommissioning an Exchange 2016 server, currently in hybrid mode using Azure AD (Entra) Sync to sync with on-prem AD. There is only 1 server in the environment.

All mailboxes, contacts and groups have been migrated to 365 and I have moved the SOA (Exchange attributes only) to the cloud for all migrated users.

Originally the plan was to uninstall Exchange and just manage all Exchange properties from 365 but I'm kind of debating with myself if I should just turn the VM off.

Is there any benefit to just turning off the Exchange server and keeping the AD schema around or will it just lead to corruption? This is the last and only Exchange server.

OTOH Is there even any point to holding onto the AD schema if the SOA is in 365?

I know you can install the RSAT tools to manage it in powershell. I wasn't planning on bothering with it but now I'm wondering. I was going back and forth with a colleague about it but haven't yet made up my mind.

I've never done this before so I'd appreciate the perspective of someone who has.

Thanks!

EDIT: Thanks everyone for the help. I think I'm going to stick to my original plan and I'm going to uninstall Exchange. I appreciate the input.

Hey guys,

I've been beating my head against the wall for a couple days trying to figure this out. Here's my situation.

We're an on-prem organization, soon moving to Exo. We just moved our offices and with that comes new conference rooms. Well that would be fine except no one knows our new conference room names so everyone's trying to use the All Rooms portion of the Address book. When you try to get to All Rooms, it errors with the typical OAB needs to be available error:

The operation could not be completed because an offline address book is not available. Download a copy of the offline address book. This is the built in All Rooms address list. We have a pretty default setup for all of this, nothing special.

I've done so many things to troubleshoot this I'm kind of at a loss.

GAL works.

The list populates in OWA.

Checked vdirs, they're null as expected.

Checked db's and if they're assigned to the db, they weren't so it should go to the global default but that wasn't working so I applied it to the db's. No fix.

Made sure the oab URL is responsive and working. It is.

Checked iis logs and everything says success codes. No error codes.

The other thing, is if you search for a term like "conf" in the address book, it returns the conference rooms. I'm assuming it's because that goes to the server and actually connects.

This is limited to the Outlook client.

There's more I've done, but looking for suggestions.

Edit: meant Exchange SE

Hi, just to confirm with the recent deprecation of EWS services, etc. Will Migrations in a hybrid env still work? I believe the MRS services uses EWS iirc? Or since that is on prem EWS, it's fine?

Thanks

Hello,

I need some ideas about what might be causing this.

I'm running an Exchange cluster with a load balancer.

Every day at after noon, some (not all!) MAPI clients lose their connection (not all at once, and they establish the connection on/off), and sending and receiving emails takes longer.

There is no unusual server load, no request attacks, backups or anything similar.

The problem started around the time Exchange Hybrid was enabled.

Any ideas?

I have an old 2016 hybrid exchange server (yes I know it’s EOL). Not wanting to update to SE, can I just set my users to use the cloud as an SOA for exchange and shut down the hybrid?

We are using Entra Connect for sync so I understand write back may be limited but that shouldn’t be the end of the world right?

I assume user creation would be create in AD -> sync -> create Exchange mailbox in cloud? Any good documentation on this?

What and why

As previously communicated in MC1466860 and MC1447678, Microsoft is continuing the retirement of Exchange Web Services (EWS) in Exchange Online.

Beginning October 10, 2026, setting EWSEnabled=True will no longer be sufficient to allow EWS access for affected Worldwide tenants. Organizations that require EWS must configure EWSAllowedAppIDs to specify which applications are permitted to access EWS.

This change is part of the final phase of EWS retirement and is intended to help organizations identify EWS dependencies, reduce service disruption, and support migration planning.

Rollout schedule

• Worldwide, GCC, GCC High, DoD: Beginning in early October 2026 and expected to complete by early July 2027

Key milestones for Worldwide tenants with EWSEnabled=True and no configured EWSAllowedAppIDs list:

Impact on your organization

Who is affected

• Exchange Online administrators
• Organizations that continue to use applications or services that depend on EWS
• Tenants with EWSEnabled=True

Platforms and services

• Exchange Online
• Exchange Web Services (EWS)

What will happen

• Beginning October 10, 2026, affected Worldwide tenants with EWSEnabled=True must have a configured EWSAllowedAppIDs allow list. Applications not included in the allow list may lose access to EWS.
• For identified Worldwide tenants with EWSEnabled=True and no configured EWSAllowedAppIDs list on October 3 2026, Microsoft creates and populates an allow list using EWS activity observed during the previous 60 days. Infrequently used applications may not be identified.
• Cross-tenant organization relationships are not affected by the EWSAllowedAppIDs requirement.
• Organizations remain responsible for reviewing, validating, and maintaining EWSAllowedAppIDs.
• EWSAllowedAppIDs is a replacement list. Ensure all required AppIDs are included whenever the configuration is updated.
• Microsoft applications and scenarios that may generate EWS traffic include Outlook for Windows, Classic Outlook for Mac, Excel Power Query, Power BI, and Exchange Server hybrid scenarios.
• Outlook for Windows customers should be on August 2026 build 16.0.20430.20092 or later. If EWS-related issues continue after disabling EWS, the cause may be customer-forced configuration. Test whether blocking EWS for the Office client AppID is possible without impact.
• New Outlook for Mac is not affected. If your organization continues to use Classic Outlook for Mac, ensure the Microsoft Office AppID is included in EWSAllowedAppIDs.
• Tenants with EWSEnabled not configured (Null) remain subject to Microsoft's phased EWS retirement process and will have EWS disabled as part of that rollout.
• Organizations with EWSEnabled=True and a configured EWSAllowedAppIDs allow list will not have their EWSEnabled setting modified by Microsoft before April 2027.

Action required and recommendations

If your organization relies on EWS:

• Review EWS usage reports and identify applications and services that require continued EWS access.
• Configure and validate an EWSAllowedAppIDs allow list before October 10, 2026.
• Include Microsoft first-party applications that continue to rely on EWS if they appear in your usage reporting.
• Ensure all required AppIDs are included whenever EWSAllowedAppIDs is updated.
• Keep the allow list current as applications are added, removed, or migrated away from EWS.
• Enable EWS only when required for approved applications.
• Continue planning migration from EWS to Microsoft Graph where possible.

To verify the configured allow list: Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Allow up to 24 hours for EWSAllowedAppIDs changes to take effect and approximately one hour for EWSEnabled changes.

Important: EWSAllowList is unrelated to EWS retirement and does not replace EWSAllowedAppIDs.

Microsoft finally published concrete dates for the EWS retirement (MC1485116). If EwsEnabled is $true in your tenant, an EwsAllowedAppIDs list is required from October 10. Microsoft only builds that list for tenants that had $true and no list on October 2, and it does that on October 8–9.

That also explains why so many of you saw an empty EwsAllowedAppIDs list this week. Tenants that never configured EwsEnabled are turned off later, in a second phase with a 7-day warning. The catch is setting $true this week without a list. You miss the snapshot, nobody builds a list for you, and on October 10 everything not on the list loses access.

Full details of the new phased schedule:

https://lazyadmin.nl/office-365/ewsallowedappids-required-from-october-10-what-changed-and-what-to-do-now/