Exchange Team Blog articles

Exchange Online EWS application stopped working? Do this.

The_Exchange_Team — Wed, 21 Oct 2026 17:42:20 GMT

As we have been announcing, Exchange Web Services (EWS) protocol is being turned off in Exchange Online. This protocol is used by various applications such as:

Apple Mail / Calendar on macOS
Classic Outlook on macOS
Different Outlook desktop add-ins
Outdated versions of Outlook Desktop on Windows
Various other applications such as backup applications that our customers purchase from various software vendors

Such applications might give you various errors when EWS is turned off, from repeatedly asking for username or password, to giving you a clear error that EWS protocol is not available.

Retirement of this protocol is now in progress, you can see our progress in this post.

If your EWS applications stopped working, do this

Please note that Microsoft support cannot perform these steps for you. Only the tenant administrator can follow these steps and re-enable EWS.

Check your tenant Message Center posts. Use the Search field to look for a post with a subject of “Action may be required: EWS will be disabled in your tenant in 7 days” or “EWS has been disabled in your tenant”. This will tell you when EWS was turned off in your tenant.

If you do find a post saying that Microsoft turned off EWS in your tenant, you have two options:

Option 1 (easiest): Use Microsoft 365 admin center Baseline Security Mode

Go to the Microsoft 365 admin center, Baseline security mode page: https://admin.cloud.microsoft/#/baselinesecuritymode
Find the “Block access to Exchange Web Services” line and click on it:

Uncheck (de-select) the “Block your entire organization from using EWS” checkbox (1) and then press the “Apply change” (2) button:

Now check (select) the same “Block your entire organization from using EWS” checkbox (3) and then again press the “Apply change” (4) button:

You have now re-enabled EWS in your tenant. The setting change usually takes less than an hour to start working (and your EWS applications will just start working again). But note that this can take up to 4 hours in rare cases.

It might be a bit confusing that while you have checked / selected the “Block” setting, the underlying setting on your tenant is now actually set to allow EWS (EWSEnabled = True) with a specific app(s) in the EWS allow list.

To learn which EWS applications are in the allow list to use EWS in your tenant, see the Scope Summary section (5). Apps that are listed / excluded are the ones that are excluded from being blocked.

Option 2 (more control): Use Exchange Online PowerShell

Install Exchange Online PowerShell module and then, connect to Exchange Online PowerShell.
Paste the following command into your connected PowerShell window:

Get-OrganizationConfig | Fl EWSEnabled

If the answer is “EwsEnabled : False” then EWS is disabled – this is your problem
Paste the following command into the PowerShell window:

Set-OrganizationConfig -EWSEnabled $true

You have now re-enabled EWS in your tenant. The setting usually takes less than an hour to start working (and your EWS applications will just start working again). But note that this can take up to 4 hours in rare cases to start working.

Finding out which EWS applications are allowed in your tenant

Using the Baseline security mode: see the Scope Summary as shown in the above screenshot and use Exclude specific apps to modify the list.

Using the Exchange Online PowerShell: paste the following command into the Exchange Online PowerShell window:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Fl EwsAllowedAppIDs

This will result in a list of EWS applications that Microsoft has detected were in use within last 60 days in your tenant. We already added them to “EwsAllowedAppIDs” – which is an “allow list” for EWS applications. You do not need to modify this list if everything is working properly once you re-enabled EWS by using previous steps. You can add additional apps to this list. Read more here.

Modifications to applications in the allow list take 24 hours to take effect.

The steps above will work only temporarily (until April 2027)

We are now in the first stage of EWS disablement, where customers are still able to re-enable EWS. Re-enabling EWS will stop working in April 2027.

The long-term solution is to update your applications to the application versions that do not use EWS. You must contact your application vendor to get the updated application version, or if you created the application yourself, you must change the code to not use EWS anymore. EWS will not be an option that your client applications can use after April 2027.

The EWS Deprecation Team

The Change Optics Report is now Generally Available in Exchange Online

The_Exchange_Team — Mon, 19 Oct 2026 14:24:57 GMT

Change management is an important part of how we improve Exchange Online. Some changes to the service can affect existing mail flow, and the key to minimizing disruption is giving administrators the visibility they need to identify affected traffic and take action before those changes arrive.

Earlier this year, we released the Change Optics Report into Public Preview (Change Optics Report released into Public Preview to showcase messages impacted by future changes | Microsoft Community Hub). Today, we're pleased to announce that the Change Optics Report is now generally available for Exchange Online worldwide tenants.

Thank you to everyone who tried the report during Public Preview and provided feedback. That feedback helped us improve the experience before General Availability (GA).

What is the Change Optics Report?

When we announce changes that could affect the sending or delivery of certain messages, the Change Optics Report provides a central place for administrators to identify potentially affected traffic.

The report displays a sample set of messages from your organization that match the characteristics expected to be affected by a particular change. Administrators can use these samples to begin an investigation, determine where remediation might be required, and monitor progress as affected traffic is reduced ahead of the change.

Scenarios available at GA

The Change Optics Report currently includes two scenarios:

Onmicrosoft.com external traffic (OMC)

This scenario identifies messages being sent externally using onmicrosoft.com addresses. Throttling of this traffic has now rolled out, so organizations that continue to see this usage should investigate and move appropriate sending scenarios to a custom domain.

For more information, see Limiting Onmicrosoft Domain Usage for Sending Emails.

Direct Send traffic (DRS)

This scenario identifies Direct Send messages received by your tenant. Organizations planning to use the Reject Direct Send setting can use the report to identify legitimate Direct Send traffic and ensure those senders are appropriately handled before enabling the setting.

For more information, see Introducing more control over Direct Send in Exchange Online.

As additional Exchange Online changes are introduced, we plan to add scenarios to the Change Optics Report where additional visibility can help administrators prepare.

What's changed since Public Preview?

Customer feedback during Public Preview helped us improve the report before GA including clearer report and scenario descriptions, filtering noisy message types like journaling reports, and displaying the P1 envelope sender address used for onmicrosoft.com enforcement.

Using the Change Optics Report

You can find the report in the Exchange admin center under:

Reports > Mail flow > Change Optics Report

The report contains two main pages:

Summary

The Summary page displays message-volume trends for the scenarios being tracked. This makes it possible to monitor potentially affected traffic and see whether remediation is reducing that traffic over time.

Details

The Details page displays example messages for the selected scenario and provides the main message properties needed to begin an investigation. The table can be exported, and Message Trace can be used when additional information about an individual message is required.

The Export function currently exports data loaded into the table rather than all data for the selected time range. We have plans to enhance the Export functionality but not ETA to report yet.

Remember that Change Optics provides samples of affected messages. It should be used to identify sending patterns and scenarios requiring investigation rather than as an exhaustive message trace.

Availability

The Change Optics Report is generally available to Exchange Online tenants in the worldwide environment.

It is not currently available in GCC, GCC High, DoD, or other sovereign cloud environments.

We will continue expanding the Change Optics framework as new scenarios arise where giving administrators early visibility can help reduce the impact of future service changes.

As always, let us know what you think in the comments below.

The Exchange Online Messaging Team

Exchange servers may become unstable after installation of October 2026 Windows updates

The_Exchange_Team — Tue, 20 Oct 2026 19:11:22 GMT

Update October 20, 2026: Added a FAQ to this post.

Since October 13, 2026 (Microsoft “Patch Tuesday” release cycle), we have seen some reports of customer issues where Exchange Servers become unstable after a set of October updates are installed.

Symptoms that can be seen are various, but here are some:

Exchange Server OWA may fail with an error MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142) with event ID 1006 logged in the Application Log.
Exchange email queues might grow during the day, with email crawling to a halt.
Various issues related to DAG members not being able to reach quorum have been reported too.
Exchange server reboot might resolve the issues temporarily.
Exchange Server 2016, 2019 or Subscription Edition (SE) might be impacted.

What is happening and how to address it

Issues reported are not related to installation of October 2026 security updates for Exchange Server. This is not a “known issue” related to October 2026 Exchange update. Any version of Exchange that runs on impacted versions of Windows could be impacted.

The following Windows Server updates can cause above mentioned Exchange Server failures after certain time:

KB5126646 (Windows Server 2025)
KB5126655 (Windows Server 2022)
KB5126651 (Windows Server 2019)
KB5126868 (Windows Server 2016)

Not all Exchange servers will be impacted by installation of those updates equally; the severity and speed of impact varies based on Exchange server load. Some servers might never see a problem.

Our recommendation

Do not uninstall October 2026 Windows Server updates.
From an elevated Command Prompt on an Exchange Server, run:

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Reboot the server.
After the reboot, monitor the environment and confirm whether the issue recurs. If it re-occurs, raise the limit (we have so far not seen any cases where this might be needed). This has been shown to solve the problem based on customer reported cases that we have assisted to date.

More information can be found in Users might be unable to sign in to OWA or send emails on Exchange Server (Windows Server known issues and notifications).

