Exchange Online Admin API apps must change permissions by 30 November

Exchange Online Admin API apps must change permissions by 30 November

5 November 2026: Microsoft is replacing the two permissions that apps use to call the Exchange Online Admin API v2.0, and any app that still relies only on the old ones after 1 December loses access. The notice gives administrators about three and a half weeks, and it arrives alongside a smaller change that can break scripts on its own.

Not yet independently verified. We have read these notices on an archive of the Microsoft 365 Message Center, not on a Microsoft Learn page. Government cloud dates may be refined in later Message Center posts. We will update this when it can be confirmed, and remove this note.

Old names, new names and the dates

The swap is one for one:

• Exchange.ManageV2 becomes Exchange.AdminAPI.Manage;
• Exchange.ManageAsAppV2 becomes Exchange.AdminAPI.ManageAsApp.

Endpoints, the API version and the operations themselves stay the same, so the code that calls the API should not need rewriting. The work lies in app registrations and consent.

In the worldwide cloud the new permissions have been available since 1 November, migration should be complete by 30 November, and the existing permissions are deprecated on 1 December. GCC, GCC High and DoD tenants start rollout during November and keep the old permissions until 1 January 2027. Microsoft ties the change to the move away from Exchange Web Services.

Where the migration tends to catch people

Microsoft's sequence is to find the affected apps, add the new permission, grant admin consent, check Exchange RBAC roles, test, then remove the old permission and update scripts and consent workflows. Two steps deserve more attention than a list gives them.

Admin consent is the easy one to forget. A new permission on an app registration does nothing until an administrator has consented to it in each tenant, and that means a consent round for an ISV with hundreds of customer tenants.

Third-party tools are the other. Backup, migration, reporting and mail-security products that manage Exchange through this API each hold their own registration, so the tenant's administrators cannot fix them. Microsoft tells customers to ask those vendors directly, and a vendor that has not published a date by mid-November is one to chase.

A response field also changes shape

The second notice, MC1540342, is easy to miss. The MailboxFolderPermission endpoint will return User as an object, with DisplayName, Name and PrimarySmtpAddress, rather than a string. Rollout starts in early November, so it may already be reaching tenants. Any script that compares that field to a string or passes it straight into a report can fail with a parse error, or quietly produce wrong output, without any permission having changed.

Teams working through the permission change can search for that endpoint at the same time. The usual suspects are scheduled PowerShell and in-house tools that audit calendar and shared-mailbox access, because they tend to have no owner until they stop working.

1 December also falls just ahead of many organisations' year-end change freezes, so the practical deadline may be earlier than Microsoft's.

Sources

• Microsoft 365 Message Center MC1540345 (archive at mc.merill.net), 5 November 2026, 5 November 2026
• Microsoft 365 Message Center MC1540342 (archive at mc.merill.net), 5 November 2026, 5 November 2026