Microsoft EWS Retirement: What AvePoint Customers Must Do Before October 1, 2026

This article replaces our earlier August 2026 EWS update. Based on the latest information from Microsoft, our guidance has changed in one important way: Enabling the tenant EWS flag is no longer enough. You must also add the correct application IDs to your tenant's EWS allow list and ensure your AvePoint apps have the required permissions. The prior article's step-by-step remains available in the Update History section at the bottom for reference, but the guidance below supersedes it.

The Issue

To keep working with Exchange Online, AvePoint has moved its products from Microsoft's older Exchange Web Services (EWS) technology to the newer Microsoft Graph API, because Microsoft is retiring EWS.

The problem: Microsoft Graph still has major gaps. It cannot yet handle everything EWS did, specifically:

• Three mailbox types: Archive mailboxes, Microsoft 365 Group mailboxes, and Public Folders. This gap is across all Microsoft 365 tenant types.
• Sovereign / government clouds: Microsoft 365 GCC High, DoD, and 21Vianet. Exchange Graph does not work in these Microsoft 365 tenants.

For anything in that list, AvePoint still has to use EWS behind the scenes; there is no Graph alternative yet. So when Microsoft turns EWS off, that work stops unless you take action to keep EWS available in your tenant.

Two Dates, and What They Mean for You

• October 1, 2026, EWS shutdown begins. Microsoft starts disabling EWS in phases. If you do nothing, your affected workloads can stop working any time after this date.
• April 1, 2027, is the final cutoff, but only relevant if you act and extend EWS in your tenant. By setting the tenant flag and adding your AvePoint app IDs (see below), you extend EWS in your own tenant and keep those workloads running. That extension buys you until April 1, 2027, when Microsoft removes EWS for good and no configuration can extend it further.

In short: Extending EWS is not optional if you want to keep these workloads running past October. Doing nothing means October is your deadline; extending moves your deadline to April 1, 2027.

Am I Affected?

Whether you are a direct customer in AOS (AvePoint Online Services) or a partner in Elements, you are affected if you use any of these AvePoint products with Exchange Online:

• Cloud Backup for Microsoft 365: including backup of Archive, Microsoft 365 Group, and Public Folder mailboxes, which continue to rely on EWS. We recommend all backup customers extend EWS due to the three mailbox type limitations.

• Migration (Fly and Fly Server): Exchange migration work that runs on EWS. We recommend all migration customers extend EWS due to limitations in migrating Calendars (Graph cannot suppress calendar invites) and the three mailbox type limitations.

• Cloud Governance (limited, see details): For customers who use the classic admin center and have the following requirements for group/team management:

  • Create groups or teams in multiple domains.

  • Set the language of the welcome email Microsoft sends to the group mailbox when provisioning a group/team.

  • Send copies of conversations and events to group/team members' inboxes.

  • Allow users outside your organization to send emails to groups/teams.

If you don't use any of these with Exchange Online, you don't need to take action.

Affected But Still Working? Here's Why You Can't Wait

Microsoft disables EWS in phased waves that may roll out over weeks (potentially longer), consistent with how they deploy any major change. This means your workloads may keep working for a period after October 1 simply because your tenant has not yet been reached in the rollout, not because you are exempt or safe. Do not wait for a failure to act. If you rely on EWS and have not extended it, your workloads will fail once the disablement wave reaches your tenant, and there is no reliable way to predict exactly when that will be. Configure everything now.

What You Need to Do

If you're affected, complete these three actions. Every affected customer completes the same three actions. Within each action, the exact steps depend on whether you use AvePoint hosted apps or your own custom apps.

• Part 1: Enable EWS at the tenant level. The same for everyone.

• Part 2: Add your AvePoint application IDs to the EWS allow list. Hosted apps: use our published ID list. Custom apps: look up your custom app IDs in AOS for Cloud Backup for M365, Fly, and Cloud Governance. Fly Server customers using custom apps can view their custom app IDs within Fly Server (Migration Settings -> Connection Manager) and find their Exchange Connections.

