Skip to content

MC1540345: Move Exchange Admin API apps by 30 November

MC1540345 (published 5 November 2026) says apps that call the Exchange Online Admin API with the Exchange.ManageV2 or Exchange.ManageAsAppV2 permissions must "Complete migration by November 30, 2026", because "Existing permissions are deprecated December 1, 2026." App owners, Exchange admins and MSPs whose tools, scripts or third-party products use the Admin API need to grant the new permissions, test, and then remove the old ones.

Updated 9 November 2026

Added one line under Do this for multi-tenant apps: admin consent is per tenant, so MSPs and vendors need consent for the new permission in every customer tenant (Microsoft Learn: grant tenant-wide admin consent). Dates and permissions are unchanged.

Runbook card

What changes: Exchange.ManageV2 (delegated) is replaced by Exchange.AdminAPI.Manage, and Exchange.ManageAsAppV2 (application) by Exchange.AdminAPI.ManageAsApp. The Admin API v2.0 endpoint URLs, API version and operations do not change.
Who: owners of apps, scripts and third-party tools that call the Exchange Online Admin API v2.0; Entra admins who grant consent.
By when: migrate by 30 November 2026; the old permissions are deprecated on 1 December 2026. GCC, GCC High and DoD: "existing permissions deprecated January 1, 2027".
Do this: 1. List the apps that hold Exchange.ManageV2 or Exchange.ManageAsAppV2. 2. Add the matching new permission, grant admin consent and confirm the Exchange RBAC roles. 3. Test, then remove the old permission; ask vendors whether their product needs an update. Multi-tenant apps (MSP tools, vendor products): admin consent is granted per tenant, so the new permission needs an admin's consent in every customer tenant.
Check: Entra admin center > Entra ID > Enterprise apps > the app > Security > Permissions, or the read-only Graph PowerShell below.
Source: MC1540345 (published 5 November 2026).

What Microsoft says

MC1540345 is titled "Action required: Update permissions for Exchange Online Admin API" and is tagged "Major change", "Admin impact" and "Retirement". The dates in the post:

  • "New permissions become available November 1, 2026."
  • "Complete migration by November 30, 2026."
  • "Existing permissions are deprecated December 1, 2026."
  • "GCC, GCC High, DoD: Rollout begins in November 2026, with existing permissions deprecated January 1, 2027."
Old permission Type New permission
Exchange.ManageV2 Delegated Exchange.AdminAPI.Manage
Exchange.ManageAsAppV2 Application Exchange.AdminAPI.ManageAsApp

Microsoft's steps, in order: identify affected applications, configure the new permissions, grant administrator consent, verify the Exchange RBAC assignments, "Test affected workflows using the new permissions before removing the existing permissions", remove the retired permissions, update any configuration, script or consent workflow that names them, and "Contact your application provider to determine whether an update is required."

The post names only these two permissions and the Admin API v2.0. It does not mention Exchange Online PowerShell. Microsoft Learn describes the Admin API as "currently in Preview" and says it "isn't a replacement for Exchange Online PowerShell" (Exchange Online Admin API overview). So leave other Exchange permissions, such as the Exchange.ManageAsApp permission used for app-only PowerShell, alone unless Microsoft announces a change for them.

MC1540345 says applications that rely only on the retired permissions after the deprecation date will no longer be able to access the APIs. What Microsoft hasn't said: which error those apps will get, or whether there is any grace period.

How to check (read-only)

Our method, not from Microsoft's post: the Exchange permissions live on the Office 365 Exchange Online service principal (app ID 00000002-0000-0ff1-ce00-000000000000). With Microsoft Graph PowerShell and read-only scopes:

Connect-MgGraph -Scopes "Application.Read.All","DelegatedPermissionGrant.Read.All"
$exo = Get-MgServicePrincipal -Filter "appId eq '00000002-0000-0ff1-ce00-000000000000'"

# Are the new permissions published in your tenant yet?
$exo.AppRoles | Where-Object Value -like 'Exchange.AdminAPI*' | Select-Object Value, Id
$exo.Oauth2PermissionScopes | Where-Object Value -like 'Exchange.AdminAPI*' | Select-Object Value, Id

# Apps with the old application permission (Exchange.ManageAsAppV2)
$old = $exo.AppRoles | Where-Object Value -eq 'Exchange.ManageAsAppV2'
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $exo.Id -All |
  Where-Object AppRoleId -in $old.Id |
  Select-Object PrincipalDisplayName, PrincipalId, CreatedDateTime

# Apps with the old delegated permission (Exchange.ManageV2)
Get-MgOauth2PermissionGrant -Filter "resourceId eq '$($exo.Id)'" -All |
  Where-Object { ($_.Scope -split ' ') -contains 'Exchange.ManageV2' } |
  Select-Object ClientId, ConsentType, PrincipalId, Scope

ClientId is the object ID of the app's service principal: look it up with Get-MgServicePrincipal -ServicePrincipalId <ClientId>. These queries show consented permissions. An app registration that requests the old permission but was never consented shows up only under App registrations > the app > API permissions.

Treat the list as a review, too: every app on it can administer parts of Exchange Online. An app nobody owns is a candidate for removal, not migration. On 5 November Microsoft reported attackers signing in as apps with secrets leaked on GitHub (our brief).

How to verify the fix

  1. Run the queries again: the app now holds Exchange.AdminAPI.Manage or Exchange.AdminAPI.ManageAsApp, with admin consent.
  2. Run the app's normal Admin API calls and confirm they succeed with the new permission alone.
  3. Only then remove the old permission, and run the queries a last time: no app should still hold Exchange.ManageV2 or Exchange.ManageAsAppV2.

Rollback and impact

Adding the new permission does not affect the old one, so test with both in place. If a workflow fails after you remove the old permission before 1 December, add it back, fix the app and try again. After 1 December the old permissions are deprecated and apps that hold only them lose access, so there is nothing to fall back to.

Also changing: MailboxFolderPermission returns a structured User (MC1540342)

MC1540342 (published 5 November 2026), "Action required: Exchange Online Admin API MailboxFolderPermission response update": "Rollout will begin and is expected to complete in early November 2026." The User property in the MailboxFolderPermission response changes from a string to a structured object with DisplayName, Name and PrimarySmtpAddress. "The endpoint URL and API version will not change."

  • Who acts: owners of scripts and tools that read folder permissions through the Admin API, for example calendar and delegate audits.
  • Do this: find code that treats User as a string (comparisons, splits, CSV exports) and read the object's fields instead; test permission listing and changes; ask vendors of mailbox permission tools whether they need an update.
  • Source: MC1540342.

Sources

More: all Email & collaboration news · Microsoft 365 retirement dates and deadlines · Exchange Online Protection Kit.

Last reviewed: 9 November 2026. Runbook Lab is not affiliated with Microsoft.