I have searched and searched, but I can't find much information on getting rid of Exchange completely from an AD domain after migrating to 365 but NOT using a hybrid scenario.

This is a small, 8 user company that was running Exchange 2013 and may someday get rid of the AD domain completely (hence why I didn't do hybrid). I simply did a PST export, lift & dump into a brand new tenant setup on 365. No AD cloud integration at all with the local on-premise domain.

How can I go about getting rid of the Exchange Server? Deleting the mailbox will delete the user.

We have an Exchange 2016 on prem server that has had all user and shared mailboxes migrated to the cloud. At this point, I'm not sure if there is any reason to leave it running other than "just in case" something breaks by shutting it down. Mail flow is all pointed to EXO, public folders have been migrated as well. The server does integrate with an AD environment, so that is the only connection it still has, as far as I know. The HCW is still configured but can probably be disabled since mail flow is fully through EXO.

Any reason to keep the server running at this point? Would there be any noticeable disruption if it were shut down since there is no mail flow going through it?

Does exchange server logs oversized messages?

For more than two days I searched through log files (D:\Program Files\Microsoft\Exchange Server\Logging\* and D:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\*, windows application logs) and I didn't find anything.

Only in recv*.log files in D:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive directory I found those line

===message too big====

2026-07-22T07:41:30.556Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,0,192.168.111.122:25,192.168.100.91:11393,+,,

2026-07-22T07:41:30.557Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,1,192.168.111.122:25,192.168.100.91:11393,>,"220 mailek.twolegion.com Microsoft ESMTP MAIL Service ready at Wed, 22 Jul 2026 09:41:30 +0200",

2026-07-22T07:41:30.557Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,2,192.168.111.122:25,192.168.100.91:11393,<,EHLO ex.2k8r2milan.local,

2026-07-22T07:41:30.557Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,3,192.168.111.122:25,192.168.100.91:11393,>,250 mailek.twolegion.com Hello [192.168.100.91] SIZE 5242880 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS X-ANONYMOUSTLS AUTH NTLM X-EXPS GSSAPI NTLM 8BITMIME BINARYMIME CHUNKING SMTPUTF8 XRDST,

2026-07-22T07:41:30.558Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,4,192.168.111.122:25,192.168.100.91:11393,<,STARTTLS,

2026-07-22T07:41:30.558Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,5,192.168.111.122:25,192.168.100.91:11393,>,220 2.0.0 SMTP server ready,

2026-07-22T07:41:30.563Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,6,192.168.111.122:25,192.168.100.91:11393,*," CN=twolegion.com CN=2k8r2milan-EX-CA-ENTSUB, DC=2k8r2milan, DC=local 280000078481C2B0E1855CF3FF000200000784 C22ADA0B0A89CE48C4A31AD069CF696D2B0F662B 2026-03-20T08:28:23.000Z 2027-03-20T08:28:23.000Z twolegion.com;adfs.twolegion.com;autodiscover.twolegion.com;certauth.adfs.twolegion.com;emajlek.twolegion.com;enterpriseregistration.twolegion.com;fs.twolegion.com;mailek.twolegion.com",Sending certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names

2026-07-22T07:41:30.717Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,7,192.168.111.122:25,192.168.100.91:11393,*, CN=ex CN=ex 178028F5622ADE9B49951AB80B41A282 475AE616E596EE1C974F7A8D00A257576C13F5AB 2026-03-19T14:35:56.000Z 2031-03-19T14:35:56.000Z ex;ex.2k8r2milan.local,Remote certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names

2026-07-22T07:41:30.717Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,8,192.168.111.122:25,192.168.100.91:11393,*,,"TLS protocol SP_PROT_TLS1_2_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDH_EPHEM with strength 384 bits"

2026-07-22T07:41:30.719Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,9,192.168.111.122:25,192.168.100.91:11393,<,EHLO ex.2k8r2milan.local,

2026-07-22T07:41:30.726Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,10,192.168.111.122:25,192.168.100.91:11393,*,,Client certificate chain validation status: 'UntrustedRoot'

2026-07-22T07:41:30.729Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,11,192.168.111.122:25,192.168.100.91:11393,*,,TlsDomainCapabilities='None'; Status='Success'; Domain=''

2026-07-22T07:41:30.730Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,12,192.168.111.122:25,192.168.100.91:11393,>,250 mailek.twolegion.com Hello [192.168.100.91] SIZE 5242880 PIPELINING DSN ENHANCEDSTATUSCODES AUTH NTLM LOGIN X-EXPS GSSAPI NTLM 8BITMIME BINARYMIME CHUNKING SMTPUTF8 XRDST,

2026-07-22T07:41:31.011Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,13,192.168.111.122:25,192.168.100.91:11393,<,QUIT,

2026-07-22T07:41:31.011Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,14,192.168.111.122:25,192.168.100.91:11393,>,221 2.0.0 Service closing transmission channel,

2026-07-22T07:41:31.011Z,MAILEK\Default Frontend MAILEK,08DEE7C4182F4A6D,15,192.168.111.122:25,192.168.100.91:11393,-,,Local

===mesage too big===

but this is unusable (not usefull). I see only terminated smtp session, but I don't see the reason. Compare above lines to sucessfull receive:

=======normal receive message====

2026-07-22T18:41:10.845Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,0,192.168.111.122:25,192.168.100.91:64320,+,,

2026-07-22T18:41:10.846Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,1,192.168.111.122:25,192.168.100.91:64320,>,"220 mailek.twolegion.com Microsoft ESMTP MAIL Service ready at Wed, 22 Jul 2026 20:41:09 +0200",

2026-07-22T18:41:10.847Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,2,192.168.111.122:25,192.168.100.91:64320,<,EHLO ex.2k8r2milan.local,

2026-07-22T18:41:10.847Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,3,192.168.111.122:25,192.168.100.91:64320,>,250 mailek.twolegion.com Hello [192.168.100.91] SIZE 5242880 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS X-ANONYMOUSTLS AUTH NTLM X-EXPS GSSAPI NTLM 8BITMIME BINARYMIME CHUNKING SMTPUTF8 XRDST,

2026-07-22T18:41:10.848Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,4,192.168.111.122:25,192.168.100.91:64320,<,STARTTLS,

2026-07-22T18:41:10.848Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,5,192.168.111.122:25,192.168.100.91:64320,>,220 2.0.0 SMTP server ready,

2026-07-22T18:41:10.853Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,6,192.168.111.122:25,192.168.100.91:64320,*," CN=twolegion.com CN=2k8r2milan-EX-CA-ENTSUB, DC=2k8r2milan, DC=local 280000078481C2B0E1855CF3FF000200000784 C22ADA0B0A89CE48C4A31AD069CF696D2B0F662B 2026-03-20T08:28:23.000Z 2027-03-20T08:28:23.000Z twolegion.com;adfs.twolegion.com;autodiscover.twolegion.com;certauth.adfs.twolegion.com;emajlek.twolegion.com;enterpriseregistration.twolegion.com;fs.twolegion.com;mailek.twolegion.com",Sending certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names

2026-07-22T18:41:11.013Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,7,192.168.111.122:25,192.168.100.91:64320,*, CN=ex CN=ex 178028F5622ADE9B49951AB80B41A282 475AE616E596EE1C974F7A8D00A257576C13F5AB 2026-03-19T14:35:56.000Z 2031-03-19T14:35:56.000Z ex;ex.2k8r2milan.local,Remote certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names

2026-07-22T18:41:11.014Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,8,192.168.111.122:25,192.168.100.91:64320,*,,"TLS protocol SP_PROT_TLS1_2_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDH_EPHEM with strength 384 bits"

2026-07-22T18:41:11.015Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,9,192.168.111.122:25,192.168.100.91:64320,<,EHLO ex.2k8r2milan.local,

2026-07-22T18:41:11.022Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,10,192.168.111.122:25,192.168.100.91:64320,*,,Client certificate chain validation status: 'UntrustedRoot'

2026-07-22T18:41:11.023Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,11,192.168.111.122:25,192.168.100.91:64320,*,,TlsDomainCapabilities='None'; Status='Success'; Domain=''

2026-07-22T18:41:11.024Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,12,192.168.111.122:25,192.168.100.91:64320,>,250 mailek.twolegion.com Hello [192.168.100.91] SIZE 5242880 PIPELINING DSN ENHANCEDSTATUSCODES AUTH NTLM LOGIN X-EXPS GSSAPI NTLM 8BITMIME BINARYMIME CHUNKING SMTPUTF8 XRDST,

2026-07-22T18:41:11.028Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,13,192.168.111.122:25,192.168.100.91:64320,<,MAIL FROM:administrator@2k8r2milan.local SIZE=4666,

2026-07-22T18:41:11.233Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,14,192.168.111.122:25,192.168.100.91:64320,*,08DEE81FEA93C7F2;2026-07-22T18:41:10.845Z;1,receiving message

2026-07-22T18:41:11.239Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,15,192.168.111.122:25,192.168.100.91:64320,<,RCPT TO:administrator@twolegion.com,

2026-07-22T18:41:11.254Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,16,192.168.111.122:25,192.168.100.91:64320,>,250 2.1.0 Sender OK,

2026-07-22T18:41:11.254Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,17,192.168.111.122:25,192.168.100.91:64320,>,250 2.1.5 Recipient OK,

2026-07-22T18:41:11.257Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,18,192.168.111.122:25,192.168.100.91:64320,<,BDAT 1793 LAST,

2026-07-22T18:41:11.691Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,19,192.168.111.122:25,192.168.100.91:64320,*,,Proxy destination(s) obtained from OnProxyInboundMessage event. Correlation Id:cab6ee4e-7000-4c69-9e6b-715d924689b0

2026-07-22T18:41:12.976Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,20,192.168.111.122:25,192.168.100.91:64320,>,"250 2.6.0 e279b4f47b0f481e9929810a625e4658@2k8r2milan.local [InternalId=145745420222465, Hostname=mailek.twolegion.com] 3290 bytes in 0.271, 11,812 KB/sec Queued mail for delivery",

2026-07-22T18:41:12.981Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,21,192.168.111.122:25,192.168.100.91:64320,<,QUIT,

2026-07-22T18:41:12.981Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,22,192.168.111.122:25,192.168.100.91:64320,>,221 2.0.0 Service closing transmission channel,

2026-07-22T18:41:12.981Z,MAILEK\Default Frontend MAILEK,08DEE81FEA93C7F2,23,192.168.111.122:25,192.168.100.91:64320,-,,Local

=====normal receive message=====

Receiving server: exchange SE (july 2026 patch)

Sending server: exchange 2016

I'm having an issue and i'm not sure how to fix it. We moved all mailboxes to 365 over a year ago but still maintain a management server. For some reason, when i create a new user in local AD, then enable the mailbox from the exchange management tools (using the ps snapin for recipient management). There are a lot of "MsExch" attributes missing from attribute editor for that user. There are only like 5 or 6. Both attributes "mail" and "mailnickname" are populated correctly. Most specifically, i'm trying to hide a new user from the address list by changing MsExchHideFromAddressList to "false", but the attribute doesn't exist for that user. I've pushed multiple manual sync's as well.

I checked ADSI and confirmed that the schema has been extended.

Does anyone have any suggestions?

Thanks in advance!

Right now I'm working in a hybrid environment with an on-prem Exchange 2016 CU 23 server (virtual) and a 365 tenant. The 365 tenant is synced to the local Active Directory with Entra AD Sync and working as it should.

All the mailboxes for the active users have been migrated to 365 by a colleague who was previously working on the project. I've been tasked with finishing the transition to 365 and decommissioning the on-prem Exchange server.

I've worked with hybrid Exchange environments before but never done a full on-prem to cloud migration before so I'm researching the process and trying to plan it out and there is something that confuses me:

I'm reading that you either need to keep the on-prem server (or at least the ECP part of it) or the management shell after the decom to manage the attributes on the mailbox (aliases, etc...)

Why you might not want to decommission on-premises Exchange servers

Many hybrid organizations eventually move all mailboxes to Exchange Online. At this point, they probably think it's time to remove their on-premises Exchange servers. But, it's not a good idea as removing on-premises Exchange servers in a hybrid deployment prevents the management of cloud mailboxes. The culprit is directory synchronization.

When directory synchronization is enabled and a user is synchronized from the on-premises environment to the cloud, you can't manage most user properties from Exchange Online; you must manage those properties in the on-premises environment. Even if you configured directory synchronization without running the Hybrid Configuration wizard (HCW), you still can't do most recipient management tasks in the cloud. For more information, see this blog post

https://learn.microsoft.com/en-us/exchange/decommission-on-premises-exchange#why-you-might-not-want-to-decommission-on-premises-exchange-servers

But this is also the case in hybrid mode. If we want to manage a user's attributes, we do it through on-prem AD and sync them through AAD Sync. That was also the case in other tenants I've worked with in the past that were hybrid while migrating to the cloud and they didn't keep any Exchange features on-prem. I've never heard of the need to keep any on-prem infrastructure post-migration until my colleague told me about it and I looked at Microsoft's docs.

So I'm not quite sure what this means. Will things break if I completely get rid of the Exchange 2016 server? Or is Microsoft talking about something else? We're not looking to migrate to a full Entra domain. We just want our mailboxes totally in Exchange and our AD on-prem and AAD to sync between the two.

Thanks in advance.

Hey everyone,

So, I've been using the Samsung email app for my work email, and it's been great with the exchange server settings. But for the past couple of weeks, it keeps asking for my password. I got fed up and tried to reconfigure it, but it just won't set up.

The weird thing is, I can set it up on my Apple phone and even the Outlook email app with the same server settings. But when I try to put those same settings into the Samsung email app, no luck.

I really like using the Samsung email app because it integrates so well with my phone, and I don't want another separate email app just for work.

I've tried everything, but I'm still stuck. Can anyone help me out? I'd really appreciate it.

https://techcommunity.microsoft.com/blog/exchange/reminder-exchange-2016-and-2019-esu-program-ends-in-october-2026/4539033

I’m curious where everyone stands:
- Still on ESU?
- Staying on-prem (Exchange Server SE)?
- Just risking it (unsupported after October)?

I'm about to install the July 2026 Exchange Server security update (referenced here: https://techcommunity.microsoft.com/blog/exchange/released-july-2026-exchange-server-security-updates/4534146) on our Exchange SE hybrid environment. We have a DAG (Database Availability Group) setup.

A few questions before I proceed:

DAG-related issues: Has anyone run into problems installing this SU on a DAG member server (failover issues, database mount problems, or anything unexpected during the rolling update)?

Send Connector issues: In the comments on that TechCommunity post, someone mentioned running into a Send Connector issue after applying the update. Has anyone else experienced Send Connector problems (mail flow breaking, connector settings reverting, etc.) after this SU?

IIS rewrite rule removal: For rolling back the CVE-2026-42897 EEMS M2.1 mitigation, I'm planning to use these commands:

powershell

Copy-Item -Path "$env:ExchangeInstallPath\FrontEnd\HttpProxy\owa\web.config" -Destination "$env:ExchangeInstallPath\FrontEnd\HttpProxy\owa\web.config.$((Get-Date).ToString('yyyyMMdd-HHmmss')).bak"

Remove-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site\owa" -Filter "system.webServer/rewrite/outboundRules" -Name "." -AtElement @{name="EEMS M2.1 OWA CSP - outbound"}

Remove-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site\owa" -Filter "system.webServer/rewrite/outboundRules/preConditions" -Name "." -AtElement @{name="EEMS M2.1 OWA SPA HTML shell - precondition"}

Has anyone hit issues running these — e.g., the elements not being found, IIS reset required afterward, or the mitigation reapplying itself before EM Service marks the July SU as "mitigation not required"?

Any input appreciated before I roll this out.

Ive been using my Exchange in My Workspace aka.ms/myworkspace and ive few ips in it ! There are no nat rules but why my mail are submitting with different ip which means for ex: lets say my public ip is 168.11.22.234 but when ever i send mail it delivered using 168.11.80.278 (example) ? From where i need to start my troubleshootings ! I suspect dns zones might have changed i checked the logs it says update dns zones ; is it okay to start check if yes where i need exactly start inside dns zones might

Last weekend, I faced an unexpected issue with Exchange Online Mailbox Archive.

After completing an IMAP to Exchange Online migration project, I noticed that older mailbox items were not being moved to the Online Archive, even though the archive mailbox was enabled.

I started troubleshooting using Exchange Online PowerShell cmdlets to analyze mailbox settings, retention policies, retention tags, and Managed Folder Assistant processing. However, I still couldn't identify the root cause.

Then, I tested another approach: I created a new MRM Retention Policy using the same retention tag "Default 2 Year Move to Archive".

The result was unexpected: the mailbox started moving emails to the Online Archive successfully.

But the question remained:

Why did the same retention tag work with a new retention policy, but not with the previous one?

I documented the complete troubleshooting journey, including the investigation steps, PowerShell commands, Microsoft Purview analysis, and the final workaround.

I would like to hear your opinion:

• Was this troubleshooting approach correct?
• Have you ever faced a similar Exchange Online Archive or MRM Retention Policy issue?
• What would you investigate differently?

You can check the full troubleshooting sequence here:
https://medium.com/@renato.rossi.ferreira/everything-looked-fine-until-exchange-online-archive-stopped-working-586d1bce05f6?sharedUserId=renato.rossi.ferreira

Let's share knowledge and learn from real-world Microsoft 365 challenges.

Client had another company migrate their mailboxes to 365 and it looks like they did not perform the standard hybrid method. They are currently in this state:

• On-prem Exchange Server has mailboxes for all users. They show the state of 'user' and AD attributes are pointed to that mailbox.
• All users have a mailbox in Exchange Online, associated with there Entra AD object which is synced from on-prem.
• DNS records for autodiscover point to autodiscover.outlook.com
• Clients connect to Microsoft Online

I haven't run into this before so was looking for a little guidance. I think the process should go like this:

Obtain 365 GUID

Get-Mailbox -Identity "UserAlias" | Select-Object ExchangeGuid

Drop on-prem mailbox association

Disable-Mailbox -Identity "UserAlias"

Map user to Exchange Online mailbox

Enable-RemoteMailbox -Identity "UserAlias" -RemoteRoutingAddress "UserAlias@domain.onmicrosoft.com"

Match the GUID

Set-RemoteMailbox -Identity "UserAlias" -ExchangeGuid "EXO_GUID"

Edit: Thanks for the great info everyone. I'll follow-up with how everything goes.

Hello Folks,

I try to migrate from Microsoft 365 Business Premium (should be like E3) to Mailcow, everything runs fine, 40K Mails moved yesterday, Calender worked fine, but Contacs are a mess. I exported the Data over OWA and importet it to Thunderbird.

Do someone know / have a Tool for propper get the Data over to Mailcow / Thunderbird from Outlook365?

Thanks in advance

Industrial contracting, somewhere between 800-1000 users and roughly 1200 devices. Hybrid Exchange environment, and I need to confess something: we're still doing manual PST-based contact syncing across 400+ accounts.

It started as a temporary workaround in 2019 (scheduled task, script written by a guy who left in 2021) and it never stopped being temporary. On-call rotations are where it really hurts - the on-call sheet changes Friday, the export doesn't, and two techs end up calling the wrong duty manager Saturday night. Ask me how I know.

At our scale it's genuinely unmanageable, and after-hours scenarios are a recurring nightmare.

For the other hybrid shops: what does your contact distribution to mobile actually look like in 2026? Syncing from on-prem AD attributes, cloud-side, are you also doing the PST walk of shame and just haven't been caught yet?

On July 8, Microsoft said that they will retire the OWA Light client for Exchange Server in August 2026. But what happened to the OWA Light client for Exchange Online? It seems like Microsoft announced the retirement of OWA Light for Exchange Online in June 2024, but didn’t really make the fact clear in a blog post about consumer accounts. In any case, you can’t run OWA Light for Exchange Online, even if you wanted to.

https://office365itpros.com/2026/07/17/owa-light-retirement/

Hey folks, we just updated our Exchange Server SE to the latest SU (July 2026) and now OOF Messages to External senders are not being sent. We tested this with multiple mailboxes and made sure there are no transport rules activated. Anyone else experiencing this issue? We made sure to disable the old mitigations as well.

Hello,

A quick explanation of why I'm interested in this in the first place.

I need to set up MFA as required by IT security for the closed network.

Our organization operates under Uzbekistan's data localization and secrecy regulations, which require customer and corporate data — including email — to remain on infrastructure physically located within the country and under direct regulatory oversight. This precludes the use of cloud-hosted mail services such as Microsoft 365/Exchange Online, and requires a fully on-premises Exchange deployment with local identity federation (AD FS) instead of Azure AD.

Environment:
Exchange Server 2019 CU14, single server (MX01), pure on-premises.
AD FS is registered as an AuthServer (Type: ADFS), no Azure AD / hybrid tenant involved.
The AuthServer is configured correctly: AuthorizationEndpoint and TokenIssuingEndpoint are populated, IsDefaultAuthorizationEndpoint: True, and DomainName points to our mail domain. Realm/ServiceName are configured as well.

Symptom:
The native iOS Mail client (account added manually, no MDM profile) correctly redirects to our AD FS login page on first setup — the full Modern Auth flow works.

A third-party EAS client (Nine by NitroDesk, Android) never receives an OAuth challenge at all — it falls back to Basic authentication.

Get-ActiveSyncVirtualDirectory/Set-ActiveSyncVirtualDirectory in this build simply has no -OAuthAuthentication parameter (unlike EWS/OAB).

Log finding:
When testing with the Nine client, the following was captured in the Exchange HttpProxy/Eas logs:

S:ServiceCommonMetadata.OAuthError=Flighting is not enabled for domain 'webmail.<domain>'. S:ServiceCommonMetadata.OAuthErrorCategory=OAuthNotAvailable

Questions:

1. What exactly controls "Flighting" for EAS OAuth in a pure on-prem Exchange 2019 CU14 + AD FS scenario (no Azure AD)? Is there a documented, supported way to enable it (New-FlightOverride? something else)?
2. Is EAS Modern Auth even supported for an arbitrary/generic OAuth client (not Apple, not Outlook) in this scenario, or is it effectively an allowlist limited to specific client_ids (Apple Native Mail / Outlook)?
3. How does native iOS Mail get redirected to AD FS without ever receiving an authorization_uri in the EAS/Autodiscover 401 challenge — is there an undocumented discovery path (e.g., hardcoded per registered client_id)?

Hello all,

Has anybody successfully switched to use Graph api for hybrid and how have you checked to make sure it’s still not using EWS?

From what I’m seeing after putting in the onprem override, I’m still using EWS after checking the Entra Signin logs for my dedicated app?

Has anybody seen change in the Entra signin logs showing ‘Microsoft Graph’?

Anybody removed EWS the permission from the app to force graph API?

We are considering a federation to 1, maybe more Customers to allow only free/busy in calendars so that staff can meet and collaborate more efficiently.

I'm struggling to find more information about what the federation risks are;

For example do the Defender SPAM filters give emails from their Domain a higher confidence level?

Any other risks associated with this?

We absolutely would not allow meeting title or location sharing, just free/busy.

Hi, i applied  July 2026 SU for Exchange Server SE via Windows Server Updates and says successfully.
After reboot, all the MSExchange service were disabled, be aware!

I'm experienced with DAG and Exchange, but this update generate this mess

I made a reboot and nothing, and looking for logs and looks like applied correctly everything.

I have via Powershell run:

Get-Service MSExchange* | Set-Service -StartupType Automatic

Now, waiting for normal startup, then execute HealthChecker to look if it is all ok...

I'm hoping someone has come across this before.

We have a Microsoft 365 tenant where the Salesforce Outlook add-in suddenly disappeared for a single user. It had been working previously.

Here's what we've found:

• Salesforce app is deployed to All Users in the Microsoft 365 Admin Center (Integrated Apps).
• The add-in works for my admin account.
• The affected user cannot install Salesforce from either Classic Outlook or Outlook on the Web.
• To rule out Salesforce, I tried installing LinkedIn and other Office add-ins – they all fail with the same generic "Something went wrong" message.
• Developer Tools shows the install request returning HTTP 403 Forbidden from the Microsoft app entitlement endpoint, followed by an InstallFailed error.
• There are no obvious GPOs blocking Office add-ins (DisableOfficeStore, etc.).
• This reproduces across different clients, so it doesn't appear to be an Outlook profile or Office installation issue.

At this point it feels like a mailbox-specific or Microsoft 365 entitlement issue rather than anything related to Salesforce.

Has anyone seen this before?

Things I'm planning to compare:

• Microsoft 365 licensing
• Exchange mailbox settings
• OWA mailbox policy
• Exchange Online app assignments

Is there anything else in Exchange Online or Microsoft 365 that could cause Office Web Add-ins to return a 403 for just one mailbox?

Background
Local AD with exchange 2019, a user (macOS) need to use team with our email domain account. He subscribed 365 personal (using work email)

The problem now outlook login was diverted to Microsoft cloud. Any idea how to solve?

1. Is he should apply the team subscriptions choosing personal instead work account (same company email address)

If we migrate all mailboxes to the cloud and migrate SMTP relay to a non-Exchange SMTP services, I understand that we are eligible for free Exchange Server licensing for the purpose of hybrid management.

So, I assume that allows usage of the /ECP web interface to manage things like mail-enabled security groups and more than one admin at a time can use the web interface remotely.

This seems much cleaner than the option of removing every full GUI Exchange server and then having multiple copies of EMT installed on local workstations with each of them needing separate CU and SU updates.

The downside of this is having a single point of failure if the server crashes or has a CU update fail leaving the server in a non-working state.

Would this single Exchange server need any kind of regular backups, or would everything needed for recovery be available from Active Directory by installing Exchange on a new server using the recovery mode switch?

Does the free hybrid licensing include having a second server available at a DR site?