FAQs

Should we wait for updated set of Windows updates or wait for next month’s Windows updates release? Should we uninstall Windows Server updates?
No, you should install already released Windows updates as soon as possible. October 2026 updates for Windows Server carry a significant security payload and installation of those updates should not be delayed for the sake of a single issue with Exchange server interoperability. Follow the recommendation in this blog post.

Can the mentioned Windows registry setting be created before we install October 2026 Windows Server updates on our Exchange servers?
Yes. Creating the registry key beforehand has no impact on Windows Server because the registry key is read and used only once October 2026 Windows Server updates are installed. The registry key remains intact during update installation.

Is there another fix coming? From Exchange? From Windows? When? Should we wait for it?
There is no imminent follow-up release from either Windows or Exchange. Both teams are still analyzing this long-term. Future improvements in the area are possible. You should not wait for a new release; please install October 2026 Windows Server updates and follow Exchange server recommendation in this post.

Major updates to this post:

October 20, 2026: Added a FAQ section. Added a note that raising the limit from "65536" is not something that we have seen as required yet.

The Exchange Team

Released: October 2026 Exchange Server Security Updates

The_Exchange_Team — Sat, 17 Oct 2026 01:07:04 GMT

Update October 16, 2026: For more information related to installation of October 2026 updates for Windows Server and the possible impact on Exchange Server, please see Exchange servers may become unstable after installation of October 2026 Windows updates | Microsoft Community Hub.

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

Exchange Server Subscription Edition (SE)
Exchange Server 2019
Exchange Server 2016

SUs are available for the following specific versions of Exchange Server:

Exchange SE RTM
Exchange Server 2019 CU14 and CU15 (to access, organization must be enrolled into the Period 2 ESU program)
Exchange Server 2016 CU23 (to access, organization must be enrolled into the Period 2 ESU program)

The October 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes.

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed by these SUs and do not need to take any action other than updating any Exchange servers or Exchange Management tools workstations in their environment.

More details about specific CVEs can be found in the Security Update Guide (filter on ‘Server Software’ under Product Family for Exchange SE and ‘ESU’ under Product Family for Exchange 2016 and 2019).

Exchange 2016 and 2019 Period 2 ESU program ends

Exchange Server 2016 and 2019 are out of support for a full year now. October 2026 is the last month when customers who enrolled in the Period 2 Extended Security Update (ESU) program are eligible to receive newly released Exchange Server 2016 and 2019 security updates.

After October 2026:

Updates will be released for Exchange Subscription Edition (SE) only.
Our update announcements and any CVEs released by MSRC will stop mentioning Exchange 2016 and 2019. This does not mean that those versions are not vulnerable to future security issues. We will stop testing Exchange 2016 and 2019 for vulnerabilities.
For a limited time, the ability to purchase Period 2 ESU will remain in effect, but that will only get you current with security updates through this October 2026 release.

Please continue upgrading your organizations to Exchange SE.

Issues resolved in this release

Update installation

The following update paths are available:

Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
After setup is completed, please reboot the server and check that all Exchange services have started properly. If some services are in a disabled state, that indicates that something interrupted installation of the update. Please see the Workaround 1 in this article.
If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates. Also please see File version error when you try to install Exchange Server updates.

FAQs

Our organization is in Hybrid mode with Exchange Online. Do we need to do anything?
Exchange Online is already protected, but this SU needs to be installed on your Exchange servers, even if they are used only for management purposes. If you change the auth certificate after installing an SU, you should re-run the Hybrid Configuration Wizard.

The last SU/HU we installed is a few months old. Do we need to install all SUs in order to install the latest one?
SUs are cumulative. If you are running a CU supported by the SU, you do not need to install all SUs or HUs in sequential order; simply install the latest SU. Please see this blog post for more information.

Do we need to install SUs on all Exchange Servers within our organization? What about ‘Management Tools only’ machines?
Our recommendation is to install SUs on all Exchange Servers and all servers and workstations running the Exchange Management Tools to ensure compatibility between management tools clients and servers. If you are trying to update the Exchange Management Tools in the environment with no running Exchange servers, please see this.

We installed an Exchange SU or HU update and are running Windows Server 2025. How do we uninstall updates as they are not listed on Windows Server 2025?
We do not recommend uninstalling Security Updates. But see Can't view or uninstall Exchange security or hotfix updates in Control Panel on Windows Server 2025 | Microsoft Support.

Our organization does not have the Exchange 2016 and 2019 Period 2 ESU. How can we get current Exchange 2016 or 2019 updates?
Since Exchange 2016 and 2019 are now out of support, only customers who have enrolled into the Period 2 ESU program (which is valid between May and October 2026) can obtain Exchange 2016 or 2019 updates released after May 2026. For all other customers still running Exchange 2016 or 2019, we recommend that you upgrade your organization to Exchange SE as soon as possible.

Documentation may not be fully available at the time this post is published.

Updates to this blog post:

October 16, 2026: Updated the banner to link to a post discussing steps you can take if your Exchange servers were impacted by this: Exchange servers may become unstable after installation of October 2026 Windows updates | Microsoft Community Hub.
October 15, 2026: Added a banner mentioning that October 2026 Windows Server updates migth create issues on Exchange Servers (no installation of October 2026 Exchange SU updates is required).

This post might receive future updates; they will be listed here (if available).

The Exchange Server Team

Sending From Email Aliases – General Availability

The_Exchange_Team — Thu, 08 Oct 2026 20:41:04 GMT

Today we are announcing the General Availability (GA) of Sending from Aliases for Exchange Online. This was a highly requested feature that now empowers users to send emails from any alias (proxy address) associated with their mailbox, not just their primary SMTP address. Read on to learn how it works, how to enable it, and what’s next.

What Is Sending From Aliases?

Sending from Aliases allows Exchange Online users to send emails using any of their configured aliases or proxy (or secondary) SMTP addresses. Previously, aliases could only receive mail, and all outgoing messages used the primary SMTP address of the mailbox. Workarounds like shared mailboxes or distribution groups were used in the absence of native alias sending support.

With the Sending From Aliases feature, which until now has been in Public Preview, users can:

Send from any alias directly using Outlook clients.
Reply from aliases when an email was addressed to it.
Select which aliases to display in supported clients.

How Does It Work?

Admin Setup

Enable at the tenant level via PowerShell:

Set-OrganizationConfig -SendFromAliasEnabled $True

Or use the Exchange Admin Center:

Go to Settings → Mail Flow → Turn On Sending from Aliases.

Aliases for users are managed in the M365 Admin Center.
Admin who wishes to block a domain from being able to send can set the domain as Receive Only in the M365 Admin Center.

It might take up to 60 minutes for this change to take effect in your tenant.

User Experience

Outlook on the Web	Go to Settings → Compose to view and select aliases
Outlook Desktop (Windows/Mac)	Use the From field dropdown or enter the alias manually
Outlook Mobile	Tap the From field to select from available aliases

Replies automatically use the alias the message was sent to.

Aliases are given to users for various reasons. If, for whatever reason, a user should not receive or send messages using a given alias, it is possible to set the entire domain to Send-only or Receive-only. To set a domain to Send-only or Receive-only, use the SendingFromDomainDisabled or SendingToDomainDisabled parameter of Set-Accepteddomain cmdlet from Exchange Online Powershell.

More nuanced restrictions would need to be implemented with mail flow rules or organizational policies that users should follow.

Known Gaps or Behavior Changes

There are certain features that rely on the email address used to send or receive messages. Rules set up that do not account for aliases such as journaling or routing rules, may not work as expected. Other features may work with the mailbox identity and be unable to differentiate between aliases used.

This feature is for Exchange Online-hosted mailboxes only. Messages to and from on-premises can be subject to rewriting the aliases on those servers.
In Hybrid scenarios, when email is sent from on-premises to Exchange Online, email is sent to user’s mail.contoso.onmicrosoft.com address. With send-as-alias feature enabled, this address is preserved and not resolved to user’s primary address. This can cause issues like OOF response coming from user’s mail.contoso.onmicrosoft.com address instead of the email address representing user’s actual email domain name (contoso.com). Please raise a DCR with the Outlook team if your organization would like autoreply messages to avoid using mail.contoso.onmicrosoft.com addresses.
For shared mailbox, send from alias feature works only with OWA when delegate opens it using “Open another mailbox” option. For Outlook client, send from alias feature is not supported for shared mailbox at all.
Various types of rules in Exchange Online may look for specific email addresses and not match aliases, resulting in the rule not acting on a subset of messages from a given mailbox. Features with rules include hygiene, journaling, and mail flow rules.
Message Trace queries using a primary SMTP address return results that do not include messages sent using an alias. To trace messages sent to or from an alias, you need to use the alias in your query. This is less of a known issue and more about highlighting the change to existing behavior.
Some companies have set up Outlook clients with aliases or display names that differ from the user’s primary email address and display name stored on the mailbox. Different email addresses or display names may appear on messages when the feature is enabled. When the sending from aliases feature is enabled, it may cause a change in behavior for what shows up in sent messages’ From field.

