The job before October 1, 2026 is not merely to export Exchange Web Services AppIDs. Exchange Online administrators should turn Microsoft’s tenant-specific EWS usage reports into an owned, evidence-backed application register, validate every retained dependency, and prepare migrations before Microsoft begins tenant-by-tenant blocking. These instructions apply to Exchange Online and Microsoft 365, not EWS running on Exchange Server.

Dashboard tracking Exchange Online EWS retirement, application inventory, migration status, security metrics, and key dates.Why the October deadline matters​

WindowsForum users tracking the retirement consistently report the same operational problem: discovering an AppID is relatively easy, but determining who owns it, what transaction it performs, and whether it can be retired is much harder. Other WindowsForum reports emphasize that the retirement is phased rather than a single shutdown event, so administrators need both a short-term exception process and a dated migration plan.
Microsoft says it will begin blocking EWS access on October 1, 2026, as part of the retirement that concludes in April 2027 (Microsoft’s EWS retirement announcement).
Microsoft also says that it plans to populate EWSAllowedAppIDs in September 2026 for tenants where customers have not created a list, using EWS applications observed in the tenant. A customer-created list will not be changed by that automated process (Microsoft’s Exchange Online EWS retirement guidance).
That automation is a fallback, not an approval decision. An observed AppID might belong to an abandoned integration, an unapproved vendor product, or an application whose original owner has left.
The inverse is an administrator risk hypothesis that must also be tested: a dependency might not appear in the reports your team has retained. Unless Microsoft documents the applicable observation window and coverage, do not assume that one usage snapshot represents every scheduled or exceptional workflow. Preserve successive reports and test known business transactions.

Build the EWS inventory​

Use the following procedure for every production tenant.
  1. Sign in to the Microsoft 365 admin center with an account permitted to read service communications.
  2. Open Health > Message center.
  3. Find the latest tenant-specific message concerning active Exchange Web Services applications.
  4. Export or record every reported application name and AppID.
  5. Retain the original message or export with its publication date. Do not replace an older report with the newest one.
  6. Compare the reports and create one register row per AppID, not per display name.
  7. Mark every new row Unverified until an owner and business purpose are established.
  8. Store the register in a controlled location with change history.
Use these columns:
  • AppID
  • Reported application name
  • First and last report dates
  • Tenant
  • Service principal object ID
  • Publisher or vendor
  • Authentication pattern, if confirmed
  • Business service
  • Technical owner
  • Business owner
  • Affected mailboxes or users
  • Required EWS workflow
  • Replacement technology
  • Exception decision
  • Exception expiration date
  • Test transaction and result
  • Migration or retirement date
  • Evidence links
  • Last review date
Appearance in Microsoft’s report establishes reported EWS activity; it does not establish authorization, current ownership, or a continuing business requirement.

Correlate each AppID with Microsoft Entra​

Use Microsoft Entra to investigate the identity behind each reported AppID. Portal navigation and available log fields can vary with licensing, permissions, portal updates, and the type of sign-in, so treat the following as an investigation workflow rather than proof of EWS use.
  1. In the Microsoft Entra admin center, locate the tenant’s sign-in logs.
  2. Search the available user and workload-identity sign-in records for the AppID.
  3. Locate the corresponding enterprise application or service principal.
  4. Record the service principal object ID, display name, publisher information, assigned owners, and relevant permissions that are visible to your account.
  5. If your organization owns the application registration, inspect that registration as well.
  6. Save the relevant event IDs, screenshots, or exported records in the register.
  7. Treat Microsoft’s tenant-specific EWS report as the protocol-usage evidence. Entra records are supporting identity and authentication evidence, not standalone confirmation that a particular transaction used EWS.
A Microsoft Graph lookup can help resolve an AppID to a service principal:
Code: 
Connect-MgGraph -Scopes "Application.Read.All"

Get-MgServicePrincipal -Filter "appId eq '<application-id>'" |
 Select-Object DisplayName, AppId, Id, SignInAudience, AppOwnerOrganizationId
