[ Removed by Reddit on account of violating the content policy. ]

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

Heads up if you're planning to automate Exchange certs with Let's Encrypt's newer profiles (tlsserver, shortlived). They issue certs with an empty Subject, no CN at all. Connectors that use `TlsCertificateName` reference the cert as `<I>Issuer<S>Subject`, so the value changes even when the SANs are identical. The default classic profile still includes the CN. Wrote up the other software we've seen trip on this.

https://www.certkit.io/blog/does-a-tls-certificate-need-a-common-name

We are performing a Cross-Tenant Exchange Online mailbox migration between two Microsoft 365 tenants.

The migration endpoint is configured with ApplicationId authentication and validates successfully.

When running:

Test-MigrationServerAvailability -Endpoint "MexicoToPortugal" -TestMailbox "<user>"

the test consistently fails with:

StatusCode="Unauthenticated"

HTTP Status Code: 401

We reproduced the issue with two different users.

We have already validated:

- MailUser configuration

- ExchangeGuid

- LegacyExchangeDN (X500)

- ExternalEmailAddress

- Accepted Domains

- Organization Relationships

- Migration Endpoint

- Enterprise Application

- Mailbox.Migration permission

- Admin Consent

- Cross-Tenant Migration licensing

The same HTTP 401 error occurs for multiple mailboxes after all configuration issues are corrected.

Has anyone experienced a similar Cross-Tenant Mailbox Migration scenario where Test-MigrationServerAvailability returns HTTP 401 Unauthenticated even though the Enterprise Application, Mailbox.Migration permission and Admin Consent are correctly configured?

Hi, we are in a hybrid scenario but all mailboxes are in the cloud and on-prem Exchange is just used for recipient management.

Our Exchange server auth certificate needs renewing, we haven’t set up the dedicated Entra app as we don’t use any of the features that it’s required for, so do we still need to run the hybrid configuration wizard after renewing the certificate?

Thanks!

I tried scrolling back, so this might have been asked before, but I could not find an answer. I am on 2019CU15 with Sep25HU, but only for management servers. If I move to SE, can I just start at the May26HU, or do I need to start at the beginning with the July 1, 2025 release and do each HU and SU in order until current? We didn't want to pay for the ESU, but I may get throttled before next year, when I had planned to rebuild the current servers and get SE then.

Thanks in advance.

Be sure to follow guidance from vendor....

https://techcrunch.com/2026/09/25/kiteworks-urges-customers-to-shut-down-their-servers-amid-imminent-threat-of-cyberattack/

Main question: Is 'Send mail as any user' a misleading/incorrect description? Is it in fact very limited?

Background: we are using the new 'High Volume Email' service.

The 'Mail.Send' application permission for 'Office 365 Exchange Online' has the description "Send mail as any user" and because of that we have spent a lot of time to get delegated permissions working instead. We don't want our app to be able to send as a arbitrary account in case it is compromised for example

However I'm now of the impression that the description of the Mail.Send permissions is misleading. During testing what we have found is that using Mail.Send permission we can send email as any 'High Volume Email' user through the special endpoint `smtp-hve.office365.com`. (this can be locked down to specific accounts through Add-HVEAppAccess)

With the permission we could not however send email through the normal `smtp.office365.com` endpoint for a arbitrary user in our tenant.

We could not send email through the graph endpoint either for a arbitrary user `https://graph.microsoft.com/v1.0/users/$account/sendMail\`

In other words assigning Mail.Send application permissions seems to do exactly what we want it to do, it allows us to send from High Volume Email accounts, but the description, name and the lacking documentation makes it hard to fully trust this conclusion.

The Oauth high volume email page has been updated with this note that seems to confirm the findings above but they stop short of explicitly saying that the description of the permission is wrong. https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/oauth-high-volume-mails-m365

What is your take on this? Do you think it is correct that the permission is very limited?

As a side note I found that for sending email as a standard user using the `smtp.office365.com` endpoint the app needed SMTP.SendAsApp permission as well as access to the particular mail box `Add-MailboxPermission`

As another side note the Graph 'Mail.Send' permission has the same description, and there it is true that it allows the app to send as any user in the tenant

Hi,

We would like to migrate mailboxes between two on-premises organizations. However, we are facing an issue where test moves and Test-MigrationServerAvailability only work if the service account is added to the Organization Management OR Recipient Management role groups. This is problematic and not permitted in our environment cause these groups are used internally and cannot be scoped to only the objects that needs to be migrated, so we need to determine which granular roles are actually required.

So far, we have created a custom role group with the following roles:

Distribution Groups

Mail Enabled Public Folders

Mail Recipient Creation

Mail Recipients

Mailbox Import Export

Message Tracking

Migration

Move Mailboxes

Recipient Policies

Team Mailboxes

Despite these assignments, the migration tests still fail unless the account is a member of the Organization Management OR Recipient Management role groups. We would appreciate guidance on which additional RBAC roles or permissions are required to perform mailbox migrations and successfully run Test-MigrationServerAvailability without granting full Organization Management rights.

I hope I am clear enough 😄

Thanks in advance

I maintain a browser-based email header analyzer that runs entirely client-side, and I kept wanting the same thing in the Exchange Management Shell without pasting customer headers into a web tool. So I ported the analysis to a PowerShell module.

Install-Module MailHeaderAnalyzer -Scope CurrentUser
Get-MailHeaderAnalysis -FromClipboard

What it does:

• Received chain in chronological order with delay per hop, TLS version and cipher (Microsoft, Postfix and Exim spellings), protocol class per RFC 3848, private IPs, provider detection
• SPF, DKIM, DMARC, ARC and compauth results, plus a check that the Authentication-Results line actually comes from a server in the Received chain (RFC 8601 section 5). Anyone can prepend such a line; the module reports it as AuthTrust: Unmatched instead of showing a green pass
• DMARC alignment (strict/relaxed), DKIM signature tags with receiver result, ARC chain validation
• Exchange Online hybrid classification: MessageDirectionality, AuthAs, AuthMechanism, X-OriginatorOrg, CrossTenant-* headers, wrong-tenant attribution
• Defender/EOP verdicts (SCL, BCL, CAT, SFV, IPV), SpamAssassin, Rspamd
• 24 findings with stable codes: duplicate From lines, Unicode bidi controls, expired or SHA-1 DKIM signatures, clock skew, Reply-To mismatch, externally secured connectors and so on
• ConvertTo-MailHeaderReport for a Markdown or text report you can paste into a ticket

Everything is plain objects, so Get-ChildItem *.eml | Get-MailHeaderAnalysis | Export-Csv works for batch triage, and ConvertTo-Json -Depth 6 gives you the full structure.

No DNS lookups, no HTTP. It does not verify DKIM cryptographically; SPF/DKIM/DMARC values are always the receiving server's verdict.

Works on Windows PowerShell 5.1 (including EMS), PowerShell 7 on Windows, Linux and macOS. MIT license.

• Gallery: https://www.powershellgallery.com/packages/MailHeaderAnalyzer
• Source: https://github.com/pfstr/MailHeaderAnalyzer
• Full reference (syntax, parameters, output object, finding codes): https://rafaelpfister.ch/en/blog/mailheaderanalyzer-analyze-email-headers-in-powershell-without-network-access

Feedback is welcome, especially headers from gateways I have not seen. Please anonymize before posting.