Future Enhancements

While the GA release delivers the core functionality, we still plan to expand the feature set in future updates. GA is a major milestone for this important feature, and we want to show our commitment to supporting it and customers who choose to use it with this announcement.

Additional functionality we’re investigating (but not necessarily committing to) includes:

Display names per alias
Additional filtering or default controls
Calendar support

Follow up communications will announce which features we plan to work on and deliver post-GA.

Next Steps

Admins who have not done so already can review and enable the feature for your organization using the guidance above.
Please raise support tickets if you uncover any issues that you discover and are not called out in the Known Gaps section. This feature was a significant shift from the previous behavior of Exchange Online and edge cases may still exist.
Monitor for announcements on future enhancements to the feature.

Exchange Online Team

Released: September 2026 V2 Exchange Server Security Updates

The_Exchange_Team — Fri, 02 Oct 2026 19:49:10 GMT

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

Exchange Server Subscription Edition (SE)
Exchange Server 2019
Exchange Server 2016

SUs are available for the following specific versions of Exchange Server:

Exchange SE RTM
Exchange Server 2019 CU14 and CU15 (to access, organization must be enrolled into the Period 2 ESU program)
Exchange Server 2016 CU23 (to access, organization must be enrolled into the Period 2 ESU program)

The September 2026 V2 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes.

The difference between the original September 2026 Security Update release and this V2 release is an addition of CVE-2026-96940. Please see the download KB article for more information.

Exchange 2016 and 2019 updates are available only under the Period 2 ESU program

Exchange Server 2016 and 2019 are out of support. Only customers who enrolled in the Period 2 Extended Security Update (ESU) program are eligible to receive Exchange Server 2016 and 2019 security updates released between May and October 2026.

If you are not part of the Period 2 ESU program, migrate to Exchange Server Subscription Edition (SE) to keep receiving the latest security updates.

If you have already purchased the Period 2 ESU and need information on accessing the latest Security Updates, please contact us by sending an email to ExchangeandSfBServerESUInquiry@service.microsoft.com.

Known issues with this release

Published calendar (.ics) returns HTTP 500 for calendar applications | Microsoft Support – to be resolved in a future update
ContentEngine deadlock because of missing Korean WordBreaker rule files | Microsoft Support – an issue impacting customers with emails in Korean language, to be addressed in a future update

Issues resolved in this release

Update installation

The following update paths are available:

Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
After setup is completed, please reboot the server and check that all Exchange services have started properly. If some services are in a disabled state, that indicates that something interrupted installation of the update. Please see the Workaround 1 in this article.
If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates. Also please see File version error when you try to install Exchange Server updates.

FAQs

The release sequence of this specific update was a bit strange. Why is this?
This specific update, which adds CVE-2026-96940, was published ahead of its intended schedule. We recommend that customers review the deployment guidance and apply the update at the earliest opportunity.

We identified the vulnerability internally and are not aware of active exploitation. ‌
For information about additional updates, customers should refer to our established security update channels.

Documentation may not be fully available at the time this post is published.

This post might receive future updates; they will be listed here (if available).

The Exchange Server Team

EWS Deprecation Is Here – What This Means To You

The_Exchange_Team — Wed, 21 Oct 2026 15:07:04 GMT

The deprecation of EWS in Exchange Online starts today. This is a multi-step process, years in the making, and this post has lots of important information. We will keep this post updated if we have new information to add.

The first change, as previously announced, starting early October 2026, means setting EWSEnabled to True will no longer be sufficient on its own to keep EWS working in the tenant: an AppID allow list (EWSAllowedAppIDs) will be required to specify apps that you want to permit access to EWS.

What happens next

Customer tenants in our multi-tenant (WW) cloud

EWSEnabled state	EWSAllowedAppIDs state	When
True	Null	We populated EWSAllowedAppIDs for all such tenants on October 10-11. After October 11, any tenant admin who sets EWSEnabled = True, must populate EWSAllowedAppIDs by themselves.
Null	Null	Tenants will get a 7-day warning in Message Center to tell them we will populate their EWSAllowedAppIDs (based on 60-day usage) and then set EWSEnabled = False. This process has now started. If EWS gets disabled, tenant admins can temporarily re-enable it by following Exchange Online EWS application stopped working? Do this. \| Microsoft Community Hub.
False	(Any)	EWS is already disabled by tenant admin; Microsoft will make no changes.

Multi-tenant WW cloud now requires the presence of EWSAllowedAppIDs if EWSEnabled = True.

Customer tenants in our Sovereign cloud environments

Stay tuned for more detailed timeline.

Other Important Information

Changing Related EWS Settings

Please remember that:

Changes to EWSAllowedAppIDs take 24 hours to take effect
Changes to EWSEnabled take typically under 1 hour (but can be up to 4 hours)
EWSAllowList property does not need to be configured and/or changed (it is not related to EWS deprecation). Please review this blog if unclear.

If EWS gets disabled by Microsoft, only the tenant admin can re-enable it (Microsoft cannot do this). Step-by-step process is described in Exchange Online EWS application stopped working? Do this. | Microsoft Community Hub.

Microsoft Applications EWS Use

We know customers are still seeing traffic from some Microsoft applications. These applications (if they show up in the EWS usage report) still need to be added to the EWSAllowedAppIDs list to keep working.

The latest on each of these:

Outlook for Windows: Customers should be on latest builds (August 2026 build 16.0.20430.20092 or higher). If customers see problems with EWS disabled, it may be due to customer forced configuration (see this example). We recommend testing to determine if blocking EWS for the Office client AppID is possible in your tenant, without impact. Microsoft successfully disabled EWS internally over a year ago.
Outlook for Mac: Please update to the latest builds and switch to the new Outlook for Mac. If you are already using new Outlook, then this change will not affect you. If you still need to use Classic Outlook, ensure the “Microsoft Office” AppID is in your EWSAllowedAppIDs list.
Excel Power Query: Please see https://aka.ms/xlewsretirement.
PowerBI: we will provide an update soon.
Exchange Server / Exchange hybrid: please see Impact of Exchange Online EWS Deprecation on Hybrid Rich Coexistence and Cross-org Sharing | Microsoft Community Hub.

Updates to this blog post:

10/21/2026: Updated the post to reflect that EWS disablements have been started and linked to the reference on how to re-enable it.
10/15/2026: Updated the table with next steps for WW tenants and reorganized the information for readability.
10/2/2026: Mentioned that EWSEnabled settings can have some variability in how quickly they apply (to account for a few occurances we have seen).

The Exchange Team

Action Required: Upgrade ExchangeOnlineManagement PowerShell Module to Version 3.10.1 or Newer

The_Exchange_Team — Thu, 01 Oct 2026 12:50:20 GMT

We have introduced security enhancements to Exchange Online PowerShell authentication in ExchangeOnlineManagement module version 3.10.1 and newer. These enhancements strengthen the authentication flow and provide additional protection against emerging threats.

Customers using a version earlier than 3.10.1 should upgrade to version 3.10.1 or later. Exchange Online authentication will increasingly rely on the security enhancements available in these versions, and older module versions may not support future authentication requirements.
Customers already using version 3.10.1 or later do not need to take any additional action beyond keeping the module up to date.

Microsoft recommends upgrading as soon as possible to benefit from the latest security, reliability, and performance improvements and to prevent any future PowerShell connectivity issues.

What is Changing

Microsoft plans to begin enforcement of more strict logon requirements for Exchange Online PowerShell module on 31^st March 2027.

After the enforcement:

ExchangeOnlineManagement versions older than 3.10.1 may experience authentication failures in certain interactive authentication scenarios.
ExchangeOnlineManagement version 3.10.1 and later will continue to function normally.

Upgrading the ExchangeOnlineManagement module to versions 3.10.1 (or newer) is the only thing you need to do. No other changes are required.

Who May Be Affected

You may be affected if you are:

Running ExchangeOnlineManagement versions earlier than 3.10.1.
Using PowerShell 7.
Using interactive authentication with Web Account Manager (WAM) disabled.

You may not be affected if you are using:

ExchangeOnlineManagement version 3.10.1 or later.
Certificate-Based Authentication (CBA).
WAM-based authentication.
Windows PowerShell 5.x.

Regardless of your current scenario, Microsoft recommends upgrading to ExchangeOnlineManagement version 3.10.1 or later to stay aligned with current and future Exchange Online requirements.

To verify the currently installed version:

Get-Module ExchangeOnlineManagement -ListAvailable

The latest version of the ExchangeOnlineManagement module is available from the PowerShell Gallery: ExchangeOnlineManagement PowerShell Module

Frequently Asked Questions

We are already using ExchangeOnlineManagement version 3.10.1 or later. Do we need to do anything?
No additional action is required for this change if you are already running ExchangeOnlineManagement version 3.10.1 or later. Continue keeping the module up to date to receive the latest security, reliability, and performance improvements.

