Skip to content
CloudRunbook logo
Start Here

Exchange Online · Runbook

Exchange Online EWS retirement: readiness runbook

• 12 min read

Exchange Online EWS retirement: what Microsoft's sources say about dates, how to find EWS users in the usage report, and how to allow-list apps.

  • Effort: Depends on how many apps call EWS
  • Risk: Medium
  • Rollback: Partial: allow-list change only

Applies to: Exchange Online

Exchange Online EWS Microsoft Graph Messaging Change
On this page
  1. What changed
  2. Who is affected
  3. Why it matters
  4. Find who uses EWS
  5. Runbook
  6. Org-wide and per-user behaviour
  7. Hybrid: what is and is not settled
  8. Checks
  9. Rollback
  10. Common pitfalls
TL;DR

The Exchange Online EWS retirement is phased in Microsoft’s Message Center posts. MC1469565 gives October 2026 as the start of global disabling and April 2027 as full disablement. Learn warns that the way the EWSEnabled parameter operates changes in October 2026. Message Center post MC1485116 is reported to say that from 10 October 2026, EWSEnabled set to True without an EwsAllowedAppIDs list no longer grants EWS access for affected Worldwide tenants. MC1227454 is reported to say that if no action was taken, Microsoft sets EWSEnabled to False and EWS apps stop working. Do not treat this as a future-dated checklist. Check straight away whether any EWS app is failing, read back the current EWSEnabled value, and check whether EwsAllowedAppIDs is populated and where the entries came from. Then find what calls EWS using the EWS usage report, and move those apps to Microsoft Graph. The EwsAllowedAppIDs allow list is the control Learn describes for restricting EWS to named apps. Microsoft’s 2023 announcement said EWS in Exchange Server is unchanged, so this is an Exchange Online problem.

Source and what to verify

Checked on 2026-10-27. Read the original posts and pages for the exact wording:

Also look up MC1485116, MC1447678 and MC1469960 in your own tenant’s Message Center. MC1485116 is the post behind the EWSEnabled statement above, and the other two are reported to cover the same ground. This page links no copy of them, so read the original wording there.

Confirm where things stand in your own tenant’s Message Center, EWS usage data and sign-in logs before acting. Some mechanics are not spelled out in Microsoft’s published material (see below).

What changed

Microsoft is retiring Exchange Web Services (EWS) in Exchange Online. The sources give these dates and behaviours, each attributed:

  • MC1469565 gives October 2026 as the start of global disabling and April 2027 as the point of full disablement. The mirror lists it as published 2026-09-09, updated 2026-10-19, with an action-required-by date of 2026-10-01.
  • MC1227454 says that after 1 April 2027, EWS access in Exchange Online will be permanently removed with no re-enablement. The mirror words it as “After April 1, 2027”, so read the cut-off as the end of 1 April, not the start.
  • MC1227454 is also reported to list end of August 2026 as the recommended deadline to configure an AppID allow list and set EWSEnabled to True if you need EWS after October 2026. It is reported to say that if no action is taken, Microsoft sets EWSEnabled to False and EWS apps stop working.
  • MC1485116 is reported to say that from 10 October 2026, for affected Worldwide tenants, EWSEnabled set to True without an EwsAllowedAppIDs list no longer grants EWS access, and that the allow list becomes required when EWSEnabled is True.
  • MC1469565 also describes a Purview Data Lifecycle Management change: Graph API support for archive mailboxes, with global rollout listed as late October 2026 to early November 2026.
  • Learn warns that the way the EWSEnabled parameter operates will change in October 2026 because of the EWS deprecation. The Learn page was last updated 2026-10-07. Read the page itself for the exact wording.
  • Microsoft’s 2023 developer blog post gave 1 October 2026 as the date it would start blocking EWS requests from non-Microsoft apps. Treat that as background. It has since been superseded by the phased timeline in the Message Center posts above.

