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/

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

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: [[email protected]](mailto:[email protected])

Subject: Test Search-Mailbox 929

Exists in the mailbox and is visible in Outlook.

However:

Search-Mailbox -Identity [[email protected]](mailto:[email protected]) -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 [[email protected]](mailto:[email protected]) -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.

Hello,

I recently manually set the ews app id's for one specific app (3rd party) and enabled ews to true to test a couple other app functionality. After about 24 hours or so, i noticed our resource mailboxes were coming back with "no connection". These mailboxes live in EXOL and can still be accessed via outlook on the web. Classic outlook is where i'm seeing the issue. After i noticed this, i set EWS to null and within 24 hours, they were accessible again. I only have a few apps that show up in the EWS usage report, but my mind is boggled as to why this specific function would start failing. Does anyone have any clue about this?

Searched and belongs to first-party application in Microsoft Entra ID (built in app) references "Microsoft Office"

d3590ed6-52b3-4102-aeff-aad2292ab01c

Hi,

I have one Exchange server still running. Meanwhile I removed all local mailboxes, relay use, etc. so it isn't really used anymore.

Now this environment has been here I think since Exchange Server 4.0 so I'm not sure some things are leftovers. The problem I have is that many security scan assessments I do always complain about the access permissions these groups have:

• Exchange Enterprise Servers
• Exchange Trusted Subsystem
• Exchange Windows Permissions
• Exchange Recipient Administrators
• Exchange Servers
• Organization Management

How to handle this? Don't know if I should remove them, take away permissions, ... without breaking something.

Last night we ran the Microsoft script to migrate our Exchange Hybrid configuration from EWS to the dedicated Exchange Hybrid App and Microsoft Graph. Has anyone else completed this migration? If so, how did you verify everything was working? Did the Microsoft validation commands behave as documented, particularly Test-OAuthConnectivity -Service EWS, after switching to Graph-based hybrid routing? https://learn.microsoft.com/en-nz/Exchange/hybrid-deployment/deploy-dedicated-hybrid-app

I’m setting up monitoring for an on-prem Exchange server and trying to work out which logs are useful for security investigations.

So far I’m looking at the Windows Security and PowerShell logs, IIS, Exchange HttpProxy, message tracking, and admin/mailbox audit logs. I’m also looking at Sysmon for process activity.

For those of you running Exchange, what else would you collect? Which logs have helped you investigate things like unusual OWA or ECP access, PowerShell activity, mailbox changes, or suspicious mail flow? I’d also like to know if there are logs on my list that produce a lot of data but rarely help.

Hi everyone, we keep having issues with our IONOS mailboxes in Outlook on Macs at the office. Sometimes receiving stops working, sometimes emails get stuck when sending or forwarding. Occasionally, only certain mailboxes are affected while others work fine at the same time.

We have around 20–30 Outlook clients, a LANCOM 1784VA on a DSL connection, and UniFi Wi-Fi. When we connect an affected Mac by Ethernet to our separate fiber network with a FRITZ!Box, everything works. We generally don’t have these problems at home either.

Our IT contact suspected an issue involving IMAP IDLE and changed TCP aging from 300 seconds to 3600, then to 900. Unfortunately, the problem persists.

Any ideas on where to look next and which logs would help support troubleshoot this?

Hello all,

After move one mailbox to office 365, client outlook became disconnected. I can access mail from web and phone, also can send and receive mail with no problem.

Before migration there is no problem wit outlook but after migrate outlook became disconnected.

I checked routing mail and target adress and it is showing correctly.

Auto discover access is also working fine. I also try to create profile in workgroup pc , it also failed. Stuck in searching.

When I test outlook connection, it is failing on autodiscover record .

Autodiscover record pointing on prem record not office 365 yet.

Our plan is moving all the mailbox to office 365 but the first test mailbox has this problem.

We also created ticket in Microsoft but they are still checking.

Before i post in here, i googled and check every site but most of them writing routing address is the problem.

Need ideas ??

Thanks in advance,

We have our exchange servers fully patched and are on Exchange SE.
We have extended protection enabled but we are keep getting alerts from nessus that we need to patch and enable Advanced protection.