Will our existing scripts be affected if I use Certificate-Based Authentication (CBA)?
No. Scripts and automation that use CBA are not expected to be affected by this enforcement because they do not use interactive authentication. However, Microsoft recommends upgrading to ExchangeOnlineManagement version 3.10.1 or later to stay current with the latest security and reliability improvements.

Does this change require us to enable WAM?
No. This change does not require customers to enable WAM.

Do we need to upgrade to the newer module if our current authentication scenario is not affected?
Yes. Microsoft recommends that all customers upgrade to ExchangeOnlineManagement version 3.10.1 or later, regardless of their current authentication scenario. While some scenarios may not be affected by the initial enforcement, upgrading helps ensure compatibility with current and future Exchange Online authentication requirements.

Exchange Online Manageability Team

Impact of Exchange Online EWS Deprecation on Hybrid Rich Coexistence and Cross-org Sharing

The_Exchange_Team — Wed, 30 Sep 2026 13:06:55 GMT

Changes to Exchange Web Services (EWS) in Exchange Online are imminent as per Exchange Online EWS, Your Time is Almost Up | Microsoft Community Hub. While EWS is not getting deprecated on-premises, we wanted to call out two specific scenarios that do impact our on-premises Exchange customers and how to ensure that your business is not impacted when Exchange Online EWS changes start happening between October 2026 and April 2027.

Scenario 1: Exchange hybrid customers who host mailboxes on-premises and online

As we mentioned in Exchange Server Security Changes for Hybrid Deployments | Microsoft Community Hub, Exchange on-premises customers must upgrade to at least May 2026 (or newer) update for Exchange SE to be able to utilize Graph calls for their rich coexistence scenarios (Exchange on-premises users looking up free/busy, MailTip etc. when working with Exchange Online users). Only Exchange SE can use Graph for this functionality. The announcement of update needed is here: Update Your Exchange SE Hybrid On-premises Rich Coexistence to Graph | Microsoft Community Hub.

The problem: As the documentation shows, the scenario where on-premises mailboxes have archive mailboxes in Exchange Online is not fully supported yet. We expect this to be enabled in following months.

What to do: For now, continue using EWS functionality with your Exchange Online tenant if you have on-premises mailboxes with online archives. You can accomplish that by:

Not yet fully switching your on-premises Exchange SE servers to Graph yet by removing EWS permissions.
Making sure that your tenant’s EWSEnabled setting is set to TRUE.
Adding your dedicated Exchange hybrid application into your tenant’s EWSAllowedAppIDs (AppID allow list).

Not impacted:

Organizations that are in hybrid but do not host any mailboxes on premises.
Organizations that have on-premises mailboxes but do not use online archiving for those mailboxes.

Scenario 2: Exchange on-premises organizations who have rich coexistence with a different Exchange Online organization

This is a situation where a purely on-premises organization (let’s call it Contoso) has an organization relationship with a different Exchange Online organization (Fabrikam) to share free/busy, MailTips, User Photos and Calendar Sharing information.

The problem: Such organization relationship relies on on-premises Contoso’s server to speak EWS to Fabrikam’s Exchange Online tenant. Fabrikam tenant must therefore keep EWS enabled (EWSEnabled = True) until we have a solution which does not use EWS from on-premises.

What to do: The Exchange Online organization (Fabrikam in our example) must ensure that tenant’s EWSEnabled setting is set to TRUE.

Other variations:

Two Exchange Online organizations using org relationships to share free/busy etc. should see Cross-tenant Free/Busy, MailTips, and Calendar Sharing are moving to Cross-Tenant Access Policy | Microsoft Community Hub (no on-premises is involved).
Two Exchange on-premises organizations using org relationships with each other (no Exchange Online involvement). No change needed at this time.

The Exchange Team

Released: September 2026 Exchange Server Security Updates

The_Exchange_Team — Thu, 24 Sep 2026 17:56:48 GMT

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

Exchange Server Subscription Edition (SE)
Exchange Server 2019
Exchange Server 2016

SUs are available for the following specific versions of Exchange Server:

Exchange SE RTM
Exchange Server 2019 CU14 and CU15 (to access, organization must be enrolled into the Period 2 ESU program)
Exchange Server 2016 CU23 (to access, organization must be enrolled into the Period 2 ESU program)

The September 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes.

Exchange 2016 and 2019 updates are available only under the Period 2 ESU program

If you are not part of the Period 2 ESU program, migrate to Exchange Server Subscription Edition (SE) to keep receiving the latest security updates.

Known issues with this release

Published calendar (.ics) returns HTTP 500 for calendar applications | Microsoft Support – to be resolved in a future update
ContentEngine deadlock because of missing Korean WordBreaker rule files | Microsoft Support – an issue impacting customers with emails in Korean language, to be addressed in a future update

Issues resolved in this release

Update installation

The following update paths are available:

Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
After setup is completed, please reboot the server and check that all Exchange services have started properly. If some services are in a disabled state, that indicates that something interrupted installation of the update. Please see the Workaround 1 in this article.
If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates. Also please see File version error when you try to install Exchange Server updates.

FAQs

Documentation may not be fully available at the time this post is published.

Updates to this blog post:

Sep 24, 2026: Added a new known issue (content index issue when emails in Korean are present)
Sep 8, 2026: Corrected one of issues addressed to the free/busy time zone issue over Graph

This post might receive future updates; they will be listed here (if available).

The Exchange Server Team

Exchange Server AD FS Modern Authentication: Expanded Outlook client support

The_Exchange_Team — Tue, 08 Sep 2026 14:14:41 GMT

We are pleased to announce expanded Outlook client support for Exchange Server AD FS Modern Authentication.

In our previous update, we announced broad Outlook for Windows/Mac support and support for the native Mail app on iOS and macOS. We are now extending this support to Outlook for iOS and Outlook for Android.

Outlook for iOS and Outlook for Android can now use AD FS Modern Authentication to access mailboxes in supported pure on-premises Exchange Server deployments.

Deployment context: AD FS Modern Authentication is intended for pure on-premises Exchange organizations that don't use Microsoft Entra ID or an Exchange hybrid configuration. Exchange hybrid organizations should continue to use Hybrid Modern Authentication (HMA) with Microsoft Entra ID.

Supported clients at a glance

Client	Supported release or OS	Administrator action
Outlook for Windows	Supported Microsoft 365 Apps channels and supported perpetual releases; Windows 11 22H2 or later	Install the required Windows update, trust the AD FS service URLs, and enable Exchange on-premises Modern Auth in Outlook.
Outlook for Mac	Outlook for Mac in Microsoft 365, build 16.106 or later; macOS Sequoia or later	Use Exchange Server Subscription Edition with the December 2025 or later Security Update, and configure ADFSAuthorizedURLs.
Outlook for iOS	Latest supported Outlook and iOS versions	Follow the Exchange and AD FS configuration guidance.
Outlook for Android	Latest supported Outlook and Android versions	Follow the Exchange and AD FS configuration guidance.
Native Mail app for iOS and macOS	iOS 17.6.1 or later; macOS Sequoia or later	Configure the documented native client application and permissions in the AD FS Outlook application group.

Updated documentation

We have updated the deployment documentation to make the supported-client requirements easier to review:

A new summary brings all supported clients and operating-system requirements together.
Outlook for Windows build, Windows update, registry, and AD FS trusted-domain requirements are grouped under the Windows client.
Outlook for Mac requirements include the ADFSAuthorizedURLs Terminal configuration, a multiple-namespace example, and the equivalent Mobile Device Management settings.

Learn more

For complete prerequisites and configuration steps, see Enable Modern Auth in Exchange Server on-premises.

For background on the earlier client expansion, see Update on Exchange Server ADFS Modern Authentication support.

The Exchange Server Team

Take control of your EWSAllowedAppIDs list before EWS access changes

The_Exchange_Team — Fri, 04 Sep 2026 14:47:38 GMT

As we prepare for the final phase of Exchange Web Services retirement, we are refining how EWSAllowedAppIDs setting (which you can use to define your EWS AppID allow list) will be applied. Our goal is to protect customers from unexpected disruption while keeping control of the allow list with each tenant administrator.

We strongly recommend that every customer review EWS usage and configure EWSAllowedAppIDs themselves. If an administrator has already configured EWSAllowedAppIDs, Microsoft will not overwrite or change the list. The customer-managed list remains authoritative.

What happens during rollout

Beginning October 1, 2026, Microsoft will start enabling the updated behavior as outlined in previous blog post. With this logic change, if the customer has EWSEnabled set to True, EWS will require an Allowed AppID list. The timing will depend on when the change reaches that tenant's environment.

If organization has:

