Impact and Solutions for the Retirement of the ApplicationImpersonation Role in Exchange Online
If you use service accounts to migrate mailboxes, the ApplicationImpersonation role is required, while Microsoft has announced the retirement of this role in Exchange Online. Refer to the following sections for the impact and solutions for the retirement of the Application Impersonation role.
Impact in Mailbox Migrations
If you use the service account authentication in mailbox migrations, note the following:
- Migrations from/to user/resource/shared/archive mailboxes will fail.
- If the service account is not the owner of the destination Microsoft 365 Group mailbox, items in the source Inbox folder cannot be overwritten.
How to Check which Accounts have been Assigned the ApplicationImpersonation Role?
To check which accounts have been assigned the ApplicationImpersonation role, open Windows PowerShell and enter the following commands in the Windows PowerShell window:
Get-ManagementRoleAssignment -Role ApplicationImpersonation -GetEffectiveUsers
Service accounts with the ApplicationImpersonation role assigned will be listed in the EffectiveUserName field as the screenshot shown below.
How to Migrate Mailboxes without the ApplicationImpersonation Role?
Fly provides three options to migrate mailboxes without the ApplicationImpersonation role. Refer to the following instructions for details.
- **Option 1**: If you want to use a service account or delegated app profile for mailbox migrations, grant the service account or the consent user of the delegated app profile the **Full Access** permission to all mailboxes you want to migrate.
- > ***Note**: In this case, Group mailboxes cannot be migrated.
- **Option 2**: Use a Fly app profile or custom app profile in the Exchange Online connection for the migration.
- **Option 3**: Create a custom app profile and assign required permissions other than the **full_access_as_app** permission to the app. Then, create an RBAC assignment for the app to only access to specified mailboxes. Refer to the following steps for details:
> ***Note**: This method is unavailable for delegated app profiles.
1. Before creating an RBAC assignment for an app, you can navigate to **Microsoft Entra admin center** > **Applications** > **Enterprise applications** to get the object ID, application ID, or name of the app. The information will be used later.
2. Connect to your Exchange Online environment using Windows PowerShell. Refer to for details.
3. Open Windows PowerShell and enter the following command to create a new resource scope (Optional):
New-ManagementScope -Name <scope name> -RecipientRestrictionFilter <filter query>
Enter a scope name as the attribute value of **Name** and a scope filter as the attribute value of **RecipientRestrictionFilter**. Then, press **Enter** on the keyboard.
4. Enter the following command to create a pointer to a Microsoft Entra service principal:
New-ServicePrincipal -AppId <Client Application ID in AAD> -ObjectId <Service principal object ID in AAD> -DisplayName <name>
Enter the client application ID as the attribute of **AppId**, the service principal object ID as the attribute value of **ObjectId**, and define a name for the service principal as the attribute value of **DisplayName**. Then, press **Enter** on the keyboard.
5. Enter the following command to select the appropriate application role:
New-ManagementRoleAssignment [[-Name] ] -Role -App <ObjectID, AppID, or DisplayName> -CustomResourceScope (or -RecipientAdministrativeUnitScope)
Enter a name for the role assignment as the attribute value of **Name**, the **Application** **EWS.AccessAsApp** as the attribute value of **Role**, the object ID, app ID, or display name of the newly created service principal as the attribute value of **App**, and a scope name as the attribute value of **CustomResourceScope**. Then, press **Enter** on the keyboard.
1. Enter the following command to Test the New Service Principal:
Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource]
Enter the object ID, app ID, or display name of the newly created service principal as the attribute value of **Identify** and the email address of a mailbox as the attribute value of **Resource** to test if the app can access the mailbox. Then, press **Enter** on the keyboard.
For more details, refer to .
If you choose the option **2** or **3** above for the migration, you also need to choose one of the following options to ensure the Exchange PowerShell is available. Otherwise, functions in Fly will be unavailable. Refer to [Working with Exchange PowerShell](#missing-link) for details.
- Assign the **Exchange** **Administrator** role to the app, refer to [How to Assign the Exchange Administrator Role to an App?](#missing-link) for details.
- Add custom roles to the app, refer to [How to Add Custom Roles to an App?](#missing-link) for details.