Run the lookup in the correct tenant. An empty result is an investigation trigger, not permission to discard the AppID. Confirm the tenant context, search retained records, and ask the application or vendor team how its identity is provisioned.

Apply an evidence standard​

WindowsForum administrators preparing for the retirement have repeatedly stressed inventory and migration rather than blind preservation. Convert that principle into a decision gate: an AppID should become a temporary exception only when its register row answers these questions.
  1. What is it? Identify the product, workload, AppID, service principal, publisher, and tenant.
  2. Who owns it? Name an accountable business owner and a technical contact or vendor escalation route.
  3. Why does it need EWS? Document the actual transaction, not merely the product name.
  4. What breaks if it is blocked? Identify the affected service, mailboxes, schedule, and user-visible failure.
  5. How was it tested? Record a real end-to-end transaction and its expected result.
  6. When will the exception end? Enter a migration, replacement, upgrade, or retirement date.
Classify each row as one of the following:
  • Approved temporary exception: Dependency verified, owners assigned, transaction tested, and exit date approved.
  • Migration candidate: Dependency confirmed, but EWS access is scheduled for removal.
  • Unknown shadow dependency: Activity reported, but no accountable owner or defensible purpose has been found.
  • Retired or unauthorized: Application must not be preserved.
“Seen in the Microsoft report,” “probably Microsoft,” and “the vendor says it is required” are not sufficient approval evidence.

Resolve orphaned and vendor applications​

For an orphaned application, assign interim responsibility to the team that owns the affected business service. Do not make the messaging team the permanent owner merely because the application accesses Exchange.
For a vendor-controlled multi-tenant application:
  1. Match the reported AppID to the enterprise application in your tenant.
  2. Record its publisher and service principal information.
  3. Obtain written vendor confirmation that the AppID belongs to the affected product.
  4. Ask which supported product release removes EWS use.
  5. Obtain the vendor’s migration procedure and delivery date.
  6. Assign an internal business and technical owner.
  7. Treat any replacement AppID as a new identity requiring validation.
For internally managed software, use a concrete search rather than a generic “check legacy systems” request. Search source repositories, deployment variables, configuration-management records, and automation assets for the exact AppID and common EWS endpoint text. For example:
Code: 
Get-ChildItem -Path C:\Automation -Recurse -File -ErrorAction SilentlyContinue |
 Select-String -Pattern '<application-id>','outlook.office365.com/EWS','Exchange.asmx'
Adjust the path to a controlled repository or application directory. Do not indiscriminately scan user profiles or expose secrets in exported results.

Preserve the current Exchange configuration​

Before any approved Exchange Online change, capture the complete organization configuration rather than relying on an unverified hand-selected property list.
Code: 
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline

Get-OrganizationConfig | Export-Clixml ".\ExchangeOrganizationConfig-before.xml"
Get-OrganizationConfig | Format-List * |
 Out-File ".\ExchangeOrganizationConfig-before.txt"
Record the tenant, operator, timestamp, Exchange Online PowerShell module version, change ticket, and file hashes.
Exchange Online documentation currently describes EwsApplicationAccessPolicy, EwsAllowList, and EwsBlockList as organization configuration parameters used by existing EWS application-access policy behavior. Do not assume that those controls are equivalent to the retirement-related EWSAllowedAppIDs mechanism. The supplied retirement information does not establish that the controls can safely be combined, how precedence would work, or that one can validate the other.
Likewise, do not copy a comma-separated Set-OrganizationConfig -EwsAllowedAppIDs example into production unless Microsoft’s current cmdlet documentation for your rollout explicitly documents that parameter, accepted data type, enforcement behavior, and rollback procedure. The feature is associated with a planned 2026 rollout, and pre-release syntax should not be treated as a supported production runbook.

Run a controlled transaction pilot​