EWSEnabled = True - Microsoft will ensure that each tenant has an EWSAllowedAppIDs list. If the customer has not created a list, Microsoft will populate one to reduce the risk of an outage when the cloud environment logic changes (and AppID allow list becomes required when EWSEnabled = True). The list will be based on the previous 60 days of usage, and so it may miss applications that run infrequently, and it may include apps you no longer want to have access. This will happen shortly before the logic change takes place.
EWSEnabled = Null - Microsoft will only populate EWSAllowedAppIDs, if the customer has not already done so. This will happen a few days before changing EWSEnabled to False during the per-tenant rollout of that setting. This means that tenants that did not change EWSEnabled property from Null could have no AppID allow list defined until later in October.

Customers that still require EWS should act now: configure EWSAllowedAppIDs to include only the applications that must continue using EWS, then set EWSEnabled to True. Continue planning to move applications from EWS to Microsoft Graph before EWS is retired. By controlling your own EWSAllowedAppIDs values, you can ensure that only applications that you really want to have EWS access after October rollouts start can still use EWS.

The Exchange Team

Exchange 2016/2019: Throttling and Blocking up to the Final Public Update Baseline

The_Exchange_Team — Wed, 02 Sep 2026 15:34:48 GMT

Several years ago, we announced Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online. Since then, we have been periodically updating the “oldest acceptable version” as we keep releasing more security updates for Exchange Server.

So far, these changes have been implemented silently. But, today, we are announcing that starting in the second week of September 2026, we will raise the oldest allowed version for Exchange 2016 or Exchange 2019 servers that connect to Exchange Online over an inbound connector type of OnPremises to at least the last available public update version, released in October 2025. This update level was released almost a year ago, and all organizations should have updated to it, since.

A very important implication of this change:

After going into effect, the oldest Exchange Server version allowed to send email to Exchange Online over the inbound OnPremises connector will be Exchange with October 2025 updates.
The next time we update the oldest allowed Exchange Server version for sending email to Exchange Online, the required version of Exchange Server 2016 or Exchange Server 2019 will be newer than any publicly available update.

When the next adjustment happens (we estimate in several months), only customers who were enrolled into our ESU program and customers who migrated to Exchange SE will have the required update versions to not be throttled or blocked when sending email to Exchange Online.

As a reminder, throttling and blocking of email from persistently vulnerable Exchange servers to Exchange Online:

Applies to servers that connect to Exchange Online over an inbound connector type of OnPremises.
DOES NOT apply to servers that send email to Exchange Online in other ways (different types of connectors etc.)
DOES NOT (currently) apply to “all servers in your organization”, but only to servers that connect to Exchange Online over an inbound connector type of OnPremises. This might change in the future.

Finally, we wanted to be clear that the fact that the “oldest version to avoid throttling and blocking in Exchange Online” is always older than the latest version available does not mean that we consider versions older than the latest security update “safe to use”. Anything older than the latest is vulnerable to everything we have fixed/released/announced since that older version. Especially in this calendar year, we have been releasing many security updates for Exchange Server and it is likely that we will continue to do so for the foreseeable future.

With a rapidly changing security landscape, no organization should consider it safe to run their organization's business email on an outdated version of Exchange Server. Please see Exchange Server update FAQ.

Additional reading: How to pause throttling and blocking of out-of-date on-premises Exchange Servers.

The Exchange Server Team

Tell us how you use ObjectGuid, SamAccountName, and DistinguishedName in Exchange Online

The_Exchange_Team — Wed, 02 Sep 2026 17:31:16 GMT

As Exchange Online continues its multi-year directory modernization, we are evaluating the future of several long-standing identifier properties: ObjectGuid (most would recognize this property as Guid), SamAccountName, and DistinguishedName.

Today, multiple properties can identify the same object in Exchange Online. While this has provided flexibility and compatibility, some of these identifiers reflect design decisions from an earlier era and can add complexity for customers building and maintaining automation, integrations, and administrative workflows.

As part of our modernization efforts, we are exploring whether a smaller and more consistent set of identifiers could better support the future of the service. No decisions have been made. Before determining a path forward, we want to better understand how these properties are used today, what the impact of potential changes could be, and what alternatives, notice periods, and migration assistance customers would need.

We are particularly interested in hearing from customers, partners, and solution providers who use these properties in scripts, automation, reporting, applications, provisioning systems, or operational processes.

The potential changes discussed in this survey apply only to the Exchange Online directory and do not represent changes to on-premises Active Directory or Exchange Server.

Please take a few minutes to complete our survey. Your feedback will help inform our evaluation and any future decisions in this area.

Take the Survey: Exchange Online Directory: Identifier Properties Survey – Fill out form

Thank you!
The Exchange Team

Help us shape Exchange Server on-premises to different online org Free/Busy after EWS retirement

The_Exchange_Team — Mon, 24 Aug 2026 16:57:31 GMT

As shared in Exchange Online EWS, Your Time is Almost Up, Exchange Web Services in Exchange Online will begin phased disablement in October 2026 and will be fully disabled in April 2027. As part of this work, we are addressing the remaining Exchange Server collaboration scenarios that currently depend on the Exchange Online EWS endpoint.

Most Exchange Server Free/Busy scenarios will not change. Free/Busy between two Exchange Server (purely on-premises) organizations will continue using Federation/DAuth and Organization Relationships. Exchange hybrid organization can continue sharing Free/Busy between Exchange Server and its own Exchange Online tenant using OAuth and IntraOrganizationConnectors through the dedicated Exchange hybrid app, with Graph replacing EWS in the modern hybrid flow.

The scenario requiring a new path is an Exchange Server organization retrieving Free/Busy or MailTips from another organization's Exchange Online tenant through an EWS-dependent Organization Relationship. For Exchange Server to external Exchange Online scenario, we are evaluating leveraging Microsoft 365 Cross-Tenant Access Policy which is also becoming the standard for Free/Busy, calendar, and MailTips collaboration between Microsoft 365 tenants.

Before finalizing the direction, we want feedback from customers and partners - particularly organizations that operate Exchange Server without an existing M365 tenant.

Please share your feedback on this approach through the form: Survey

This feedback request is specifically about Exchange Server (Organization A) to a different Exchange Online (Organization B) collaboration. Exchange Server-to-Exchange Server Organization Relationships (two purely on-premises organizations) are not in scope and will continue unchanged.

The Exchange Team

Notes from the field: testing EWSAllowedAppIDs safely

The_Exchange_Team — Wed, 14 Oct 2026 18:10:47 GMT

As customers prepare for the final phase of Exchange Web Services (EWS) retirement in Exchange Online, many are asking the same practical question: how can I prove that EWSAllowedAppIDs is working before I depend on it? This field guide walks through a controlled positive-and-negative test, explains what the result means, and highlights an important naming trap that we are already seeing in customer conversations.

A note from the field

The most common confusion is not about the PowerShell syntax. It is about two similarly named controls that operate at different layers. EWSAllowedAppIDs is the new application-ID control for EWS. The older EWSAllowList and EWSBlockList settings are user-agent controls associated with EwsApplicationAccessPolicy, and they can affect both EWS and REST traffic.

Understand the two controls before testing

EWSAllowedAppIDs is a tenant-level list of application (client) IDs. When EWS is enabled and the list contains one or more Application IDs, only the listed applications are permitted to access EWS. This is the control to validate when you are testing an application's EWS access during the retirement transition.

EWSAllowList and EWSBlockList are older, user-agent-based controls. Despite their names, the underlying access policy is not limited to EWS; it will also affect REST requests. Customers that already use these settings may still need them for REST access control after EWS retirement.

The controls are evaluated independently. In practical terms, an EWS request must pass the application-ID control and then any applicable user-agent control. A successful App-ID test therefore does not prove that a separate user-agent policy is configured correctly.

What the test proves

A valid before-and-after test demonstrates the EWSAllowedAppIDs behavior only when all of the following are true:

The application can obtain an OAuth token.
The application has EWS application permission and tenant-wide admin consent.
EWSEnabled is set to True for the test.
The test mailbox contains at least one item in the Inbox.
The App ID is present for the positive test and absent for the negative test.
At least 24 hours has elapsed after each allow-list change.

Before you start

Perform this procedure in a test tenant if you can. Removing an application from the list can stop a production workload from accessing EWS after the configuration change has propagated.

Prepare the following:

A test mailbox with at least one Inbox item.
An app registration in the same tenant as the mailbox.
EWS application permission with tenant-wide admin consent.
A client secret or certificate for application authentication. Treat a client secret as a password and do not place it in a shared script or source-control repository.
Exchange Online PowerShell access and permission to run Get-OrganizationConfig and Set-OrganizationConfig.
Download the Test-EWSAppAccess.ps1 script. This is a test script that you can use unless you want to test with a real app. Script documentation can be found at Testing EWS App Access.

Record the tenant ID, application (client) ID, test mailbox SMTP address, and the selected authentication material before starting.

Test 1: Confirm access while the app is allowed

Connect to Exchange Online PowerShell.

Connect-ExchangeOnline

Inspect the current EWS state and capture the complete existing App-ID list.

Get-OrganizationConfig | Format-List EWSEnabled Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

