Check a tenant's EWS posture
Scanning your code tells you what calls EWS. It does not tell you whether EWS is still switched on for the tenant those calls run against. That is a separate question with a separate command, and it is the one that decides what happens on Oct 1, 2026.
The command
Run the Exchange Online cmdlet and pipe it straight in. Nothing is sent anywhere — the tool only parses the text you give it.
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsEnabled, EwsAllowedAppIDs |
deadlinescan tenant
Or save the output first and pass the file:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsEnabled, EwsAllowedAppIDs |
Out-File ews-posture.txt
deadlinescan tenant ews-posture.txt
With no file argument the tool reads standard input until end of input, so pasting into a live terminal works too. Run the cmdlet in an Exchange Online PowerShell session with the permissions your organisation requires; DeadlineScan neither asks for nor holds a credential.
The five verdicts
It reports one of five postures and says what each one means for the dates. Each message below is the exact text the tool prints.
Not configured — EwsEnabled is present but blank
EwsEnabled is not set: Microsoft flips this tenant to disabled starting Oct 1, 2026. Every EWS app here breaks when that wave hits — including Microsoft's own.
This is the tri-state null: the setting exists and has never been decided. Microsoft's own
documentation says it changes this to $false on October 1, 2026 for any tenant that
has not explicitly set $true. An allow list does not rescue this posture —
EwsEnabled has to be set as well.
Enabled without an allow list — True, no app IDs
EwsEnabled is True but no allow list is configured: from Oct 2026, True alone no longer grants access — only allow-listed app IDs can call EWS. Configure EwsAllowedAppIDs now.
Microsoft pre-populates the allow list for customers who have not created one before September 2026, based on each tenant's own EWS usage telemetry. If your read comes back empty, the pre-population either has not reached this tenant or found nothing to add, so treat the list as yours to write. The exact commands.
Enabled with an allow list — True, one or more app IDs
Allow-listed apps keep working until Mar 31, 2027. Apr 1, 2027 is the hard shutdown — no exceptions, no re-enablement. Use the runway to migrate.
This is the best posture available and it is still a countdown. Two things to check while you have it: that every application still calling EWS is actually in the list, including Microsoft first-party applications that appear in your usage reporting, and that the list is read back from the tenant rather than from the change ticket that was supposed to set it.
Disabled — EwsEnabled is False
EWS is already disabled org-wide. Any remaining EWS call sites in code are dead.
The org-level setting overrides per-mailbox EWS settings, so this verdict decides the whole tenant regardless of what the allow list contains. Microsoft's Message Center notice says admins may re-enable during the phased period; after April 1, 2027 there is no re-enablement.
Unknown — the paste could not be read
Could not reliably parse the pasted output. Run: Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs
unknown is a real answer, not a failure. The parser refuses to guess a posture out
of output it cannot read. Four things produce it rather than a confident wrong reading: no
recognizable EwsEnabled line at all; a value that is neither blank nor
True/False; and — only where EwsEnabled reads
True, because that is the one posture the allow list decides — an allow list
whose brace never closes, or one whose braces close over content with no readable app ID in it.
Under False or blank, a mangled allow list changes nothing and is not allowed to
downgrade a clean verdict. A wrong verdict here is worse than no verdict, because both wrong answers — telling
you that you are allow-listed when you are not, or that you are disabled when you are not —
send you somewhere useless.
What it does not do
- It does not connect to Exchange Online, or to anything else. You run the cmdlet; it reads the text.
- It does not change your tenant. The
Set-OrganizationConfigcommands are yours to run, deliberately. - It does not check per-mailbox EWS settings. The verdict is the organisation-level posture, which is the level the retirement acts on.
Sources
- Microsoft
Learn — Prepare for EWS retirement: the tri-state
EwsEnabledsetting, the automatic change to$falseon October 1, 2026, allow-list pre-population before September 2026, and the April 1, 2027 hard deadline. - Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online: the October 2026 and April 2027 timeline.
- Message Center MC1227454 (archive copy): phased disablement from October 1, 2026, re-enablement during the phased period, and no re-enablement after April 1, 2027.
- Message Center MC1447678 (archive copy):
EWSEnabled=TruewithoutEWSAllowedAppIDsno longer permitting unrestricted access, and Microsoft first-party applications needing to be included.