“The requested web method is unavailable to this caller or application”
This is an EWS ErrorAccessDenied fault: the endpoint answered, and it
refused the operation for this caller. If it started recently and nothing in your code changed, the
first thing to read is the tenant's EWS posture, not your code.
ErrorAccessDenied
The requested web method is unavailable to this caller or application
Check the tenant first — one command
In an Exchange Online PowerShell session:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsEnabled, EwsAllowedAppIDs
There are three readings that matter, and the difference between them decides what you do next:
EwsEnabledblank — never decided. Microsoft's documentation says it changes this to$falseon October 1, 2026 for any tenant that has not explicitly set$true.EwsEnabled : Truewith an emptyEwsAllowedAppIDs— from October 2026,Trueon its own no longer permits unrestricted EWS access. Only allow-listed application IDs can call EWS.EwsEnabled : False— EWS is off org-wide. Every EWS call in every application in this tenant fails, and no per-mailbox setting overrides it.
You can pipe that output into the free scanner and have the posture read for you: deadlinescan tenant.
Why this is happening now
EWS: tenants that never opted in start getting disabled Oct 1, 2026 (includes Microsoft's own apps); allow-listed apps run until Mar 31, 2027; Apr 1, 2027 is final — no exceptions.
Microsoft Learn's timeline is short and unambiguous: “October 2026: EWS starts to be disabled globally for all organizations” and “April 2027: EWS is fully disabled.” The disablement is phased and tenant-by-tenant rather than a single global switch, which is why one tenant can be failing while another is not.
The scope is wider than third-party software. After the January 2024 Midnight Blizzard incident, Microsoft widened it — “The scope was also widened from third party applications to include all Microsoft applications” — so Microsoft's own applications that still rely on EWS are subject to the same block and have to be allow-listed like anything else.
One honest caveat: this fault string is a documented EWS access-denied error, and it is the shape of error a blocked caller gets. We have not found a Microsoft source that states which exact fault the October 1, 2026 tenant disablement returns, so read this page as “here is what access-denied means and how to check the posture” rather than as a confirmed mapping from that string to the retirement.
What to do right now
If EWS still has to work while you migrate, opt the tenant in and allow-list the applications that call it:
Set-OrganizationConfig -EwsEnabled:$true
Set-OrganizationConfig -EwsAllowedAppIDs "<comma-separated Entra app client IDs>"
Then read it back — from the tenant, not from the change ticket:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsEnabled, EwsAllowedAppIDs
Microsoft's Message Center notice for the enforcement wave is explicit that first-party applications count: “Microsoft first-party applications that continue to rely on EWS must also be included if they appear in your usage reporting.”
Allow-listing buys time and nothing else. Allow-listed applications keep working until March 31, 2027; April 1, 2027 is the hard shutdown, with no exceptions and no re-enablement. The allow list in detail.
Then scan the code
Once the tenant is settled, the question is what still calls EWS. DeadlineScan is a free, MIT-licensed command-line scanner that reads a directory tree and reports the EWS and QuickBooks Online call sites in it, with what each one maps to in Microsoft Graph. It makes no network calls and sends no telemetry, so your code never leaves the machine.
deadlinescan scan ./my-repo
Get the scanner: email hello@deadlinescan.com and you'll get the source and a Windows binary by reply — the public repository is being prepared.
A finding count of zero means no affected call sites were FOUND — not that you're unaffected.
How the scanner works, and what it does not do.
Sources
- Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online: the October 2026 / April 2027 timeline and the widening of scope to all Microsoft applications.
- Microsoft
Learn — Prepare for EWS retirement: the tri-state
EwsEnabledsetting, theSet-OrganizationConfigcommands, and the April 1, 2027 hard deadline. - Microsoft Learn — Control access to EWS in Exchange.
- Message Center MC1447678 (archive copy): enforcement from October 1, 2026, and first-party applications needing to be allow-listed.