• Part 3: Authorize your apps for the required EWS permissions. Hosted apps: re-authorize in AOS (one click per app). Custom apps: add the required permissions yourself (see the Custom App Permissions tables below), and re-consent the custom app.

Remember: the tenant flag alone is no longer enough. Microsoft will not automatically whitelist pre-existing applications, so you need all three actions. To see this applied end to end, jump to Example Scenarios near the bottom.

If your migrations, Cloud Governance Exchange-related services, or backups are running normally today, they can still fail once the rollout reaches your tenant if you have not completed all three actions. Please act now.

Is There an Easy Button? 

Yes and no; we can explain. If you are not using custom apps, and you do not mind adding application IDs to the EWS allow list that you may not be using (there is no real harm in this), then you can skip everything and jump down to the end of the article and focus on Example Scenario 7: The Easy Button (all AvePoint-hosted app IDs, every environment). 

Part 1: Enable EWS at the Tenant Level (Everyone)

Every affected customer does this step, regardless of which apps you use. In Exchange Online PowerShell, ensure the organization setting is enabled:

Set-OrganizationConfig -EWSEnabled $true

You can verify your current configuration at any time:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Part 2: Add Your Application IDs to the EWS Allow List (Everyone)

Populate EWSAllowedAppIDs at the Exchange Online organization level with the application IDs for the AvePoint products you use. First, get your IDs: 

• AvePoint hosted apps: Use the AvePoint Published Application IDs tables below. Find the row(s) for the products you use and the column for your AOS environment (Commercial, AOS-US, AOS-UG, or 21Vianet). For Cloud Backup for M365 and Cloud Governance affected customers, always include the AOS classic (all permissions) app.
• Custom apps: Look up your IDs in AOS:
  • Sign in to AvePoint Online Services using the URL for your environment:
    • Commercial: avepointonlineservices.com
    • AOS-US: usgov.avepointonlineservices.com
    • AOS-UG: aosusgov.online15.net
  • Go to Management → App management.
  • On the App profile management tab, select the app profile you want to inspect.
  • In the App profile details panel, note the Service field and copy the Application ID. 

Part 3: Authorize Your Apps for the Required EWS Permissions (Everyone)

In February this year, AvePoint added the Exchange Graph permissions required for this transition. Your app must carry those permissions, or your workloads can fail even with the tenant flag and allow list configured. How you do this depends on your app type:

If you use AvePoint hosted apps: Re-authorize in AOS

(Applicable for Cloud Backup for M365 and Fly. Not required for Cloud Governance.)

• Sign in to AvePoint Online Services using the URL for your environment:
  • Commercial: avepointonlineservices.com
  • AOS-US: usgov.avepointonlineservices.com
  • AOS-UG: aosusgov.online15.net
• Go to Management → App management.
• Select the app profile you use, then click Re-authorize and complete the consent prompt.

Re-authorizing is a one-click consent in AOS. This is the key difference from custom apps, where you must add the permissions yourself.

If you use custom apps: Add the required permissions yourself

Because you own the app registration, you must add the required EWS/Graph permissions and grant admin consent. The exact permissions depend on the product, so use the Custom App Permissions tables below. Bear in mind these are NEW permissions you are adding; these are not replacements. This is an append action to your current custom applications. For migration, the permissions also depend on the source and destination of your migration.

AvePoint Published Application IDs (Hosted Apps)

Use these tables to complete Part 2 if you use AvePoint hosted apps. Add the application IDs that correspond to the AvePoint products you use and the environment your tenant runs in. Always include the AOS classic (all permissions) app.

Verification note: You can always confirm these values on your App management page in AOS, which reflects the app registered in your tenant.

For Fly Server customers, please see the table below. Fly Server is a self-hosted application and has no connection to AOS environment. 