The two main Message Center posts word the end date slightly differently (“by April 2027” versus “after April 1, 2027”). Check the wording in your tenant’s Message Center and plan to be finished well before either.

Check your tenant’s Message Center, the EWS usage report and your sign-in logs to see whether apps are failing. Do not rely on a date alone. Where the allow-list deadline and the 10 October 2026 date apply to your tenant, check now whether EwsAllowedAppIDs is populated and whether EWSEnabled is still True.

MC1227454 also says tenant admins can re-enable EWS before the permanent removal. Microsoft’s published material does not confirm the exact mechanism for that temporary unblock, or how long it lasts. Microsoft has a Tech Community article titled “Exchange Online EWS application stopped working? Do this.” that may cover it. Read it yourself, and treat any temporary unblock as a stopgap, not a plan.

Because Learn warns that EWSEnabled behaviour changes in October 2026, do not rely on older descriptions of how the setting works. Read the Learn page and the Message Center posts in your tenant that cover it, and read back the current EWSEnabled and EwsAllowedAppIDs values before you change anything. Microsoft’s published material also does not say whether the allow list keeps working after April 2027. Test in a non-production tenant if you can, and ask Microsoft.

Who is affected

  • Anyone whose apps, scripts or third-party tools call EWS in Exchange Online.
  • MC1469565 specifically names organisations using EWS to reach archive mailbox content. That includes eDiscovery, compliance and records management, data lifecycle management, and backup and export tools.
  • Hybrid organisations. See the hybrid section below, because the picture is not settled.

Why it matters

  • Blocked requests: Learn says blocked EWS requests return HTTP 403 with an X-EWS-Policy-Reason header. Expect support calls from whoever owns the affected apps.
  • Vendor lead times: MC1469565 tells you to ask third-party vendors for their migration plans and timelines. Their answers set your deadline.
  • Microsoft apps and exemptions: the 2023 developer blog scoped its October 2026 block to non-Microsoft apps. MC1227454 mentions no exemption, and the EWS usage report page says Microsoft updates its own apps to remove EWS dependencies. Do not assume an exemption covers your tooling. Check the current Message Center wording.
  • Slow feedback: the usage report can take up to 10 days to show data, and allow-list changes can take up to 24 hours. Leave time.

Find who uses EWS

Learn gives this path to the report: Microsoft 365 admin center > Reports > Usage, then under Reports select Exchange, then the EWS usage tab. If Reports is not visible, select Show all first.

What Learn says about the report:

  • Data is aggregated weekly and can take up to 10 days to appear.
  • You can filter to the last 7, 30 or 90 days.
  • The details table has four fixed columns: Application ID (Entra), SOAP Action, Call Volume and Last Activity date (UTC).
  • Export produces a .csv of all users’ usage data. Learn describes no published script for the report.
  • The roles needed to view it are in the “Before you begin” section of the Microsoft 365 admin center usage reports overview. Check that page for your role.

For application IDs the report does not map to a name, Learn points to the Microsoft first-party app list or Entra Enterprise applications.

