M365 Mailbox and Archive Migrations - Performing Migration using only API permissions

This article provides all the necessary information to set up and perform a mailbox migration for a Microsoft 365 tenant. The approach outlined in the article is important to follow as it contains new information about the setup of the tenant, the application registration, the replacement of the Application Impersonation role in M365, and the assignment of permissions.

# Check current status:
Get-OrganizationConfig | fl EWSEnabled 
# Enable EWS: 
Set-OrganizationConfig -EWSEnabled $true

# Check a specific mailbox 
Get-CASMailbox -Identity user@domain.com | fl EWSEnabled 
# Enable EWS for a specific mailbox 
Set-CASMailbox -Identity user@domain.com -EWSEnabled $true 
# Enable EWS for ALL mailboxes (use with caution) 
Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -EWSEnabled $true

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App ID to add
$newAppId = "99999999-8888-7777-6666-555555555555"
# Combine existing and new values
$updated = @($current, $newAppId)
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the App ID to remove
$removeAppId = "99999999-8888-7777-6666-555555555555"
# Split the comma-separated list into individual App IDs
$appIds = $current -split ","
# Remove the specified App ID
$updated = $appIds | Where-Object { $_ -ne $removeAppId }
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

The quick checklist below outlines the basic steps covered in detail in this article. These steps allow for the process of replacing the application impersonation.

1. Create a new Application Registration
2. Assign the API Permissions and Grant Admin Consent
3. Obtain the AppID and TenantID from the Application Registration
4. Create a Client Secret
5. Note regarding the Scoping Requirements 
6. Set up your MigrationWiz Project

Considerations

• The following replacement should be followed for any O365 endpoints for O365 mailbox/archive mailbox projects. Depending on the case, these steps should be performed at both the source and the destination.
• You can only perform the recommended replacement with Administrator credentials. If you use end-user credentials you should use the delegated permissions process. 
• This guide does not apply to Public folder migrations.
• The Use Impersonation to Authenticate checkbox must be enabled in your advanced options' Source/Destination tab.
  
  Otherwise, the following error might arise.
  
• If you want to set up your environment for Exchange Online (Microsoft 365) to Exchange Online (Microsoft 365) using coexistence or to use the apply licenses feature in a regular Exchange Online tenant-to-tenant migration, please refer to this guide.

Step One - Create a New Application Registration

Create a new Application Registration in the Microsoft 365 tenant source or destination.

1. Log in to the Microsoft Entra admin center with a Global Administrator login.
2. Click View all products and select Microsoft ID (Azure AD) in the Microsoft Entra Admin Center.
3. In the left sidebar, open the Applications dropdown list and select App Registrations, which is found under the Identity dropdown list.
4. Select New Registration at the top of the screen.
   
5. Give the app a distinct name. You can change this later if necessary.
6. Select the Accounts in this organizational directory only ('Tenant name only' - Single tenant) radio button.
7. Click Register.
   
8. Under the Manage menu, select Authentication (preview).
9. Select the Settings tab.
10. Set the option Allow public client flows to Enabled.
11. Under the Supported Account types, select Accounts in this organizational directory only.
    

Step Two - Assign the API Permissions and Grant Admin Consent

The following steps allow you to assign the API permission and grant consent to the necessary M365 components.

1. From the Manage menu, select API permissions.

   Important

   If an API permission is named User.Read under Microsoft Graph is already present, this can be removed. The Microsoft Graph API does not apply to this project type and is not used.

2. Click Add a Permission.
   
3. Select APIs my organization uses.
4. Scroll down or search for the following permissions Office 365 Exchange Online.
   
5. Select Delegated Permissions.
6. Select EWS.

7. Check the box under EWS for EWS.AccessAsUser.All. 

   Important

   This permission only allows the OAuth application (MigrationWiz) to be associated with EWS. This does not grant access to all mailbox data.

8. Click Add a Permission.
   
9. Select APIs my organization uses.
10. Scroll down or search for the Office 365 Exchange Online.
11. Select Application Permissions.
12. Check the box under Other Permissions for full_access_as_app.
13. Click Add Permissions.
    
14. Click Grant admin consent.
    
15. Click Yes to confirm the settings. Under the Status column, you should see a message that permission has been granted for the domain.

Step Three - Obtain the AppID and TenantID from the Application Registration

Follow the steps below to obtain the AppID and TenantID from the Application Registration.

1. Navigate to the App Registrations item as shown below. In the Overview tab, you will find the Application (client) ID and the Directory (Tenant) ID.
2. Copy both of these to another application, such as Notepad, for use later in this process. This is needed for the MigrationWiz Project Setup.
   

Step Four - Create a Client Secret

Create a Client Secret for the application by following the steps below.

1. Go to Manage > Certificates & secrets from the left sidebar.
2. Create a new secret client by clicking + New client secret.
3. Copy and save the client secrets' value on a notepad or other preferred tool.
   

Step Five - Informational Note

The options provided in Step Two allow the Application Permissions to have full rights to read the mailboxes in the tenant. If you do not want this to be the case, please look at the M365 Mailbox and Archive Migrations - Scoping Option for API Permissions article on how to scope the application permissions to only allow access to a smaller set of mailboxes.

Step Six - Set up your MigrationWiz Project

Add the details from the Application Registration into the MigrationWiz project.

1. Create your migration project.
2. Set up your Endpoints. During this setup, you will be asked for:
   • Application (Client) ID - Obtained in Step Three
   • Directory (Tenant) ID - Obtained in Step Three
   • Client Secret - Obtained in Step Four

The correct Application and Directory IDs must be used, from the App Registration screen. These are NOT the values you used in running the ConfigureM365Tenant script above. They are obtained from Step Three and Step Four in these instructions.

Final Notes

The configuration will need to be performed on both the source and destination if they are Microsoft 365 endpoints. This entire process now supersedes the Application Impersonation requirements that have been present in these migrations for many years. As this old process is being deprecated across M365 tenants by Microsoft over the coming year it is highly recommended that this be the 'go-to' method for the setup of MigrationWiz projects from this point.

In case of any questions or concerns about this new method, contact our support team.

Related Topics

• M365 Mailbox and Archive Migrations - Scoping Requirements
• MigrationWiz Impersonation and Delegation for Microsoft 365