If you use the AvePoint Online Services (AOS) classic all-permissions application, include it in your allow list as well because backup and Cloud Governance all rely on it, and AOS uses it for Public Folder scanning. If you are not using the AOS classic (all permissions) app, you don't need to include it in your allowed app ID list.

AOS Commercial

AOS-US

Values are provided by cloud type: GCC High (GCCH) and GCC / Commercial. Use the one matching your M365 tenant.

AOS-UG

Values are provided by cloud type: GCC High (GCCH) and GCC / Commercial. Use the one matching your tenant.

21Vianet (21V)

Fly Server

Values are provided by cloud type: GCC High (GCCH), GCC / Commercial and 21Vianet(21V). Use the one matching your Microsoft 365 tenant(s).

Custom App Permissions (appending to the existing permissions)

Use these tables to complete Part 3 if you use custom apps. Append/add the listed Microsoft Graph permissions to your app registration and grant admin consent. You only need the permissions for the product(s) you use.

Cloud Backup for Microsoft 365

Confirm the values were applied:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Step 3: Re-authorize the hosted apps in AOS

Because these are AvePoint-hosted apps, finish by re-authorizing so they carry the required EWS permissions:

Because these are AvePoint-hosted apps, finish by re-authorizing so they carry the required EWS permissions:

• Sign in to AvePoint Online Services at avepointonlineservices.com (the Commercial URL).

• Go to Management → App management.

• Select each Cloud Backup for M365 app profile, click Re-authorize, and complete the consent prompt (one-click consent per app).

Example Scenario 2: Fly (Exchange Online → Exchange Online and Exchange Online → Gmail) in AOS-US (GCC High), custom apps

Step 1: Run the tenant-level switch

In Exchange Online PowerShell, enable EWS at the organization level:

Set-OrganizationConfig -EWSEnabled $true

(Optional) Verify the setting at any time:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Remember: this flag alone is not enough. You still need Steps 2 and 3.

Step 2: Look up your custom app IDs and add them to the allow list

Because you use custom apps, look up your own Fly app's Application ID in AOS:

• Sign in to AvePoint Online Services at usgov.avepointonlineservices.com (the AOS-US URL).

• Go to Management → App management.

• On the App profile management tab, select your Fly app profile.

• In the App profile details panel, note the Service field and copy the Application ID.

Connect to Exchange Online (if you are not already connected):

Connect-ExchangeOnline

Add your custom Fly app ID to the allow list without overwriting existing values (replace the placeholder with your actual Fly app ID):

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App IDs to add
$newAppIds = "<your-custom-fly-app-id>,c1d4abb8-c953-4199-945d-f6498c1f95a3"
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs "$current,$newAppIds"

Confirm the values were applied:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Step 3: Add the required permissions to your custom app

Because you own the app registration, you must add the Microsoft Graph permissions yourself and grant admin consent. Since you run two migration directions, add all three permission sets below.

Exchange Online → Exchange Online — Source read permissions:

Exchange Online → Exchange Online — Destination read and write permissions:

Exchange Online to Gmail — Source read permissions:

Exchange Online → Gmail — Source read permissions:

After adding all three sets, grant admin consent in your Entra app registration.

Example Scenario 3: Cloud Governance in AOS Commercial (AvePoint-hosted apps)

Before you begin: Confirm whether your classic Cloud Governance services actually rely on EWS — this applies to customers using the classic admin center who need to create groups or teams in multiple domains, set the welcome-email language, send copies of conversations and events to members' inboxes, or allow external users to email groups/teams.

Step 1: Run the tenant-level switch

In Exchange Online PowerShell, enable EWS at the organization level:

Set-OrganizationConfig -EWSEnabled $true

(Optional) Verify the setting at any time:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Remember: this flag alone is not enough. You still need Steps 2 and 3.

Step 2: Add the allowed application IDs

For Cloud Governance in AOS Commercial, add the Cloud Governance for Exchange app ID plus the AOS classic (all permissions) app:

Connect to Exchange Online (if you are not already connected):

Connect-ExchangeOnline