Runbook

  1. Record the dates and check for failures

    Open MC1469565, MC1227454 and MC1485116 in your tenant’s Message Center. Note the dates as written there, and any difference from the mirrors above. Put them in the change record with the date you checked. Then ask your helpdesk and app owners whether any EWS-based app has stopped working, and look for HTTP 403 responses (see the block step below). Check the current EWSEnabled value in your organisation config and whether EwsAllowedAppIDs is populated (see the allow list step below), and record both.

  2. Export the usage data

    In the Microsoft 365 admin center, open the EWS usage tab as described above. Filter to 90 days and select Export. Because of the 10-day lag, re-export a few times so you catch weekly and monthly jobs.

  3. Map application IDs to owners

    Look up each Application ID in the Microsoft first-party app list or in Entra Enterprise applications. Group by app, then by SOAP Action. Assign an owner to each. Anything with no owner needs a decision: allow-list it or let it be blocked.

  4. Check the archive mailbox consumers

    Ask whether any eDiscovery, compliance, records, lifecycle, backup or export tool reads archive mailbox content through EWS. MC1469565 says to update those applications to Microsoft Graph APIs for archive mailbox operations.

    Be careful with what you build on. The Learn mailboxFolder page covering this is the Graph beta reference, and Learn says beta APIs are subject to change and not supported in production. It shows a parentMailboxUrl property that routes to the mailbox where a folder physically lives, which matters when auto-expanding archiving is on because archive content can span several mailboxes. Microsoft’s published material does not state the v1.0 status or permission scopes for archive access. Check the current Graph reference before committing a design.

  5. Ask vendors

    For each third-party tool, ask for their Graph migration plan and timeline, in writing. This is an action MC1469565 lists.

  6. Review hybrid dependencies

    If you run Exchange hybrid, read the hybrid section below and list what depends on EWS-named endpoints.

  7. Build the app ID allow list for apps you still need

    Learn describes EwsAllowedAppIDs on Set-OrganizationConfig. You give it a comma-separated list of Entra application ID GUIDs. Learn says that when EWSEnabled is True, only those application IDs can use EWS, and it also warns that the way EWSEnabled operates changes in October 2026. MC1485116 is reported to say that True without a list no longer grants access for affected Worldwide tenants, so do not leave the list empty. Check the exact syntax in the Set-OrganizationConfig reference linked above before you run it.

    First, read back what is set. Learn says you must use the -RetrieveEwsOperationAccessPolicy switch to see the list:

    POWERSHELL
    Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

    Then:

    • Build the list from the owners you confirmed in the usage data, not from every ID in the export.
    • Learn says EwsAllowedAppIDs and the user-agent EwsAllowList/EwsBlockList are both evaluated and both must pass. If you use EnforceAllowList, required user agents such as the Teams Calendar agent must stay in EwsAllowList. Learn also has a note on the Teams app ID cc15fd57-2c6c-4117-a88c-83b1d56b4bbe. Read it before you build the list.
    • Learn says changes can take up to 24 hours to take effect because of caching. Do not judge the result sooner.
    • The Set-OrganizationConfig reference does not name the role needed to run it. It points to Learn’s guidance on finding the permissions required for any Exchange cmdlet. Confirm the role group in your tenant before the change window, for example by checking which roles hold the cmdlet.

  8. Know what a block looks like

    Learn says blocked EWS requests return HTTP 403 with an X-EWS-Policy-Reason header:

    • “EWS is disabled for this user or tenant” means EwsEnabled is off.
    • “EWS is blocked by policy for this user or tenant” covers both app ID and User-Agent blocks, and the message does not say which. Check both lists.

    Put these strings in your helpdesk notes.

  9. Move the apps to Graph, then tighten

    As each app is migrated, remove it from the allow list. Track the list shrinking to nothing as the progress measure.

Org-wide and per-user behaviour

Learn says disabling EWS org-wide with EwsEnabled set to $false also disables per-user EWS overrides. Enabling EWS on a mailbox does not override org-wide disablement. So per-user exceptions will not rescue you after an org-wide off switch.

Learn’s page also describes a null org value as treated as True. That description is qualified by Learn’s own warning that the way EWSEnabled operates changes in October 2026, and by MC1485116, which is reported to say that True without an EwsAllowedAppIDs list no longer grants EWS access for affected Worldwide tenants. Do not assume a null or True org value alone keeps EWS working. Read the current Learn page, check your tenant’s Message Center, and read back the live values.

Hybrid: what is and is not settled

The Learn Hybrid Agent page shows several EWS dependencies:

  • Message tracking and multi-mailbox search do not traverse the Hybrid Agent. They need the classic model, with EWS and Autodiscover published on-premises and reachable externally from Exchange Online.
  • The Hybrid Configuration wizard sets the organisation relationship TargetSharingEPR to an agent URL ending in /EWS/Exchange.asmx, and the migration endpoint is named “Hybrid Migration Endpoint - EWS (Default Web Site)”. Free/busy and mailbox moves therefore use EWS-named endpoints.
  • Mailbox migrations need the MRS proxy enabled on the on-premises EWS virtual directory. Learn gives this command:
POWERSHELL
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true
  • Hybrid Modern Authentication is not supported with the Hybrid Agent. It needs the classic hybrid topology with the Autodiscover, EWS, ActiveSync, MAPI and OAB endpoints published. Teams calendaring features that need on-premises mailboxes also call for classic hybrid.

That page does not discuss the EWS deprecation at all. Microsoft’s published material does not say what changes for free/busy, mailbox moves or cross-premises access between October 2026 and April 2027. Do not assume these flows are unaffected, and do not assume they break. Ask Microsoft, and check your Message Center for hybrid-specific posts.

Checks

  • Dates from MC1469565, MC1227454 and MC1485116 are recorded from your tenant's Message Center, with the date you checked.

  • Helpdesk and app owners have been asked whether any EWS-based app has stopped working, and 403 responses have been looked for.

  • The current EWSEnabled value and the EwsAllowedAppIDs list are recorded in the change record, with a note of where any entries came from, and the Message Center posts on the October 2026 EWSEnabled change have been read.

  • EWS usage report exported for 90 days, and repeated after the 10-day reporting lag.

  • Every Application ID in the export has a named owner or a decision to block.

  • Archive mailbox tools (eDiscovery, backup, export, records) are identified, with a Graph plan or a vendor answer.

  • Third-party vendors have given written migration timelines.

  • Current allow list read back with -RetrieveEwsOperationAccessPolicy and saved to the change record.

  • Hybrid dependencies (free/busy, MRS moves, message tracking, multi-mailbox search) listed, with a question raised with Microsoft.

  • Helpdesk know the two X-EWS-Policy-Reason messages.

  • No production build depends on a Graph beta endpoint.

Rollback

Rollback here is partial. It covers the allow-list change only. The retirement itself is not reversible: MC1227454 says that after 1 April 2027, EWS access will be permanently removed with no re-enablement.

  • Allow list too tight: Learn’s Set-OrganizationConfig reference says to remove the application ID restriction by using the value $null for EwsAllowedAppIDs. Allow up to 24 hours for caching before you retest. Given the MC1485116 statement above, check in your Message Center what an empty list means for your tenant before you rely on this.
  • Temporary unblock: MC1227454 says tenant admins can re-enable EWS before the permanent removal, and that after 1 April 2027 there is no re-enablement. The mechanism for the temporary unblock is not confirmed in Microsoft’s published material. Find it in the Tech Community article above or from Microsoft before you need it.
  • Graph migration: keep the EWS version of an app in place until the Graph version is proven, for as long as EWS access is available to you.

Common pitfalls

  • Relying on older EWSEnabled guidance. Learn warns that the way EWSEnabled operates changes in October 2026, and MC1485116 is reported to say True without an allow list no longer grants access for affected Worldwide tenants. Read the current Learn page and your tenant’s Message Center, and read back the live values before you change anything.
  • Treating one date as the date. The sources give a phased window with slightly different wording. Plan against the earliest.
  • Trusting the report too soon. It can take up to 10 days to show usage, so a quiet week proves little.
  • Forgetting archive mailboxes. Compliance and backup tooling is easy to miss and is called out in MC1469565.
  • Building on beta Graph APIs. Learn says beta is not supported in production.
  • Forgetting the user-agent lists. App ID and User-Agent rules must both pass, and Learn says required user agents such as the Teams Calendar agent must stay in EwsAllowList if you use EnforceAllowList.
  • Reading a 403 as one cause. “Blocked by policy” covers both app ID and User-Agent blocks.
  • Assuming per-user overrides help. They do not override org-wide disablement.
  • Assuming hybrid is fine. Microsoft’s Hybrid Agent page does not say so. Ask.