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 the question that decides what happens on Oct 1, 2026.
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs | deadlinescan tenant
Nothing is sent anywhere — the tool only parses the text you give it. With no file argument it reads standard input until end of input, so pasting into a live terminal works; or save the cmdlet output first and pass the file: deadlinescan tenant ews-posture.txt. 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
Each message below is the exact text the tool prints.
Not configured
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.
The tri-state null: the setting exists and has never been decided. An allow list does not rescue this posture — EwsEnabled has to be set as well.
Enabled without an allow list
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, from each tenant's own usage telemetry. An empty read means treat the list as yours to write. The exact commands.
Enabled with an allow list
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.
The best posture available, and still a countdown. Check that every application still calling EWS is in the list — Microsoft first-party applications included — and that the list is read back from the tenant rather than from the change ticket.
Disabled
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 decides the whole tenant regardless of the allow list. Admins may re-enable during the phased period; after April 1, 2027 there is no re-enablement.
Unknown
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, because a wrong verdict is worse than no verdict — both wrong answers send you somewhere useless. Four things produce it:
- 01No recognizable
EwsEnabledline at all. - 02A value that is neither blank nor
True/False. - 03Under
EwsEnabled: Trueonly — an allow list whose brace never closes. - 04Under
EwsEnabled: Trueonly — an allow list 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.
What it does not do
- No networkIt does not connect to Exchange Online, or to anything else. You run the cmdlet; it reads the text.
- No writesIt does not change your tenant. The
Set-OrganizationConfigcommands are yours to run, deliberately. - Org levelIt does not check per-mailbox EWS settings. The verdict is the organisation-level posture, which is the level the retirement acts on.
Get the scanner: email [email protected] and you'll get the source and a Windows binary by reply — the public repository is being prepared.