Add them to the allow list without overwriting existing values:

Set-OrganizationConfig -EWSAllowedAppIDs @{Add="ec377498-817e-4ec8-89be-f3917a7a8bdd","8347dcbb-c18a-4a06-ad9d-c4ade6daba43"}

Confirm the values were applied:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Step 3: No re-authorization required for Cloud Governance

Unlike Cloud Backup for Microsoft 365 and Fly, Cloud Governance does not require re-authorization in AOS. Once the tenant flag (Step 1) and the application IDs (Step 2) are in place.

Example Scenario 4: Cloud Backup for M365 in AOS-UG, custom apps

Step 1: Run the tenant-level switch

In Exchange Online PowerShell, enable EWS at the organization level:

Set-OrganizationConfig -EWSEnabled $true

(Optional) Verify the setting at any time:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Remember: this flag alone is not enough. You still need Steps 2 and 3.

Step 2: Look up your custom app IDs and add them to the allow list

Because you use custom apps, look up your own Cloud Backup app's Application ID in AOS:

• Sign in to AvePoint Online Services at aosusgov.online15.net (the AOS-UG URL).

• Go to Management → App management.

• On the App profile management tab, select your Cloud Backup app profile.

• In the App profile details panel, note the Service field and copy the Application ID.

Connect to Exchange Online (if you are not already connected):

Connect-ExchangeOnline

Add your custom Cloud Backup app ID without overwriting existing values (replace the placeholder with your actual values):

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App IDs to add
$newAppIds = "<your-custom-cloud-backup-app-id>"
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs "$current,$newAppIds"

Confirm the values were applied:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Step 3: Add the required permissions to your custom app

Because you own the app registration, you must add the Microsoft Graph permissions yourself and grant admin consent. Cloud Backup does not differentiate read versus read/write, so add the full set:

After adding the permissions, grant admin consent in your Entra app registration.

Example Scenario 5: Fly Server (Exchange Online → Exchange Online, both Microsoft 365 Commercial) and (Gmail → Exchange Online, M365 GCC), custom apps

This customer runs two migrations on Fly Server, and all Exchange connections use custom apps:

• Migration A, Exchange Online → Exchange Online: both the source and destination are M365 Commercial tenants.
• Migration B, Gmail → Exchange Online: the destination is an M365 GCC tenant. (Gmail is not an Exchange Online tenant, so it needs no EWS action.)

Step 1: Run the tenant-level switch

EWS is enabled per Exchange Online tenant, so run the switch on each Exchange Online tenant involved:

• Migration A: Run it on both the source Commercial tenant and the destination Commercial tenant.
• Migration B: Run it on the GCC destination tenant only (there is no switch for the Gmail side).

In Exchange Online PowerShell, for each tenant:

Set-OrganizationConfig -EWSEnabled $true

(Optional) Verify the setting at any time:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Remember: this flag alone is not enough. You still need Steps 2 and 3.

Step 2: Look up your custom app IDs in Fly Server and add them to the allow list

Because Fly Server is self-hosted and has no connection to AOS, look up your custom Exchange app IDs directly in Fly Server:

• Go to Migration Settings → Connection Manager and open the relevant Exchange Migration connection.
• Review the associated App Profile(s) configured for that connection.
• Go to Migration Settings → App Profile, locate the associated app profile(s), and confirm they are configured as custom apps. Review the application details.
• Verify the Application ID and app configuration to confirm this is the custom app being used for the Exchange migration workload.

Then add each custom app ID to the EWSAllowedAppIDs allow list on the tenant(s) where that app connects to Exchange Online:

• Migration A (EXO → EXO, both Commercial): Add the custom app ID(s) to both the source Commercial tenant and the destination Commercial tenant.
• Migration B (Gmail → EXO, GCC): Add the custom app ID to the GCC destination tenant only.

Connect to Exchange Online (repeat per tenant):

Connect-ExchangeOnline