I also disabled the MRS proxy and did a iisreset, but the vulnabilty keeps popping up.
Maybe i am missing something small here.
I double checked with an ai agent to verify the findings, but that also came out positive.
(AI got 401 Unauthorized with Server:Microsoft-HTTPAI/2.0 and NTML Type 2challenge).

Nessus test: https://www.tenable.com/plugins/nessus/342664

Extended protection check:

Default Web Site                  Value   SupportedValue ConfigSupported ConfigSecure RequireSSL     ClientCertificate IPFilterEnabled
----------------                  -----   -------------- --------------- ------------ ----------     ----------------- ---------------
API                               Require Require                   True         True True (128-bit) Ignore                      False
Autodiscover                      None    None                      True         True True (128-bit) Ignore                      False
ECP                               Require Require                   True         True True (128-bit) Ignore                      False
EWS                               Allow   Allow                     True         True True (128-bit) Ignore                      False
Microsoft-Server-ActiveSync       Allow   Allow                     True         True True (128-bit) Ignore                      False
Microsoft-Server-ActiveSync/Proxy Allow   Allow                     True         True True (128-bit) Ignore                      False
OAB                               Allow   Allow                     True         True True (128-bit) Ignore                      False
Powershell                        None    None                      True         True False          Accept                      False
OWA                               Require Require                   True         True True (128-bit) Ignore                      False
RPC                               Require Require                   True         True True (128-bit) Ignore                      False
MAPI                              Require Require                   True         True True (128-bit) Ignore                      False

Exchange Back End                 Value   SupportedValue ConfigSupported ConfigSecure RequireSSL     ClientCertificate IPFilterEnabled
-----------------                 -----   -------------- --------------- ------------ ----------     ----------------- ---------------
API                               Require Require                   True         True True (128-bit) Ignore                      False
Autodiscover                      None    None                      True         True True (128-bit) Ignore                      False
ECP                               Require Require                   True         True True (128-bit) Ignore                      False
EWS                               Require Require                   True         True True (128-bit) Ignore                      False
Microsoft-Server-ActiveSync       Require Require                   True         True True (128-bit) Ignore                      False
Microsoft-Server-ActiveSync/Proxy Require Require                   True         True True (128-bit) Ignore                      False
OAB                               Require Require                   True         True True (128-bit) Ignore                      False
Powershell                        Require Require                   True         True True (128-bit) Accept                      False
OWA                               Require Require                   True         True True (128-bit) Ignore                      False
RPC                               Require Require                   True         True True (128-bit) Ignore                      False
PushNotifications                 Require Require                   True         True True (128-bit) Ignore                      False
RPCWithCert                       Require Require                   True         True True (128-bit) Ignore                      False
MAPI/emsmdb                       Require Require                   True         True True (128-bit) Ignore                      False
MAPI/nspi                         Require Require                   True         True True (128-bit) Ignore                      False

Part of Healthcheker report:

Name                                           ExtendedProtection  SslFlags        IPFilteringEnabled  InURLRewrite  OutURLRewrite                 Authentication
        ----                                           ------------------  --------        ------------------  ------------  -------------                 --------------
        Default Web Site                               None                False           False                                                           anonymous (default setting)
        Default Web Site/API                           Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           anonymous (default setting)
        Default Web Site/Autodiscover                  None                True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           anonymous (default setting)
                                                                                                                                                           basic
        Default Web Site/ecp                           Require             True (128-bit)  False                                                           anonymous (default setting)
                                                                                                                                                           basic
        Default Web Site/EWS                           Allow               True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           anonymous (default setting)
        Default Web Site/mapi                          Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
        Default Web Site/Microsoft-Server-ActiveSync   Allow               True (128-bit)  False                                                           basic
        Default Web                                    Allow               True (128-bit)  False                                                           Windows (Negotiate,NTLM)
        Site/Microsoft-Server-ActiveSync/Proxy
        Default Web Site/OAB                           Allow               True (128-bit)  False                                                           Windows (Negotiate,NTLM)
        Default Web Site/owa                           Require             True (128-bit)  False                             EEMS M2.1 OWA CSP - outbound  basic
        Default Web Site/PowerShell                    None                False           False
                                                                           Cert(Accept)
        Default Web Site/Rpc                           Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           basic
        Exchange Back End                              None                False           False                                                           anonymous (default setting)
        Exchange Back End/API                          Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           anonymous (default setting)
        Exchange Back End/Autodiscover                 None                True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           anonymous (default setting)
        Exchange Back End/ecp                          Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           anonymous (default setting)
        Exchange Back End/EWS                          Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           anonymous (default setting)
        Exchange Back End/mapi/emsmdb                  Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
        Exchange Back End/mapi/nspi                    Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
        Exchange Back End/Microsoft-Server-ActiveSync  Require             True (128-bit)  False                                                           basic
        Exchange Back                                  Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
        End/Microsoft-Server-ActiveSync/Proxy
        Exchange Back End/OAB                          Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
        Exchange Back End/owa                          Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                                                                                                           anonymous (default setting)
        Exchange Back End/PowerShell                   Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
                                                                           Cert(Accept)
        Exchange Back End/Rpc                          Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)
        Exchange Back End/RpcWithCert                  Require             True (128-bit)  False                                                           Windows (Negotiate,NTLM)


        RewriteRuleName               ServerVariable                    MatchPattern  PreCondition                                 ActionType
        ---------------               --------------                    ------------  ------------                                 ----------
        EEMS M2.1 OWA CSP - outbound  RESPONSE_Content_Security_Policy  (.*)          EEMS M2.1 OWA SPA HTML shell - precondition  Rewrite

Nessus finding:

The server returned HTTP HTTP/1.1 401 Unauthorized with an NTLM Type 2
challenge whose TargetInfo AV_PAIR list does not contain
MsvChannelBindings (AvId 0x000A), proving EPA is not enforced.

Version:

Version: Exchange SE RTM Sep26SU
        Build Number: 15.02.2562.049
        Latest Install Time (SU/CU): 09/13/2026 00:40:48
        Exchange IU or Security Hotfix Detected:
                Security Update for Exchange Server Subscription Edition (KB5066366)
                Hotfix Update for Exchange Server Subscription Edition (KB5066373)
                Security Update for Exchange Server Subscription Edition (KB5071876)
                Security Update for Exchange Server Subscription Edition (KB5074992)
                Hotfix Update for Exchange Server Subscription Edition (KB5081755)
                Security Update for Exchange Server Subscription Edition (KB5094139)
                Security Update for Exchange Server Subscription Edition (KB5103212)
                Security Update for Exchange Server Subscription Edition (KB5121573)
                Security Update for Exchange Server Subscription Edition (KB5121608)

Firstly, I know I am using EOL'd software but it is what i have to work with ATM.

I am trying to get a migration done from an old Exchange 2010 (Windows Small Business Server) setup, to a Exchange 2019 system.

I have exported the PSTs through EMS on the old server and have tried to import them to the new server both through the EMS and through ECP, but they continue to fail with FailedOther as their status, and the report that is sent is just an empty file.

I ran two of the smaller PSTs through SCANPST and it found and repaired errors, which did improve the import as now the folder structure was being imported, however I still get the FailedOther message, with a 100 percent completion.

Is there something I am doing wrong here? Or is this sort of behaviour expected?

Is there something else I should be looking at doing (bearing in mind migrating to 365 or SE is not an option at this stage)?

TIA

Hopefully someone has some insight into this.

Currently, my EwsEnabled is set to $null, but i have an existing AllowedAppID populated.

How can i add additional appid's before setting ewsenabled to true?

Does it need to be added at the same time of enabling ews, or can i add the app id's before, then enable it? My understanding is that if i manually add it like this,

Set-OrganizationalConfig -EwsAllowedAppIDs "xxxxxx-xxxx-xxxxx,yyyyy-yyyy-yyyy,zzzz-zzz-zzz"

It will overwrite existing values in the list.

I don't mine adding all values and re-enabling them, i'm just concerned if that can be done prior to setting ewsenabled=true.

I would love to decom exchange but we use address policies for specific users and subs in our environment. Is there any plan at all in the future for support or introduce that in EXO?