When attempting to migrate a mailbox, the process fails with the error “Error creating source session. The request failed. The remote server returned an error: (403) Forbidden).”
The source account is a Global Administrator with MFA disabled.
Access is granted through a Service Principal.
The service account is PIM-enabled.
The source tenant is hybrid, with accounts synchronized from on-premises Active Directory.
This issue can also occur in cloud-only tenants when the service account is created using Microsoft PIM.
Cause 1: Application Access Policy Limiting application permissions to specific Exchange Online mailboxes - Microsoft Graph | Microsoft Docs
Cause 2: Minimal and Full consents both granted
| Scenario | Consent granted | Outcome |
| Scenario 1 |
Source Tenant
Target Tenant
| Error will occur |
| Scenario 2 |
Source Tenant
Target Tenant
| Error will occur |
| Scenario 3 |
Source Tenant
Target Tenant
| Error may occur |
| Scenario 4 |
Source Tenant
Target Tenant
| Error may occur |
** there are more scenario that cant be covered but multiple consent will be causing the error to occurs
Cause 3: RBAC consent granted and not configured for use
Cause 4: Conditional Policy or Application Policy (Group Mailbox for Teams or M365 Group)
Cause 5: Account has Microsoft license assigned which does not support Exchange WebService connectivity (ie: F3)
Cause 6: Baseline Security Mode is enabled and the setting "Block access to Exchange Web Services" is enabled
Cause 7: EWS is disabled at mailbox level
Cause 8: Exchange Online EWS access was restricted by the EwsAllowedAppIDs configuration, and the migration application's App ID was not included in the allow list.
Since source EXO mailboxes are controlled by the Application Access policy, verify what group this policy is applied to, then add affected users as members of the said group onprem. After ADconnect syncs user's membership to the cloud, mailbox migration should work for them.
It may be required to remove Application Access Policy using PowerShell as there's no convenient way to see them using Microsoft Azure GUI
To retrieve a list of Application Access Policies and test ability to access a specific mailbox, please do the following command in bold:
Connect-ExchangeOnline -UserPrincipalName <admin_account using onmicrosoft UPN> -ShowProgress $true
Get-ApplicationAccessPolicy | Select-Object Identity, AppId, AccessRight, ScopeIdentity, PolicyScopeGroupId
Note: <AppId> is the id that come from output of 2nd cmdlet.
Test-ApplicationAccessPolicy -Identity "<email of user's account>" -AppId <AppId>
Result of Test-ApplicationAccessPolicy will indicate whether AppID has access to the mailbox. Quest ODM AppId are listed in Microsoft AzureAD -> Enterprise Application, search for "quest" in the search bar on the right pane.
Note: The error could also be "error creating target session". This should pinpoint what tenant exactly is experiencing an issue.
** Please find the below Microsoft document reference of how to delete enterprise applications.
https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/delete-application-portal?pivots=portal
If it is not intended to use RBAC, follow the steps below to revoke RBAC consent. Otherwise if RBAC is intended, review this article to ensure it is configured correctly.
Add the temporary migration account (or account which granted consent) to the application/conditional access policy to avoid the error.
Ensure that the account for which the mailbox migration is running has a license assigned with Exchange WebService connectivity support (EWS application support = Yes)
https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-service-description#feature-availability-across-exchange-online-standalone-plans
Either disable "Block access to Exchange Web Services" from within Baseline security mode in the tenant(s) or exclude users being migrated.
If the block is enabled either remove the checkmark and save the change. This can take a few hours to propagate the change. In cases where the block cannot be removed, exclude users that need to be migrated.
https://admin.cloud.microsoft/?source=applauncher#/baselinesecuritymode
EWS must also remain enabled for all mailboxes that On Demand Migration will process. If it is set to False the mailboxes can't be migrated using EWS.
Get-CASMailbox user@domain.com | fl EwsEnabled #Check mailbox setting for Null, True or False
Set-CASMailbox user@domain.com -EwsEnabled $True #Enable EWS for a mailbox by setting it to Null or True
If it is set to Null or True and EWS is not working and mailbox migrations still produce a 403 error, toggle the setting to False and back to Null/True allowing for tenant propagation for the setting being changed (between changes allow tenant propagation between 15 to 60 minutes as changing global tenant settings within a few moments may not trigger the setting change) and then migrate the mailboxes again with ODM.
Note: Until Oct 2026 it will be possible to change the value of EwsEnabled to Null, True or False after that time Null will be no longer available to be set.
Add the Enterprise App for ODM migration application's App ID to the Exchange Online EWS allow list. To obtain the Application ID from Microsoft Entra Admin Center | Enterprise Apps and search for Quest On Demand - Migration - Mailbox Migration to locate the Application ID and use it to update the EWS Allowed App IDs.
Microsoft has the following community blog post with PowerShell examples of adding and removing an App ID.
