Join us at Microsoft Ignite, booth #1766, Nov 17-19. Schedule time to meet. Meet Us at Microsoft Ignite

April 1, 2025

Microsoft has announced a significant change in how Exchange Web Services (EWS) access is controlled within Exchange Online. The update is set to roll out worldwide this month. It’s a change aimed at providing administrators with more security and control over managing EWS.

While Microsoft is working toward disabling EWS starting in late 2026, the current fix is to take care of logic in the hierarchical structure that gave preference to user settings over the organizational setting. Here’s a simple summary of the before and after:

Old behavior: Previously, if the organization-level EWS setting was disabled (set to False), but a user’s mailbox-level EWS setting was enabled (set to True), that user could still access EWS. This allowed user-level settings to override organization-wide configurations, leading to potential inconsistencies in policy enforcement.

New behavior: With the change, EWS access is only permitted if both the organization-level and user-level EWS settings are enabled (set to True). This means administrators can’t be overridden at the user level. Settings controlled at the organization level ensure consistent and secure management of EWS access across the environment.

Implications for MigrationWiz users: If you use MigrationWiz for migrating Exchange Online, be sure to review and adjust your EWS settings to prevent disruptions. Here’s a handy guide:

  1. Check the organization-level EWS setting by running the following command in Exchange Online PowerShell:
    • Get-OrganizationConfig | fl EWSEnabled
    • If the EWSEnabled flag is empty (the default) or set to True, EWS is enabled at the organization level.
    • If set to False, EWS is disabled organization-wide, which will block EWS access regardless of user-level settings.
  2. To review user-level EWS settings for a specific mailbox, or ensure that users requiring EWS access have it enabled, run:
    • Get-CASMailbox [UserIdentity] | fl EWSEnabled
    • Replace [UserIdentity] with the user’s identifier
  3. If your organization relies on EWS for migration or other services, adjust the settings to enable access at the organization level and at the user level as necessary. The changes by Microsoft provide better administrative control, so you can disable access at the organization level or for specific users.

Action Steps

With this change in administrative control to EWS access, it pays to do a quick review to make sure there are no unintended consequences for your organization. Here are recommended action steps:

  • Audit your current EWS configurations: Review both organization-wide and user-specific EWS settings to understand your current setup.
  • Update policies accordingly: Adjust your EWS settings to either permit or restrict access based on your organization’s needs.
  • Communicate changes: Inform relevant stakeholders and users about the changes to prepare them for any potential impact on workflows involving EWS.

At BitTitan, we’re advocates of a “no surprises” approach to IT management. By proactively managing your EWS settings, you’ll maintain a logical structure in your Exchange Online environments and ensure seamless mailbox migrations.

For more detailed information, refer to Microsoft’s official announcement.

Preparing for EWS Retirement in Exchange Online

Microsoft began phasing out Exchange Web Services (EWS) access in Exchange Online in October 2026, with full retirement scheduled for April 1, 2027. Organizations that rely on EWS for mailbox migrations should review their existing migration workflows and identify potential disruptions before the deadline.

To prepare for the transition, IT teams should identify migrations that still depend on EWS and evaluate supported alternatives. BitTitan now offers Microsoft Graph API mailbox migrations through MigrationWiz, providing another option for eligible Exchange Online migrations. Administrators should review supported workloads, authentication requirements, and migration limitations before switching to a Graph-based approach.

For more information about the upcoming changes and how they may affect your migration plans, review Microsoft’s official EWS retirement announcement

FAQs About EWS and Mailbox Migrations

Why is my MigrationWiz mailbox migration failing even though EWS is enabled?

Exchange Online requires EWS access to be permitted at both the organization and mailbox levels. If either setting blocks access, an EWS-based migration may fail. Administrators should also verify the required application allow list and review the current MigrationWiz migration guide before retrying.

How can I check whether EWS is enabled in Exchange Online?

Administrators can use Exchange Online PowerShell to check organization-level access with Get-OrganizationConfig \| fl EWSEnabled and mailbox-level access with Get-CASMailbox -Identity user@domain.com \| fl EWSEnabled. Review both settings and confirm that the migration application has permission to use EWS.

What is EWSAllowedAppIDs, and why does it matter for MigrationWiz?

EWSAllowedAppIDs is an Exchange Online allow list that controls which applications can access EWS during Microsoft’s retirement transition. EWS-based MigrationWiz projects require the appropriate application ID in the allow list. Missing or incorrect settings can cause connection failures, even when EWS is enabled at the organization and mailbox levels.

When will Microsoft stop supporting EWS for Exchange Online mailbox migrations?

Microsoft began phasing out EWS in October 2026 and plans to permanently disable it in Exchange Online on April 1, 2027. Organizations using EWS-based migrations should review their project requirements and prepare to transition to supported Microsoft Graph-based methods before the retirement deadline.

Can MigrationWiz use Microsoft Graph instead of EWS for mailbox migrations?

Yes. MigrationWiz introduced a generally available Microsoft Graph API mailbox migration project in October 2026. Microsoft Graph supports eligible Exchange Online mailbox migrations, while some workloads, including certain archive, Public Folder, and Microsoft 365 Group scenarios, may still require EWS during the transition. Review the current migration guides before selecting a project type.