Add your Fly Server custom app ID to the allow list without overwriting existing values:

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App IDs to add
$newAppIds = "<your-fly-server-custom-app-id>"
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs "$current,$newAppIds"

Step 3: Add the required permissions to your custom app

Because you own the app registration, add the Microsoft Graph permissions yourself and grant admin consent. Add the set(s) that match each migration direction.

Migration A, Exchange Online → Exchange Online (both Commercial). Add both the source and destination sets:

Source read permissions:

Destination read and write permissions:

Migration B, Gmail → Exchange Online (GCC destination). Because Gmail is the source (no Exchange/Graph permissions are needed on the Gmail side) and Exchange Online is the destination, add only the destination read and write permissions:

(Migrations A and B share the same destination set, so you only need to add that set once per app.) After adding the permission sets, grant admin consent in your Entra app registration.

Example Scenario 6: MSP (partner) using Elements, managing Cloud Backup for Microsoft 365 across five customers (AvePoint-hosted apps)

You are a managed service provider (partner) who manages your customers’ instances of Cloud Backup for Microsoft 365. You have five customers:

• Customers 1 to 4: M365 Commercial tenants, managed within AOS Commercial.
• Customer 5: managed within AOS-US, with a Microsoft GCC tenant.

Note for MSPs: EWS enablement and the allow list are configured per customer tenant, in each customer’s own Exchange Online. Complete all three actions separately for every customer you manage. The app IDs you add depend on the AOS environment that customer is managed in (AOS Commercial vs. AOS-US) and that customer’s Microsoft 365 cloud type.

Step 1: Run the tenant-level switch (once per customer)

In each customer’s Exchange Online PowerShell, enable EWS at the organization level. Repeat for all five customer tenants:

Set-OrganizationConfig -EWSEnabled $true

(Optional) Verify the setting for a customer at any time:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Remember: this flag alone is not enough. You still need Steps 2 and 3 for each customer.

Step 2: Add the allowed application IDs (per customer, by environment)

Because you use AvePoint-hosted Cloud Backup apps, use the published app IDs. The IDs differ by AOS environment, so use the correct set for each group of customers. Always include the AOS classic (all permissions) app.

Customers 1 to 4, Microsoft 365 Commercial in AOS Commercial. Add these three IDs in each of the four customer tenants:

For each of the four Commercial customers, connect and add the IDs:

Connect-ExchangeOnline

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App IDs to add
$newAppIds = "c21d796d-56a5-4305-a7df-047371fa9fd7,b14c93d6-47fe-4ace-afcd-006fc1fbfabb,8347dcbb-c18a-4a06-ad9d-c4ade6daba43"
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs "$current,$newAppIds"

Customer 5, Microsoft GCC tenant in AOS-US. Use the AOS-US, GCC / Commercial column values. Add these three IDs in that customer’s tenant:

For Customer 5, connect and add the AOS-US IDs:

Connect-ExchangeOnline

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App IDs to add
$newAppIds = "445af094-57b9-47fb-ae7e-1881190dd71c,c52e33dd-7019-4d42-8476-8842b17dac2e,d13856af-0382-4579-bd16-4c9ab7ff0405"
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs "$current,$newAppIds"

Confirm the values were applied (run for each customer):

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Step 3: Re-authorize the hosted apps in AOS (per environment)

Because these are AvePoint-hosted apps, finish by re-authorizing the Cloud Backup app profiles so they carry the required EWS permissions. Re-authorize in the AOS environment that manages each customer:

• Customers 1 to 4 (AOS Commercial): sign in to avepointonlineservices.com, go to Management → App management, select each Cloud Backup for M365 app profile, click Re-authorize, and complete the one-click consent.
• Customer 5 (AOS-US): sign in to usgov.avepointonlineservices.com, go to Management → App management, select the Cloud Backup for M365 app profile, click Re-authorize, and complete the one-click consent.

