← NAOAT News

Exchange Online guidance separates temporary EWS recovery from migration

Microsoft’s October 21 instructions offer tenant administrators a recovery path while retaining the April 2027 deadline.

Conceptual illustration of software maintenance and protected computing infrastructure
AI-generated illustration. Conceptual image; not a photograph of the reported event.

Microsoft has published instructions for Exchange Online applications disrupted by Exchange Web Services disablement. Its October 21 guidance directs tenant administrators to confirm the change in Message Center, then use Baseline Security Mode or Exchange Online PowerShell to restore access temporarily.

The company says enabling EWS usually takes less than an hour but can take four; changes to the application allowlist take 24 hours. Re-enabling stops working in April 2027. Microsoft directs customers to obtain application versions that no longer use EWS, or change their own application code.

NAOAT analysis

The immediate business question is which workflow stopped, rather than which email client a user prefers. A calendar integration, backup process or internal application can have a different owner from the mailbox it accesses. Incident records should connect the affected workflow to its application, responsible team and vendor contact. That gives the migration effort a usable starting point after service is restored.

Temporary access should have an explicit exit plan. Each exception can record the replacement approach, a test owner and a target date for removing the dependency. Otherwise, a successful recovery may close the support ticket while leaving the underlying migration without a responsible person. The person who approves short-term continuity should be able to see how the longer-term work will finish.

Testing should follow real business tasks through the proposed replacement: a meeting update, an attachment transfer or a scheduled synchronization, for example. A login check alone does not establish that an integration still does its job. Teams should also distinguish expected configuration propagation time from a failed change, documenting when a setting was applied and when the workflow was retested. That record makes troubleshooting more disciplined and helps prevent repeated configuration changes from obscuring the result.