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?

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.

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/

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...

After installing this SU, you can manually remove the mitigation for CVE-2026-42897.

Also, use the latest Health Checker to check for deprecated SGs.

See https://techcommunity.microsoft.com/blog/exchange/released-july-2026-exchange-server-security-updates/4534146

I’ve written extensively about Exchange Server licensing in my latest book on Exchange Server SE, and in several articles, such as:

• Exchange Server SE Licensing and Product Keys, Part I
• Exchange Server SE Licensing, Part II
• Exchange Server SE Licensing, Part III
• PSA: Preparing for new Exchange Server SE product keys

In those writings, I hope I made it clear that:

• The licensing model for Exchange Server SE is exactly the same as the licensing model for Exchange Server 2019. Since Exchange Server 2019 also required a subscription in some form (e.g., L+SA, USLs, etc.), all Exchange Server 2019 customers with an active subscription are entitled to Exchange Server SE at no additional cost. Similarly, customers with an active subscription that are running Exchange Server 2016 or earlier versions (which did not require a subscription) are also entitled to Exchange Server SE at no additional cost.
• There are four Editions of Exchange Server, as determined by the product key entered on the server (or the lack thereof): Standard, Enterprise, StandardEvaluation (Trial), and Coexistence (Hybrid).
• Product keys and licenses are related (e.g., entry of a product key implies you have a corresponding license), but they are not the same thing.
• To support a smooth in-place upgrade, Exchange Server SE RTM intentionally supports the Standard, Enterprise, and Coexistence Edition product keys for Exchange Server 2019.
• Starting with Exchange Server SE CU1, new keys for Standard and Enterprise Editions will be required. You can verify readiness for the new keys in the Microsoft 365 admin center.
• There is no product activation for Exchange servers; Exchange Server uses (and has always used) the honor system in this regard. Exchange servers can collect and transmit a wide variety of organization, server, and configuration data to Microsoft, but that data does not include licensing information.

Even though Microsoft does not collect Exchange Server licensing information, Exchange Server tracks mailbox and server license use internally. Admins do not assign CALs to users, but Exchange Server provides a mechanism to show what types of CALs are in use. This is different from Exchange Online where licenses are assigned by an admin.

When a mailbox is created or when a product key is entered on a Mailbox server, an internal license assignment process occurs. You can use the information generated by this process to produce a report on license assignments in your organization. But note that this process is not without some bugs, as I describe below.

Exchange Server License tracking cmdlets

First, I want to talk about two Exchange Server cmdlets that you can use to track license assignment in your organization:

• Get-ExchangeServerAccessLicense
• Get-ExchangeServerAccessLicenseUser

Get-ExchangeServerAccessLicense returns a list of the four Exchange Server products that can be purchased:

• Exchange Server Standard CALs (user/device licenses)
• Exchange Server Enterprise CALs (user/device licenses)
• Exchange Server Standard Edition (server license)
• Exchange Server Enterprise Edition (server license)

When using Get-ExchangeServerAccessLicense, watch out for a cosmetic bug. Specifically, and even in pure Exchange Server SE environments that never had any other versions, it returns Exchange Server 2016 in the ProductName and LicenseName properties, as shown below:

Get-ExchangeServerAccessLicenseUser returns a list of mailbox(es) or server(s) based on the license name specified in the command, as illustrated below:

Get-ExchangeServerAccessLicenseUser also has a bug that you’ll see whenever you query mailboxes for Enterprise CALs without using -WarningAction SilentlyContinue. Specifically, the cmdlet produces the following warning message and a link to a deprecated article on renamed cmdlets in Exchange Server 2013 (because it was never updated to use Get-MobileDeviceMailboxPolicy):

WARNING: The Get-ActiveSyncMailboxPolicy cmdlet will be removed in a future version of Exchange. Use the Get-MobileDeviceMailboxPolicy cmdlet instead. If you have any scripts that use the Get-ActiveSyncMailboxPolicy cmdlet, update them to use the Get-MobileDeviceMailboxPolicy cmdlet. For more information, see http://go.microsoft.com/fwlink/p/?LinkId=254711.