For a controlled test, set EWSEnabled to $null (all EWS allowed, AppID Allow List ignored).

Set-OrganizationConfig -EWSEnabled $null

Add the test App ID without overwriting any existing entries. The EwsAllowedAppIDs command writes the complete list, so preserve the current value.

$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy).EwsAllowedAppIDs $updated = @($current -split "," | ForEach-Object { $_.Trim() } | Where-Object { $_ }; $appId) | Select-Object -Unique Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Verify that the App ID was written.

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Wait for the change to propagate. Because of the Exchange Online configuration caching, this can take up to 24 hours.
Set EWSEnabled to True

Set-OrganizationConfig -EWSEnabled $true

Wait for under 1 hour (but can be up to 4 hours), for the change to become effective.
Download Test-EWSAppAccess.ps1 and run Test-EWSAppAccess.ps1 with application authentication. The Mailbox parameter is required when using application permissions.

.\Test-EWSAppAccess.ps1 -AppId $appId -TenantId $tenantId -Mailbox $mailbox -SecretKey $secretKey

A successful test should report that the application accessed the mailbox.

Application <appid> successfully accessed mailbox <mailbox></mailbox></appid>

Confirm that $LASTEXITCODE is 0 and save the output with your change record.

Test 2: Remove the app and confirm access is blocked

Remove only the test App ID, preserving every other entry.

$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy).EwsAllowedAppIDs $updated = $current -split "," | ForEach-Object { $_.Trim() } | Where-Object { $_ -and $_ -ne $appId } Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Confirm that the App ID is no longer present.

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Wait at least 24 hours before retesting. An immediate success can simply mean that an Exchange Online server still has the previous configuration cached.
Run the same Test-EWSAppAccess.ps1 command again.
After propagation, the expected result is a failure.

Application <appid> failed to access mailbox <mailbox></mailbox></appid>

Confirm that the process returns exit code 1. If the first test failed too, troubleshoot authentication, permissions, consent, mailbox access, and script dependencies before concluding that the allow list caused the failure.

Restore the test App ID to the full list, verify the configuration, wait for propagation, and repeat the successful-access test.

Do not leave a production tenant with an unintentionally empty or incomplete App ID allow list.

The fastest way to re-enable EWS after App ID blocking

Let’s say you are testing this process in a tenant and after setting both EWSEnabled = True and populating EWSAllowedAppIDs you do not see results that you expected and need the quickest way to undo your changes and re-enable the use of EWS in your tenant.

Changes to EWSAllowedAppIDs take ~24 hours to fully apply to your tenant.
Changes to EWSEnabled take about 1 hour.
EWSAllowedAppIDs (Allow List) is ignored if EWSEnabled is set to Null.

Therefore, the quickest way to re-enable EWS in an unrestricted way is to set EWSEnabled back to Null. One hour later, EWS will be unrestricted:

Set-OrganizationConfig -EWSEnabled $null

EWSEditor is another option

EWSEditor is also available for administrators and developers who prefer an interactive EWS API explorer. It can be useful for making a real EWS call against a test mailbox while using the same application identity you are validating.

You still need a correctly configured OAuth application, EWS permissions and consent, a controlled test mailbox, a recorded baseline, and enough time for EWSAllowedAppIDs changes to propagate.

Common pitfalls to avoid

Running the negative test immediately after removing the App ID.
Replacing the entire list instead of preserving existing App IDs.
Testing with an empty Inbox when the test script reads the first Inbox item.
Treating an OAuth, permission, consent, or credential failure as proof that EWSAllowedAppIDs blocked the request.
Confusing the user-agent-based EWSAllowList or EWSBlockList with the new App-ID-based EWSAllowedAppIDs control.
Adding an App ID for a workload that uses REST but does not call EWS.

Customer guidance in one paragraph

If an application calls EWS and requires temporary access during the retirement transition, validate its application ID with EWSAllowedAppIDs in a test tenant. If a tenant already uses EwsApplicationAccessPolicy, assess its EWSAllowList or EWSBlockList separately because those user-agent settings can also affect REST. The similar names do not make the controls interchangeable.

This distinction matters because we are already seeing customers assume that any setting beginning with “EWS” is part of the EWS retirement exception process. It is not. Making that mistake can create unnecessary configuration changes or interrupt REST workloads that were never using EWS.

The simple rule: use EWSAllowedAppIDs for the new EWS application-ID gate; use EWSAllowList or EWSBlockList only for the older user-agent policy. Test each layer independently.

And lastly: Set up your EWSAllowedAppIDs parameter while EWSEnabled is still Null, then wait 24h before changing EWSEnabled to True.

Sources and further reading

Testing EWS App Access, PowerShell-EWS-Scripts Wiki: https://github.com/David-Barrett-MS/PowerShell-EWS-Scripts/wiki/Testing-EWS-App-Access
EWSEditor project: https://github.com/dseph/EwsEditor

David Barrett
(All-round good guy and Exchange development expert)

Understanding the new 100 GB mailbox entitlement for Microsoft 365 Business suites

The_Exchange_Team — Wed, 19 Aug 2026 20:25:03 GMT

Microsoft 365 Business Basic, Business Standard, and Business Premium now include an additional 50 GB of primary email storage for eligible users. This brings the supported primary mailbox entitlement from 50 GB to a maximum of 100 GB. We wanted to talk about this change, so Exchange Online administrators understand how this mailbox size increase is delivered. We will focus only on mailbox size in this post.

What changed for the Business suites

Microsoft announced an additional 50 GB of email storage for Microsoft 365 Business Basic, Business Standard, and Business Premium as part of the 2026 Microsoft 365 packaging updates. The packaging changes are rolling out June - September 2026, with customers receiving advance notice through Message Center before the changes became available in their tenant.

The additional storage changes the effective primary mailbox size for eligible Business suite users from 50 GB to 100 GB. The affected commercial product suites are:

Microsoft 365 Business Basic
Microsoft 365 Business Standard
Microsoft 365 Business Premium

After the rollout, all users that had the appropriate licenses assigned will have received a new service plan and the corresponding mailbox quota increase.

Please note: this mailbox size increase applies only to the above-mentioned suite licenses; there can still be licenses (such as standalone Exchange Online Plan 1) that have the maximum mailbox size set at 50 GB.

The supported quota outcome

The additional storage establishes a maximum effective quota of 100 GB for the eligible Business suite scenario.

A user whose highest applicable Exchange mailbox plan is the Business suite plan receives an effective 100 GB quota when the storage add-on is present.
A user who also has an Enterprise or standalone Exchange license that already provides a 100 GB mailbox remains entitled to 100 GB.
A user who has multiple licenses assigned, which contain multiple Exchange service plans (this is known as Concurrent Licensing), will be granted the maximum quota provided by a single product – the quotas are not additive across products. For example, a user with one of the Business Suite and a separate Enterprise license containing Exchange Online Plan 2, will still be entitled to 100 GB. The quota increase for the Business suites affects the base mailbox size only. It does not provide archive capabilities.

How the additional quota is implemented

The Business suite provides the total storage through a combination of service plans:

The Business suite Exchange plan is represented by BPOS_S_STANDARD, which grants 50 GB of storage.
The additional entitlement is represented by the EXCHANGE_STORAGE_50GB service plan, which adds +50 GB, increasing the total quota to 100 GB.

Both plans must be enabled for the user to have the full 100 GB.

In your Microsoft 365 admin center, this will look like the following – there is a “standard” license and there is an add-on:

Custom mailbox quotas are preserved

If an administrator has configured a custom mailbox quota, the additional storage logic does not overwrite that setting. Likewise, removing the add-on does not replace a later administrator-defined custom value. This protects deliberate tenant-level mailbox management choices.

For example, if an administrator configured the mailbox for user with a Business suite from the original default of 50 GB down to 20 GB, the user’s quota will remain at 20 GB even after the additional service plan is assigned to them.

Reviewing the user’s licenses and service plans

In the Microsoft 365 admin center, open Users > Active users, select the user, and review Licenses and apps. Confirm that the user has an eligible Microsoft 365 Business suite and that its included services are enabled. The Billing > Licenses page can also show whether the product was assigned directly or through group-based licensing.

Microsoft Graph PowerShell can provide a more detailed service-plan view. The following example retrieves the assigned license details and searches for the storage service plan:

$licenses = Get-MgUserLicenseDetail -UserId user@contoso.com $licenses.ServicePlans | Where-Object ServicePlanName -eq "EXCHANGE_STORAGE_50GB" | Select-Object ServicePlanName, ProvisioningStatus

Review the effective Exchange mailbox quota

Exchange Online PowerShell shows the quota values that Exchange presents for the mailbox. For example:

Get-Mailbox -Identity user@contoso.com | Format-List IssueWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota, UseDatabaseQuotaDefaults

For an eligible Business suite user with the additional storage service plan and no custom quota, the effective maximum mailbox quota should be 100 GB.

Common license and quota scenarios