MSP tip: Track completion per customer across all three steps (flag set, app IDs added, apps re-authorized). A customer is only protected once all three are done in their own tenant. Because Microsoft disables EWS in phased waves, a customer that still works after October 1 may simply not have been reached yet, so do not treat continued operation as confirmation.

Example Scenario 7: The Easy Button (all AvePoint-hosted app IDs, every environment)

This scenario is for the administrator who does not want to think about which AvePoint products they use, which AOS environment they are in, or which mailbox types are affected. If you use only AvePoint-hosted apps (not custom apps), you can run one script that adds every AvePoint-hosted application ID, across all environments (AOS Commercial, AOS-US, AOS-UG, 21Vianet) and Fly Server, to your tenant’s EWS allow list in a single pass.

Is this safe? Yes. Adding an application ID that you do not actually use is harmless. Exchange simply allows an app that will never connect. Whitelisting everything guarantees that whichever AvePoint-hosted product(s) you run are covered, with no lookup required.

When should you NOT use this? If you use custom apps, the easy button does not apply to you, because your custom app IDs are unique to your tenant and are not in the list below. Follow the custom-app steps instead, and add the required permissions to your app.

Step 1: Enable EWS and add every hosted app ID (one script)

In Exchange Online PowerShell, run the following. It connects, enables the tenant flag, reads your current allow list, appends every AvePoint-hosted app ID without overwriting anything already there, and writes it back:

# Connect to Exchange Online (skip if already connected)

Connect-ExchangeOnline

# Enable the EWS tenant flag

Set-OrganizationConfig -EWSEnabled $true

# Read the current allow list

$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)

# ALL AvePoint-hosted App IDs (every product, every AOS environment, plus Fly Server)

$newAppIds = "8347dcbb-c18a-4a06-ad9d-c4ade6daba43,c21d796d-56a5-4305-a7df-047371fa9fd7,b14c93d6-47fe-4ace-afcd-006fc1fbfabb,34be87c0-bd08-47ab-8ecf-38f6340592f3,83043760-a2ba-4185-8611-0e6d94a0905b,ec377498-817e-4ec8-89be-f3917a7a8bdd,c1d4abb8-c953-4199-945d-f6498c1f95a3,d13856af-0382-4579-bd16-4c9ab7ff0405,4fa91893-bb1f-4cfd-bb88-18e7b00b8c1a,445af094-57b9-47fb-ae7e-1881190dd71c,0db11a07-da70-4d27-b205-90688106e3b6,c52e33dd-7019-4d42-8476-8842b17dac2e,9fb80a60-66c4-4c8f-a25d-a244e2f570bc,c64a33b2-e2d4-46f9-a67f-0c48024848f8,d3cb7b35-9bff-476c-bb4b-a4ba146fca02,2ecdce2f-34f7-44e7-84cf-c4c256bdb717,d70ee466-a0aa-4b57-b488-2fbc6e9c4a60,df065b1c-b0f4-492b-bb0b-35a63724049a,709cca68-e157-4d9e-b2aa-00cdf4405b63,46bcfd39-a388-458d-ace1-40c42b432ac6,7ba47328-7958-44b8-9ac5-1e9ba644c161,9b0189ab-b4ed-4a57-84d0-97d9f857fa64,bb6028da-9be8-44bd-89ed-76f92aae0114,af57086e-e3fd-4e47-a504-6c48dc5be563,5439aad5-53a4-4090-8423-699e2c0f1fb4,d4b9d0ea-c4c9-49b3-9ab7-cebd1aee6af4,2554307b-4348-4ada-b341-6400e50a5ccb,bea6b477-8622-4aad-8544-050de1b47e82,2268dddc-704a-4400-afa3-d4a7a9c2828e,cf9258a8-a52b-47df-9d7d-1d9870757a92,8ccdeabe-491d-44d8-b311-16567f9e9aed,a17ecac1-8eed-460e-92db-fb847b0579c0,1855242b-a473-43b8-a579-c17ffc980abb,fd3851f8-5e15-4daf-9a8e-2cb1ed4b76a2,74592f26-4f20-4972-9581-400426c5cd34,1051e7ac-3119-477f-9c35-420b22bfbf13,fe369c7d-bcf3-457b-929e-e2ca439a6517,d76d2b89-b0b2-41a4-9534-3bc1f6769b34,6d5ebe16-e826-4621-b839-d14134299a73,7b898d33-2af2-4137-a1b4-cc67dbb0fe6b,c02e0fe3-c9ce-47f4-b04e-82ad3af3793e,44d3d6d8-eee8-416e-8c86-09cdabc778e9,c15d4987-1af3-4d2e-b277-9c71c4507f5e,ca7ce308-22db-48a6-801d-6c4ae1c65799,abab2369-6eb4-4c00-bd60-9438dc9d6514,4910be2d-606c-4dc3-95a2-feb42ea5615d"

