Microsoft Is Retiring EWS: What ENow Customers Need to Do

Purpose

Microsoft is retiring Exchange Web Services in Exchange Online. This article explains what happens on the retirement dates, what ENow has already done about it, what you need to do, and what to do if you have not upgraded yet.

The dates

• October 2026 — Microsoft began disabling EWS globally for all organizations, blocking EWS requests from non-Microsoft applications to Exchange Online. For worldwide tenants, an EWS allow list is required from October 10, 2026 (see If you have not upgraded yet).
• April 2027 — EWS is fully disabled.

Two things worth being clear about, because both catch people out:

October was the start of a rollout, not a single switch. Microsoft disables EWS progressively across organizations. If nothing has broken for you yet, that does not mean your tenant is exempt — it means your turn has not come yet.

April 2027 is not your deadline. The rollout that started in October is. By April there is nothing left to migrate, because it will already have stopped working.

This is about Exchange Online only

Worth stating plainly, because hybrid customers reasonably worry about it: the retirement applies to Exchange Online. Exchange Server on-premises is unaffected. Microsoft does not support Graph against on-premises mailboxes, so on-premises monitoring continues to use EWS and will keep doing so.

If you run hybrid, only the Exchange Online side of your monitoring is affected.

What ENow has done

The Exchange Online monitoring tests in the ENow Management System have been migrated from EWS to Microsoft Graph in EMS 8.7. They keep running with EWS disabled in your tenant, and your thresholds, baselines, alert rules and historical latency data are preserved — there is nothing to reconfigure after you upgrade, and no gap in your trend history. The underlying API changed; the measurements did not.

Some tests were renamed

The migration changed what several tests actually do, so their names changed to match:

Was	Now
EWS Logon	Mailbox Sign-In
OWA Logon	OWA Reachability
Collaboration (MAPI Client)	Mailbox Functions

The OWA test changed in substance as well as name: it no longer signs in, reads no mailbox and uses no token, so it now works for customers using a stored MFA token credential. Its latency threshold is correspondingly renamed. Mailbox Sign-In still requires a password.

Read-receipt and RTF sub-tests have been removed.

Test name enums, result types, threshold names, latency keys, alert categories and page URLs are unchanged, so integrations and saved links keep working. It is the display names you will notice.

What you need to do

1. Upgrade to the current GA release

Upgrade the ENow Management System to the current GA release (8.7 or later). The Graph-based tests are included there.

If you are several versions behind, check the upgrade path before you start — a stepped upgrade through an intermediate release may be required rather than going straight to the latest. ENow supports the current GA release and the two releases before it; see ENow Version Support Policy, and Windows Server Compatibility.

2. Re-consent the Exchange Online Tester app registration

After upgrading, the ENow Exchange Online Tester app registration needs to be re-consented so that it is granted the new Microsoft Graph permissions. The upgrade adds the permission requirements; the consent has to be granted in your tenant by an administrator who can grant tenant-wide consent.

This step is required. Without it the tests have the code path but not the permissions, and they will fail once EWS stops answering.

The 8.7 upgrade also adds new permissions to the ENow MS Teams Tester for new Teams monitoring tests. It is not part of the EWS migration, but re-consent it at the same time so the Teams tests do not go red.

The full permission list for both applications, the consent links and troubleshooting steps are in ENow | EMS | OAuth App Registration Consent and Permissions (sign in to the Help Center to view it).

3. Run Verify Credential

In the Admin Console, go to Server > Tuning Policy > Microsoft 365 > Exchange Online and run Verify Credential. This opens the consent prompt if consent is still needed, then confirms the test account is working against the new permissions. A 403 indicates a missing permission and asks you to re-run this check after granting it. If you re-consented the Teams Tester, run Verify Credential for Microsoft Teams as well.

A successful verification is your confirmation that the migration is complete for your environment. Do not treat the upgrade alone as sufficient — run the check. If you granted consent outside the console, the console does not pick it up until you run Verify Credential.

If you have not upgraded yet

There is an interim measure. Microsoft's block applies to applications that are not on your tenant's EWS allow list, so you can keep EWS working for ENow specifically while you schedule the upgrade.

Setting EwsEnabled to $true on its own is no longer enough. Once enforcement applies to your tenant, EWS is allowed only for the applications listed in EwsAllowedAppIDs:

Tenant configuration	Before enforcement	After enforcement
EwsEnabled not set (null)	EWS allowed	Microsoft may set it to False, and then EWS is blocked
EwsEnabled = True, allow list empty	EWS allowed	All EWS blocked
EwsEnabled = True, allow list populated	Listed apps allowed	Only listed apps allowed
EwsEnabled = False	EWS blocked	EWS blocked

For worldwide (commercial) tenants, Microsoft's Message Center notice states that from October 10, 2026, EwsEnabled = True requires a configured allow list. Microsoft may pre-populate the list from EWS usage it observed in your tenant over the previous 60 days. Review the list rather than assuming it is complete.

In Exchange Online PowerShell:

1. Check your current settings (read-only):

Get-OrganizationConfig | Format-List EwsEnabled, EwsAllowedAppIDs

2. Add ENow and enable EWS (changes tenant configuration):

Set-OrganizationConfig -EwsAllowedAppIDs @{Add="1babc55c-ccea-49de-83a0-fa69178cdbc6"} -EwsEnabled $true

The @{Add=...} syntax adds ENow to the existing list without removing other entries. Any other application in your tenant that still needs EWS must also be on the list, or it will be blocked.

3. Confirm the change: run the command from step 1 again and check that 1babc55c-ccea-49de-83a0-fa69178cdbc6 appears in EwsAllowedAppIDs and EwsEnabled is True.

Treat it as a bridge, not a solution — it buys time until the upgrade, and it stops working entirely when EWS is removed in April 2027. After you upgrade, ENow no longer needs the allow-list entry.

Confirming you are ready

1. You are on the current GA release (8.7 or later).
2. The ENow Exchange Online Tester app registration has been re-consented since that upgrade.
3. Verify Credential passes in the Admin Console.

If tests start failing

If Exchange Online tests begin failing during the EWS rollout, work through the three checks above before anything else — in the great majority of cases the missing item is the re-consent in step 2, because an upgrade can complete successfully without it and nothing fails until EWS stops answering.

If you have not upgraded yet and are relying on the allow list, run the read-only check in If you have not upgraded yet and confirm that EwsEnabled is True and ENow's application ID is still listed in EwsAllowedAppIDs.

If all three check out and tests are still failing, open a case and say explicitly that you have completed the Graph migration steps and that Verify Credential passes. That rules out the common cause immediately.

Government and national clouds

The Graph-based Exchange Online tests do not currently cover GCC tenants, and other national clouds are out of scope. If you operate in a government cloud, raise a case to discuss your options rather than assuming the migration path above applies to you.

References

• Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online, for the current retirement timeline.
• Upgrading to EMS 8.7: Prerequisites, and What Changes Afterwards