Business suite with the +50 GB storage add-on: user’s effective primary mailbox maximum is 100 GB.
Business suite without the +50 GB storage add-on: base Business mailbox quota continues to apply until the additional service plan is provisioned (should happen automatically).
Business suite plus an Enterprise or standalone plan that already grants 100 GB: effective maximum remains 100 GB because Exchange uses the highest applicable entitlement rather than adding the quotas.
Business suite plus a lower Exchange capability (for example, F3 license): Business plan remains the highest capability, so the add-on can raise the effective maximum to 100 GB.
Custom quota: administrator-defined values remain in effect and are not replaced by the automatic +50 GB boost.
+50 GB add-on explicitly removed: for a mailbox using default plan quotas, Exchange returns to the applicable plan default. A custom value set by an administrator remains custom.

Rollout and license propagation

The additional storage is represented through licensing data, so the service plan must be assigned and processed before Exchange can return the higher effective quota. During broad service-plan rollout or backfill operations, users in the same organization may not all reflect the change at the same time. It is possible that some of your users received additional 50 GB mailbox size increase while others did not – you should expect that this gets resolved automatically if users are licensed by one of affected business suite licenses.

Administrators should not remove and reassign an Exchange license solely to force a quota refresh unless Microsoft Support specifically directs that action. Removing a product license removes access to its services and starts the applicable data-retention lifecycle. Please keep using your normal license-assignment processes.

Exchange Online Team

Where is Exchange SE CU1 anyway?

The_Exchange_Team — Thu, 13 Aug 2026 21:05:31 GMT

We are getting questions from our customers on when they can expect us to release Exchange SE Cumulative Update 1 (CU1). After all, in the past we mentioned that it would be released by the end of the first half of calendar year 2026, later updated to “second half of 2026”. What is the deal? Where is CU1?

Over the last few months, various Microsoft execs made statements explaining how Microsoft is leveraging a variety of AI tools to help find vulnerabilities in our products (examples of such announcements can be found here, here and here).

It should come as no surprise that this is a Microsoft-wide initiative. Many teams, Exchange Server included, are working through reported issues – which includes validation that they are real security issues, reproducing, fixing, testing for regressions / issues after fixes are deployed and releasing updates monthly.

We have been releasing security updates for Exchange Server regularly: May, June, July, August. You can expect this increased pace of security releases to continue. We are prioritizing security above all else.

While all of that is happening, we are also working on CU1; we are regularly rolling our monthly security payload into our internal CU1 build and plan to release Exchange SE CU1 as soon as we get a reasonable stable point and have a month without pressing security payload. We really do not want to try to release a new CU1 and then immediately supersede the new CU with security updates as that would create double the update work for many organization administrators. Even internally, trying to ensure that two major releases (Security Update and a CU) get appropriately tested so we can ensure high quality and nothing falls through the cracks would be very challenging as CU1 must be all inclusive of everything that we released since the RTM.

In short: Exchange SE CU1 is coming; we do not have a date to give you. But we did not forget about it.

Until then, please keep Upgrading your organization to Exchange Server SE | Microsoft Community Hub and if you are already on Exchange Server SE, stay up to date!

The Exchange Server Team

Released: August 2026 Exchange Server Security Updates

The_Exchange_Team — Tue, 08 Sep 2026 20:41:07 GMT

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

Exchange Server Subscription Edition (SE)
Exchange Server 2019
Exchange Server 2016

SUs are available for the following specific versions of Exchange Server:

Exchange SE RTM
Exchange Server 2019 CU14 and CU15 (to access, organization must be enrolled into the Period 2 ESU program)
Exchange Server 2016 CU23 (to access, organization must be enrolled into the Period 2 ESU program)

The August 2026 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes.

OWA Light is disabled starting with this update

As we announced several weeks ago, this update (and any subsequent updates) permanently disables the OWA Light client when update is installed on an Exchange server. See related CVE-2026-62914 for more information.

Customers who are not able to install August 2026 (or later) update should disable OWA Light on their servers to address this particular CVE.

Exchange 2016 and 2019 updates are available only under the Period 2 ESU program

If you are not part of the Period 2 ESU program, migrate to Exchange Server Subscription Edition (SE) to keep receiving the latest security updates.

Known issues with this release

Wrapper messages appear in shared mailbox inbox in hybrid environments | Microsoft Support – to be addressed in an upcoming update.
If a backend mailbox server is updated to August 2026 SU, but the frontend server proxying the inbound MRS connection is on an older version, MRS migration might fail with TooManyTransientFailureRetriesPermanentException error. This can manifest on any MRS request, including Test-MigrationServerAvailability. Updating the front end server to the August 2026 SU should resolve this problem.
Published calendar (.ics) returns HTTP 500 for calendar applications | Microsoft Support
Hybrid Free/Busy over MS Graph drops the requester timezone | Microsoft Support

Update installation

The following update paths are available:

Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
Re-run the Health Checker after you install an update to see if any further actions are needed.
After setup is completed, please reboot the server and check that all Exchange services have started properly. If some services are in a disabled state, that indicates that something interrupted installation of the update. Please see the Workaround 1 in this article.
If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates. Also please see File version error when you try to install Exchange Server updates.

FAQs

Documentation may not be fully available at the time this post is published.

Major updates to this post:

Sep 8, 2026: mentioned the correct known issue for August (Graph time zone issue)
Aug 28, 2026: Linked to the KB article talking about the anonymous calendar publishing known issue.
Aug 25, 2026: Added a known issue with anonymous calendar publishing failing to update after SU is installed, with a workaround.
Aug 24, 2026: Added a known issue that can happen with MRS migrations if not all servers are updated to August 2026 updat yet.

The Exchange Server Team

Cross-tenant Free/Busy, MailTips, and Calendar Sharing are moving to Cross-Tenant Access Policy

The_Exchange_Team — Tue, 20 Oct 2026 15:55:23 GMT

Update 10/20/2026: This blog post discusses a feature that is not yet fully available. Please see The rollout schedule for Cross-Tenant Access Policy table below for expected availability dates.

If your organization shares Free/Busy, MailTips, or calendars with other Microsoft 365 organizations, there's a change coming that you'll want to understand and plan for. If it doesn't, you can stop reading in about two paragraphs. This post covers what's changing as Exchange Web Services (EWS) is deprecated, how the new Microsoft 365 Cross-Tenant Access Policy model replaces the old plumbing, how to tell whether your tenant is affected, and what to do about it. The official announcement is Message Center post MC1446796; consider this the friendlier, more complete version with the context we wish the MC post had room for.

Is your organization impacted by this change?

Only if your organization shares Free/Busy, Calendars, or MailTips information with other Microsoft 365 organizations.

This change affects cross-tenant / cross-organization collaboration - the ability for people in your organization (Organization A) and people in a partner's Microsoft 365 tenant (Organization B) to see each other's Free/Busy availability, shared calendars, and MailTips (such as out-of-office notices). If you've set up these relationships with subsidiaries, partners, vendors, or recently acquired companies, you need to understand this and take action before the deadline, or those experiences will break.

Organization sharing is not set up by default – tenant admins must have set it up by themselves.

Not impacted scenarios:

Sharing Free/Busy availability, calendars, or MailTips within your organization.
Sharing Free/Busy availability, calendars, or MailTips between your on-premises and online users in an Exchange Hybrid Deployment. You should work on your Dedicated Hybrid App as per our previous announcements.
Sharing Free/Busy availability, calendars, or MailTips with another organization running on-premises Exchange. Watch for future Message Center posts covering this scenario (no immediate impact but changes are coming). If you are sharing with a partner organization running both Exchange Online and on-premises, the sharing with Exchange Online is impacted.

The “How to check your sharing configurations?” section below has more information on how to verify.

What's changing, and why

Deprecation of Exchange Web Services (EWS) begins on October 1, 2026. Several cross-tenant collaboration features - Free/Busy, MailTips, and Calendar Sharing – currently use Exchange Web Services under the hood. As EWS is retired in Exchange Online, the mechanism that carries those cross-tenant requests has to move somewhere else.

That “somewhere else” is Microsoft 365 Cross-Tenant Access Policy. It replaces the EWS-based approach, and it becomes available starting September 2026. The end state is the same experience your users have today - someone sees a colleague's calendar availability across a tenant boundary - but it travels over a modern, Entra-governed path instead of legacy EWS. It's part of the broader push to retire legacy protocols and eliminate high-privilege access.

How the new model works

Today, three Exchange Online configurations drive cross-tenant sharing:

Organization Relationships - used to share Free/Busy and MailTips with other Microsoft 365 tenants.
Availability Address Spaces - used to share Free/Busy with other Microsoft 365 tenants (specifically those set with AccessMethod: OrgWideFBToken).
Sharing Policies - used to share calendars externally, either through invitations sent to recipients in other Microsoft 365 organizations, or calendars published for anonymous access via an internet URL.