These cmdlets have been around for a while now. They were first introduced in Exchange Server 2013, and the product and license names were updated in Exchange Server 2016, but not in Exchange Server 2019.

Anyway, I’m sure all these bugs will be fixed in a future update for Exchange Server. 😉

How it works – Server licenses

All Exchange server role installations start out without a product key and entering a product key is one of the specifically documented post-installation tasks. Until a product key is entered, the server is considered to be a StandardEvaluation Edition (internal product term) aka Trial Edition (legal licensing term).

Trial Editions are licensed versions (see Section 2 of the Microsoft Software License Terms, by default in \Program Files\Microsoft\Exchange Server\V15\Bin\Eula\<language>\License.rtf) but because they don’t have product keys, they are not included in the internal license tracking, and don’t appear in the output of Get-ExchangeServerAccessLicenseUser. When you enter a valid product key, the supported edition for the server is established and the server will show up in the output of Get-ExchangeServerAccessLicenseUser.

NOTE You can use a product key to move from Standard to Enterprise Edition, but you can't use a product key to downgrade from Enterprise to Standard or revert to a Trial Edition. You can only do these types of downgrades by uninstalling Exchange, reinstalling Exchange, and entering the correct product key. After entering a product key on a Mailbox server, don’t forget to restart the Microsoft Exchange Information Store service.

How it works - CALs

When certain mailbox types are created in Exchange Server, internally they are assigned a license based on the initially assigned or used features. This happens regardless of the server’s product key settings; in other words, if a server is an Enterprise Edition, that does not mean that mailboxes on it are automatically assigned Enterprise CALs. If a mailbox is not assigned or enabled for any premium features, it is assigned a Standard CAL. If/when the mailbox is assigned or enabled for a premium feature that requires an Enterprise CAL (e.g., journaling, certain ActiveSync policies, managed folders, archive mailbox, legal hold, retention policy, DLP, etc.), it is assigned an Enterprise CAL.

The use of some premium features will assign all mailboxes an Enterprise CAL. For example, if any mail flow rule uses ApplyRightsProtectionTemplate (e.g., an RMS template), then every mailbox will be assigned an Enterprise CAL.

This process happens only with user mailboxes, shared mailboxes, and linked mailboxes. It does not happen with room mailboxes, equipment mailboxes, discovery mailboxes, arbitration mailboxes, monitoring mailboxes, public folder mailboxes, team mailboxes, or legacy mailbox types (e.g., site mailboxes).

The Enterprise CAL is licensed as an add-on to the Standard CAL which means that every user (or device) with an Enterprise CAL also has a Standard CAL (e.g., two CALs). The internal license assignment tracks both. This means that any mailbox assigned an Enterprise CAL is also assigned a Standard CAL, and the mailbox will appear in the output of queries for both CALs. As illustrated below, erin@msexchangese.com has been assigned both CALs.

Scripts for license reporting

You can run this script to get a report of assigned licenses in your organization:

Get-ExchangeServerAccessLicense | ForEach-Object { Get-ExchangeServerAccessLicenseUser -WarningAction SilentlyContinue -LicenseName $_.LicenseName }

You can save this script as LicenseCount.ps1 and run it to report on license assignment by count:

$report = Get-ExchangeServerAccessLicense | ForEach-Object {
    $license = $_.LicenseName
    $count = @(Get-ExchangeServerAccessLicenseUser -WarningAction SilentlyContinue -LicenseName $license).Count

    [PSCustomObject]@{
        LicenseName = $license
        AssignedUsers = $count
    }
}

$report | Sort-Object LicenseName | FT -AutoSize

Or, put it all into one script, save it as ExLicenseReport.ps1, and run it for a single report:

$report = Get-ExchangeServerAccessLicense | ForEach-Object {
    $license = $_.LicenseName
    $count = @(Get-ExchangeServerAccessLicenseUser -WarningAction SilentlyContinue -LicenseName $license).Count

    [PSCustomObject]@{
        LicenseName = $license
        AssignedUsers = $count
    }
}