# Write the updated allow list back

Set-OrganizationConfig -EwsAllowedAppIDs "$current,$newAppIds"

That single run covers all 46 AvePoint-hosted application IDs. You do not need to identify your product or environment.

Confirm the values were applied:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs

Step 2: Re-authorize your hosted app(s) in AOS

The script covers Parts 1 and 2 (tenant flag and allow list). You still need to make sure your hosted apps carry the required EWS permissions. Because you may not know exactly which app profiles you have, simply re-authorize every app profile you see:

• Sign in to AvePoint Online Services using the URL for your environment: avepointonlineservices.com (Commercial), usgov.avepointonlineservices.com (AOS-US), or aosusgov.online15.net (AOS-UG).
• Go to Management → App management.
• For each app profile listed, click Re-authorize and complete the one-click consent.

Note: Cloud Governance does not require re-authorization, and Fly Server is self-hosted (no AOS re-authorization). Re-authorizing any Cloud Backup for M365 and Fly profiles you have is what matters here.

That’s it. With the tenant flag on, every hosted app ID whitelisted, and your app profiles re-authorized, your AvePoint-hosted workloads are extended through the EWS retirement window. Remember that April 1, 2027 remains the final cutoff.

Frequently Asked Questions

How do I know if I use hosted apps or custom apps? 

If you use the standard AvePoint applications we provide, you're on the hosted path: pick your IDs from the published tables and re-authorize in AOS. If your organization created its own custom app profiles in AOS (typically to control the permissions granted), you're on the custom path: look up your IDs in AOS and add the required permissions yourself. If you use both, complete the relevant steps for each.

Does the April 1, 2027 date give me an automatic extension? 

No. April 1, 2027 is a hard cutoff and cannot be extended by any configuration. Extending EWS (flag + app IDs) only keeps EWS working during the window between October 1, 2026 and April 1, 2027, and only if you complete all three actions.

My workloads are still running after October 1. Does that mean I'm fine? 

Not necessarily. Microsoft disables EWS in phased waves that roll out over weeks, so your tenant may simply not have been reached yet. Continuing to work shortly after October 1 is not confirmation that you are exempt or correctly configured. Configure everything now rather than waiting for a failure.

I only set the tenant flag, like last time. Isn't that enough? 

Not anymore. Microsoft confirmed it will not auto-allow pre-existing third-party apps. You must complete all three actions: the tenant flag (Part 1), the application ID allow list (Part 2), and app authorization or permissions (Part 3).

What about Archive, Microsoft 365 Group, and Public Folder mailboxes?

These still rely on EWS and receive no special exemption. Completing the three actions is exactly what keeps these workloads running through the retirement window.

What about sovereign or government clouds? 

Microsoft has confirmed the same two dates apply across all environments, with no separately published later schedule. Follow the same guidance and use the environment-specific IDs above.

How do I confirm my settings are correct? 

Run 

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EWSEnabled,EWSAllowedAppIDs 

in Exchange Online PowerShell and confirm the flag is True and your application IDs are present. If you use hosted apps, also confirm your app profile is re-authorized in AOS. If you use custom apps, confirm the required permissions are added and admin-consented.