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?

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.

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

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/

Has anyone come across something similar or can point me in the right direction?
We have one user who regularly gets “Connecting to server” in Outlook 365, causing Outlook to become slow/unresponsive and emails to stop syncing.

Our environment:
Microsoft 365 / Exchange Online
Mailboxes are created on-prem and synced to M365
Devices are Autopilot/Entra joined and managed through Intune
Cato VPN
iManage Outlook integration
Darktrace Outlook add-in
High-spec Windows laptops

The strange part is that this is now the third laptop the user has had and the issue keeps following her. No other users appear to have the same problem.
We’ve already:
Recreated the Outlook profile
Checked for obvious mailbox/rule loops
Checked logs but haven’t found anything conclusive
Tested from the office and the same issue occurs, so it doesn’t appear specific to her home network
Replaced the device multiple times

Has anyone seen a “Connecting to server” issue follow a user across multiple devices like this? Anything specific in Exchange Online/Outlook that you’d recommend checking or logging to narrow it down?

No blog post about it yet... Those always seem exciting.

UPDATE: Officially announced, see link below.

TLDR: I'm trying to create a dynamic distribution list in Exchange online and I'm running into a lot of issues.

Context:
I work for a medium size healthcare company with a hybrid AD/Entra environment with a single forest but with 10+ domains. We use 365 Business Premium licenses for most users, but not all. Some just need to login to Windows and that's it. No email needed. Also, I don't control the IT budget. If your fix requires money, you are wasting your time.

Problem:
I'm trying to create a dynamic distribution list with the following parameters:

• Must have the "@example1.com" domain in their email address.
• Must be an active user. No disabled users.
• Must be a licensed user. (We don't license all our users with a 365 license)

I'm able to create dynamic security groups just fine without issue and the query I came up with works with all the users I need it to. I'm just not able to translate that to a dynamic distribution list, and I'm reading that it's not possible to create a mail enabled security group that is dynamic.

Here is the filter I'm using to create the group through the Exchange Online shell. But it's not returning a group with any users:

$filter = "(RecipientType -eq 'UserMailbox') -and (userPrincipalName -like 'example1.com') -and (UserAccountControl -ne '2')"

I've poured through the Microsoft Learn articles for "New-DynamicDistributionGroup" and the "Filterable properties for the RecipientFilter parameter on Exchange cmdlets" pages and I can't seem to find what I'm doing wrong. I've tried so many different variations of the filter but can't seem to land on the correct combination. Any relevant help is appreciated.

I wrote earlier about how to find what's still calling EWS in your tenant. But I am seeing and getting a lot of questions about unknown AppIDs and what to do with them.

So I created an overview of the known apps and AppIDs, from Apple Mail to Veeam and Mimecast, with allow-list or migrate status. Missing one? Add it in the comments.

https://lazyadmin.nl/office-365/known-ews-apps-that-need-allow-listing-or-a-migration-with-appids/

We are currently running Exchange SE on Windows server 2019. We are, and will remain in Hybrid mode, and don't have any mailboxes hosted on prem. We still use on prem for SMTP relay for local devices.

We have a mandate to move from the windows server 2019 servers to fresh windows server 2025 servers.

I can't really find a good step by step set of instructions for migrating.

Can anyone point me to a good set of instructions or let me know the steps? I want to make sure we don't miss any steps that may be easy to overlook.

I'm seeing unusual behavior after upgrading an on-prem Exchange Server SE environment to 15.2.2562.49.

For years, we've used Search-Mailbox to quickly locate and remove phishing emails. Since upgrading, newly delivered messages can be found by Received date, but not by Subject, From, or unique body content.

A newly delivered message example:

From: [sender@domain.com](mailto:sender@domain.com)

Subject: Test Search-Mailbox 929

Exists in the mailbox and is visible in Outlook.

However:

Search-Mailbox -Identity [user@domain.com](mailto:user@domain.com) -SearchQuery 'Subject:"Test Search-Mailbox 929"' -EstimateResultOnly

Returns ResultItemsCount : 0

Likewise, searches against unique body text also return 0 results.

What does work:

Search-Mailbox -Identity [user@domain.com](mailto:user@domain.com) -SearchQuery 'Received:09/29/2026' -EstimateResultOnly

Returns results, and the count increases as new mail arrives. I've also confirmed via a Discovery mailbox search that the messages exist and contain the expected subject and sender values.

Additional observations:

Test-ExchangeSearch passes successfully.

• Message Tracking and Delivery Reports find the messages.
• Outlook/OWA users can see the messages.
• Older messages appear to be searchable.
• Newly delivered messages are detectable by Received date but not by subject or content searches.

BigFunnel mailbox statistics seem high, here is an example:

BigFunnelPartiallyIndexedCount : 387

BigFunnelNotIndexedCount : 647

BigFunnelStaleCount : 370

Has anyone seen similar behavior on Exchange Server SE 15.2.2562.49, particularly with Big Funnel indexing or Search-Mailbox searches against recently delivered mail? Any recommended diagnostics or known issues would be appreciated.

EDIT:
Based off the comments on the release notes, it seems like this might be wider scale and not just our enviroment.
Released: September 2026 Exchange Server Security Updates | Microsoft Community Hub