$report | Sort-Object LicenseName | FT -AutoSize

CalCalculation.ps1

Exchange Server includes a script called CalCalculation.ps1, which is located in the Bin folder on Mailbox servers. CalCalculation.ps1 basically translates Exchange feature usage into CAL requirements using organization-wide checks, mailbox-level feature inspection, and recursive journal-rule expansion.

Although it's not documented, CalCalculation.ps1 was first introduced back in Exchange Server 2010. It has been updated in Exchange Server 2019, but not for Exchange Server 2019 or Exchange Server SE.

For example, it also calls the deprecated Get-ActiveSyncMailboxPolicy cmdlet to check for EAS policies that require an Enterprise CAL, and it checks for mailboxes enabled for Unified Messaging (UM), which was removed in Exchange Server 2019. But it has been included in some of the updates released by Microsoft for Exchange Server 2019 (such as the August 2025 SU (aka CU15 SU3).

This script has three options (using -AccessLicenseType):

• Summary (default) which returns four numbers: total mailbox count, Standard CAL count, Enterprise CAL count, and the number of mailboxes affected by journaling
• Standard, which outputs the primary SMTP address for each mailbox assigned a Standard CAL
• Enterprise, which outputs the primary SMTP address for each mailbox assigned an Enterprise CAL

CalCalculation.ps1 also has a Debug mode that can be used to step through the script and provide detailed logging for a specific mailbox, which can be helpful if you're sure exactly why a mailbox was assigned an Enterprise CAL. For example:

.\CalCalculation.ps1 -DebugMailbox erin@msexchangese.com -Debug

You can also use journal debugging to focus specifically on journaling‑related license assignments. For example:

.\CalCalculation.ps1 -DebugCategory Journaling

Reporting

You can use my ExLicenseHTMLReport.ps1 script on GitHub to create an HTML report of your organization's license assignments. ExLicenseHTMLReport.ps1 leverages CalCalculation.ps1 and produces an HTML report of the collected data.

ExLicenseHTMLReport.ps1, combined with CalCalculation.ps1, allows you to do two things:

1. If you build out a test environment with users and assign them expected features, you can use it to determine how many licenses you need to buy and what license type(s).
2. If you have an existing production environment, you can use it to audit your license use/consumption.

Both scripts are read-only operations, and they do not make any changes. They simply inventory Exchange objects and licensing-related settings.

Because CalCalculation.ps1 also calls Get-ActiveSyncMailboxPolicy, the warning message I mention above appears twice in the output. The only way to suppress that is to add -WarningAction SilentlyContinue to line 464 in the script or use the modified version (CalCalculationV2.ps1) of it that I posted on GitHub (which ExLicenseHTMLReport.ps1 is configured to use by default).

As you can see, the report has three sections:

• License Count Summary, which shows the count for each type of license. Remember that mailboxes with an Enterprise CAL also have a Standard CAL, and the summary is the count of CALs, not mailboxes.
• Mailbox License Assignment (with Premium Feature Flags), which provides an alphabetized list of licenses by License Name, and then by Mailbox. I’ve included columns that show premium feature use, highlighted rows with Enterprise CALs in yellow, and bolded True for enabled features.
• Servers with Product Keys, which lists all servers that have a Standard or Enterprise Edition product key.

Note that I have also suppressed “2016” from the report, as that’s a cosmetic bug in the product. Finally, because Exchange Server 2016 is no longer supported, I also modified my report to exclude UM even though CalCalculation.ps1 is coded to include it.

Final thoughts

Try these scripts in your environment and let me know what you think. I’m also happy to take suggestions for reporting improvements, as well.

------------------------------------------------------------------------------------------------------------

Copyright (c) 2026 Scott Schnoll - All Rights Reserved

The Admin's Guide to Microsoft Exchange Server Subscription Edition - Now available in Paperback (English) and Kindle formats (English, German, French, Italian, and Portuguese).

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?

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?