Error when you move mailboxes from on-premises to Exchange Online in a hybrid deployment: User is already being moved
Original KB number: 4502865
Assume that you have a hybrid deployment of Exchange Server and Exchange Online in Office 365. When you try to move mailboxes from on-premises to Exchange Online, you receive an error message that resembles one of the following:
Error: UserAlreadyBeingMigratedException: The user 'Name' already has a pending request. Please remove the existing request and resume the current batch or start a new batch for this user. --> Mailbox 'Name' is already being moved to 'Cloud Database Name'.
Error: MigrationPermanentException: The onboarding move could not be created because user 'Name' is already being moved. --> The onboarding move could not be created because user 'Name' is already being moved.
This issue may occur if one of the following conditions is true:
You already have a move request (active or orphaned) in Exchange Online for that user. In this scenario, the error message most likely is as follows:
Mailbox 'Name' is already being moved to '<Cloud Database Name>'.
You already have a move request (active or orphaned) in on-premises Exchange Server for that user. In this scenario, the error message is most likely as follows:
The onboarding move could not be created because user 'Name' is already being moved.
To fix this issue, use the following steps.
Step 1: Identify the move request for the affected user
In Exchange Management Shell, run the following command:
Get-MoveRequest -Identity 'firstname.lastname@example.org'
In Exchange Online PowerShell, run the following command:
Get-MoveRequest -Identity 'email@example.com'
If you're unsure about the identity of the user, you can output all move requests by running the
Get-MoveRequest command to find the affected user.
Step 2: Verify and delete the move request or move references
You can check the status of a user move request that you find in either on-premises or Exchange Online. The status will most likely be in a Completed or Failed state. You have to remove this move request in order to be able to create a new move request to migrate the user to Exchange Online.
If the move request that has to be deleted isn't associated with a migration batch or a migration user, you can run
Remove-MoveRequest directly in PowerShell. Otherwise, we recommend that you remove the corresponding migration batch or corresponding migration user from that batch. This should also take care of the move request removal.
If you don't find a move request for the user in the on-premises or Exchange Online organizations, and you still receive an error message (user is already being moved), you will have to manually clean up the move references for that user from your on-premises Active Directory container.
To do this, follow these steps:
If you use the Attribute Editor, ADSI Edit snap-in, LDP utility, or any other LDAP version 3 client, and you incorrectly change the attributes of Active Directory objects, you can cause serious problems. Microsoft cannot guarantee that problems that occur if you incorrectly change Active Directory object attributes can be solved. Change these attributes at your own risk. Always make a note of the value that was there before you remove or change these attributes so that you can undo the changes.
Open Active Directory Users and Computers in Domain Controller (DC) server.
Locate the affected user, click View, select the Advanced Features check box, and then open the Attribute Editor tab.
Look for msExchMailboxMove attributes, and check whether any value is set for that user.
For example, msExchMailboxMoveRemoteHostName is populated by the
<tenant.onmicrosoft.com>value if there was at least one attempt to move the user to Exchange Online.
If the move request was successfully removed from Exchange Online (that is, you don't find it by running
Get-MoveRequestin Exchange Online PowerShell) but the msExchMailboxMoveRemoteHostName attribute is set, this suggests that the move reference was not cleared up correctly from on-premises Azure Active Directory (Azure AD). In this scenario, you have an orphaned move request for that user.
Another example for an orphaned local move request for a primary or archived mailbox would be if there's no move request on-premises for it, but there are attributes set, such as the following:
Manually clear the value in Azure AD, and then create another move request in Exchange Online for that user.