Historically, each of these has used EWS to fetch availability and MailTips from the partner tenant. Going forward, that trust and data exchange is expressed through Microsoft 365 Cross-Tenant Access Policy instead. You still decide which partner organizations you collaborate with and what you share; only the mechanism carrying it changes. Migrating means understanding your current configuration, standing up the equivalent Cross-Tenant Access Policy, validating that sharing still works, and then removing the old configurations you no longer need.

How to check your sharing configurations?

MC1446796 was sent to every tenant but most admins who received it won't actually need to do anything. So before you plan a migration, confirm you're in scope. Run these three commands in Exchange Online PowerShell:

Get-OrganizationRelationship | Format-List Name, DomainNames, Enabled, FreeBusyAccessEnabled, FreeBusyAccessLevel, FreeBusyAccessScope, MailTipsAccessEnabled, MailTipsAccessLevel, MailTipsAccessScope

You're affected if the results show Enabled: True, and either FreeBusyAccessEnabled: True or MailTipsAccessEnabled: True, and the external organization is hosted in Microsoft 365. Otherwise, no action is needed.

Get-SharingPolicy | Format-List Name, Domains, Enabled, Default

You're affected if the results show Enabled: True, the Domains property contains at least one rule with a CalendarSharingFreeBusy access level (Simple, Detail, or Reviewer), the targeted external organization is hosted in Microsoft 365, and the policy is assigned to one or more mailboxes. Otherwise, no action is needed.

One note on that last check: rules that begin with Anonymous: represent calendar publishing to anonymous internet recipients through a published URL, and they show up in the same output. If you have an Anonymous: rules with a CalendarSharingFreeBusy access level (Simple, Detail, or Reviewer) then you are affected.

Sharing Free/Busy with another organization hosted in Microsoft 365 via Availability Address Space (with AccessMethod OrgWideFBToken) does not depend on Exchange Web Services and is not impacted by EWS deprecation. However, you may still wish to migrate these configurations to Microsoft 365 Cross-Tenant Access Policy, which supports additional security features and more granular configuration options. Run this command to check your Availability Address Space configurations:

Get-AvailabilityAddressSpace | Format-List ForestName, AccessMethod

The rollout schedule for Cross-Tenant Access Policy

This feature becomes available starting September 2026, so your migration window opens as the rollout reaches your environment. Wait to migrate until after the rollout completes in the environment where your tenant and your partner’s tenant are hosted. Here's the schedule:

For Free/Busy sharing:

Environment	Rollout begins	Expected completion
Worldwide	August 2026	September 23, 2026
GCC	September 2026	Rollout paused
GCC High	September 2026	Rollout paused
DoD	September 2026	Rollout paused

For MailTips:

Environment	Rollout begins	Expected completion
Worldwide	August 2026	September 29, 2026
GCC	September 2026	Rollout paused
GCC High	September 2026	Rollout paused
DoD	September 2026	Rollout paused

For Calendar Sharing:

Environment	Rollout begins	Expected completion
Worldwide	August 2026	October 30, 2026
GCC	September 2026	Rollout paused
GCC High	September 2026	Rollout paused
DoD	September 2026	Rollout paused

What happens if you do nothing?

Starting October 1, 2026, EWS will be gradually disabled in Exchange Online, in line with the deprecation communications we've been sending for a while now. As that rollout reaches your tenant, any cross-tenant Free/Busy, MailTips, and Calendar Sharing that still depends on EWS will stop working - people in your partner organizations may no longer see Free/Busy, MailTips, or shared calendars coming from your tenant. You may no longer be able to see Free/Busy, MailTips, or shared calendars from the partner organization. If you're in scope and take no action, that's the outcome.

Not ready by October? You have a runway

We realize that the window between this announcement and the start of the rollout is short. For organizations with many partner tenants and a tangled web of organization relationships, analyzing, testing, and executing a migration in a few weeks is a tall order, and we know it.

There is a safety valve. You can keep the existing cross-tenant sharing working by setting EWSEnabled to True, following the guidance in our earlier post, Exchange Online EWS, Your Time Is Almost Up. That keeps the old path alive while you prepare and execute the migration. This extension remains available until the final EWS shutdown on April 1, 2027 - which is the hard deadline for completing the move.

You do not need to specify AppIDs in your tenant Allow List to keep the old method working, as it doesn’t rely on AppIDs (as it doesn’t use OAuth). If EWSEnabled is set to True, we’ll allow the cross-tenant flows covered here to continue working until April 2027, no matter the tenant Allow List state.

What you need to do

Confirm scope. Run the checks above. If nothing flags, you're done.
Plan your migration for after the rollout reaches your tenant and before EWS deprecation affects you. Review the migration guide for step-by-step instructions.
Migrate - understand your current configurations, set up the new Microsoft 365 Cross-Tenant Access Policies, validate that sharing works, and remove the configurations you no longer need.
If you can't finish by October 1, set EWSEnabled to True to keep sharing alive until you can migrate, no later than April 1, 2027.

Frequently Asked Questions

We cannot make the October deadline for this migration. Other than setting EWSEnabled to True for our tenant, do we need to add some AppID to the tenant EWS Allow List?
Setting EWSEnabled to True is all that you need to do to keep your current configurations for sharing with other organizations working. You do not need to add anything to the EWSAllowedAppIDs tenant value. Please note that both your and your partner Microsoft 365 organization need to set EWSEnabled to True to continue bidirectional information sharing.

What happens if we set up sharing using the new model on my side but the partner organization does not?
For bidirectional sharing, both organizations need to configure Microsoft 365 Cross-Tenant Access Policies and disable the old configurations before sharing will work in both directions.
For one-way sharing, only the resource tenant (the tenant with the mailboxes that contain the Free/Busy, Calendar, or MailTips information) needs to configure a Microsoft 365 Cross-Tenant Access Policy. Once configured, users in the home tenant (the tenant with users trying to access the shared information) will be able to access the information via Cross-Tenant Access Policy. Ensure both organizations disable old configurations for sharing as these will prevent requests from flowing through the new Cross-Tenant Access Policy.

What happens if we extend EWS deprecation in my tenant but the partner organization does not and we do not complete the migration before EWS deprecation starts?
After EWS is disabled in the partner organization, users in your organization will no longer be able to access information shared from the partner organization. Users in the partner organization will continue to be able to access information shared from your organization.

We have a Sharing Policy with a Wildcard in the domain. Do we need to migrate it?
Yes, as long as the CalendarSharingFreeBusy access level is Simple, Detail, or Reviewer.

Our default Sharing Policy is defined (with a "{*:0}" wildcard domain) but is set to Enabled:False. This is because we want to prevent users from external calendar sharing. Do we need to migrate this policy?
No action is needed. No Cross-Tenant Access Policy will have an equivalent effect to default Sharing Policy being disabled.

What if we are sharing with multiple domains that are in the same partner Tenant ID?
Create a single Microsoft 365 Cross-Tenant Access Policy to configure sharing with the partner Tenant ID. Any domains associated with the partner Tenant ID will be covered by the policy.

What if we have an Availability Address Space with Google Workspace for Google/Exchange Calendar Interop?
You are not affected by this change. Users in Exchange Online can continue to access calendar information of users in Google Workspace via the Availability Address Space configuration. Users in Google Workspace can continue to access calendar information of users in Exchange Online via Microsoft Graph API. Ensure Google Workspace is configured to connect to Exchange Online via Microsoft Graph API and not the legacy EWS connection method. See: Allow Google Calendar users to see Exchange availability

What if we have an Availability Address Space configuration for sharing Free/Busy between commercial cloud (most customers world-wide) and 21Vianet cloud?
Availability Address Space (with AccessMethod OrgWideFBToken) does not depend on Exchange Web Services and is not impacted by EWS deprecation. However, you may still wish to migrate these configurations to Microsoft 365 Cross-Tenant Access Policy, which supports additional security features and more granular configuration options.

Does managing Microsoft 365 Cross-Tenant Access Policy require Microsoft Graph beta endpoints or Graph PowerShell SDK beta modules?
No. Microsoft 365 Cross-Tenant Access Policy management APIs are now available in Microsoft Graph v1.0 and can be configured using the non-beta Microsoft Graph PowerShell SDK modules starting with version 2.40.

Major updates to this blog post:

10/20/2026: Updated the availability date of Calendar Sharing in the table.
9/29/2026: Added a table to call out the availability for Calendar Sharing functionality.
9/29/2026: Added a table to confirm the availability for MailTips functionality.
9/16/2026: Updated the table to reflect later availability of Free/Busy sharing. Added the FAQ reflecting that beta endpoint or PS modules are no longer required.
9/11/2026: Added a banner to the blog post
9/3/2026: Removed a redundant section of the article.
8/28/2026: Various updates to the post; timeline changes, several clarifications made.
8/18/2026: Modified the FAQ related to AAS sharing with the 21Vianet cloud.
8/10/2026: Added a FAQ that clarifies that default sharing policy that is set to be disabled does not need migration.

The Exchange Online EWS Deprecation Team