A safe pilot does not begin by assuming that setting EWSEnabled=True will enforce a customer-created AppID list. The supplied Microsoft statements establish the planned allow-list population and retirement timeline, but they do not establish enough command semantics to prescribe that tenant-wide enforcement procedure here.
In particular, administrators should not infer that:
  • EWSEnabled=True plus EWSAllowedAppIDs permits only listed callers;
  • Microsoft and non-Microsoft callers will be treated differently during a customer pilot;
  • an empty or absent customer-created list has a safe, predictable result; or
  • undocumented list syntax can be rolled back reliably.
Therefore, use this ordered pilot:
  1. Freeze the proposed exception register for the test window.
  2. Obtain approval from messaging, identity, security, and affected service owners.
  3. Confirm every tested application has a named contact available during the window.
  4. Capture the Exchange organization configuration and application configuration.
  5. Run a normal end-to-end transaction for every proposed exception.
  6. Record the start time, completion time, mailbox or test object, expected result, actual result, and supporting application log.
  7. Repeat the transaction after any vendor upgrade or Graph migration change.
  8. Investigate every failure before approving the AppID.
  9. Request Microsoft support confirmation of the tenant’s EWSAllowedAppIDs availability, supported syntax, prerequisites, caller behavior, and rollback process before attempting enforcement.
  10. Attach Microsoft’s response and the exact approved commands to the change record.
If Microsoft support authorizes changing EwsEnabled, capture its original value in the same session:
Code: 
$Before = Get-OrganizationConfig
$Before.EwsEnabled
The exact rollback for that specific setting is:
Set-OrganizationConfig -EwsEnabled $Before.EwsEnabled
Then verify it:
Get-OrganizationConfig | Format-List EwsEnabled
This restores only the captured EwsEnabled value. It does not restore an AppID list or any separate EWS access policy. Do not perform an EWSAllowedAppIDs enforcement pilot until the current Microsoft documentation or Microsoft support provides the supported list-setting and list-restoration commands for the tenant.

Verify and troubleshoot​

After each application test:
  1. Confirm the business transaction completed, not merely that authentication succeeded.
  2. Check the application’s own job history and error log.
  3. Record the tested mailbox, account, or resource without placing secrets in the register.
  4. Correlate the test time with available Entra records.
  5. Confirm the AppID matches the register.
  6. If the transaction fails, restore only settings changed under the approved change record.
  7. Re-run Get-OrganizationConfig and compare it with the saved baseline.
  8. Repeat the application transaction after rollback.
  9. Escalate unexplained EWS results to Microsoft or the vendor with timestamps, AppID, tenant ID, and sanitized error details.
A successful sign-in is not a successful application test. The acceptance criterion is completion of the business transaction.

Frequently Asked Questions​

Pre-October deliverables​

Before October 1, 2026, each production tenant should have:
  • Retained tenant-specific Message Center reports and their dates
  • One controlled register row for every reported AppID
  • Named business and technical owners for every approved exception
  • An approved temporary exception list
  • A recorded end-to-end transaction test for every retained application
  • A configuration baseline and tested rollback artifact
  • Microsoft-supported commands attached to any enforcement change
  • A migration or retirement date for every temporary exception
  • An investigation decision for every unknown caller
  • A post-change verification and escalation plan
By October 1, the deliverable should be more than a collection of GUIDs. It should be a tested production register in which every retained AppID has evidence, an accountable owner, and an expiration path, while every unknown caller remains an investigation item rather than receiving automatic approval.

References​

  1. Primary source: techcommunity.microsoft.com
  2. Independent coverage: devblogs.microsoft.com
    devblogs.microsoft.com

    Retirement of Exchange Web Services in Exchange Online

    On October 1, 2026, we will start blocking Exchange Web Service requests from non-Microsoft apps to Exchange Online.
    devblogs.microsoft.com
  3. Primary source: WindowsForum
    windowsforum.com

    EWSAllowedAppIDs: Exchange Online EWS Allow List Before Oct 2026 Disablement | Windows Forum

    Microsoft is rolling out EWSAllowedAppIDs in Exchange Online in June 2026 so tenant administrators can restrict remaining Exchange Web Services access to...
    windowsforum.com
 

Click to expand...
You must log in or register to reply here.