I recently had an issue where a user had two accounts, each in separate domains.  The problem was that the wrong account was linked to the Exchange Online mailbox, and I needed to move the mailbox to the other account and delete the now defunct un-linked account.  I’m not going to drill in to too much detail on things such as immutable ID used with Azure AD, if you don’t know about it I suggest going and reading up on it all first.  The key things to understand are around hard and soft matching and the source anchor.  In this scenario the immutable ID source anchor was the ObjectGUID for the source objects.  For simplicity we will call the two accounts [email protected] (the one currently linked to the mailbox and [email protected] (the one we want to use and to move the mailbox to).

The general plan is to get rid of the new account in Azure AD, make the new account match the old account, and then let the AAD connect sync join the new account to the existing mailbox and Azure AD account.

First I made a note of all the details (UPN, ImmutableID, ObjectID, Mailbox GUID) of both accounts as shown within the Get-MsolUser command, so I could easily recognise them and identify them.  Then I moved both of them out of scope of AAD Connect and forced a sync.  This moved both objects to the deleted users within Office 365.  From here I needed to hard delete the [email protected] (the one without the mailbox) from AzureAD.  I used the command

Remove-MsolUser -UserPrincipalName [email protected] -RemoveFromRecycleBin -force

I then located the [email protected] within the deleted users and restored the account.  This results in it being created in Office 365 as a cloud mastered user.  This is great as it allows you to edit it and make changes.

From here there are two ways to get them to match up, either soft or hard matching.  I ended up just going the whole way and getting everything matched.

So here is how you do the hard matching using the immutable ID.  First you need to get the Object GUID of the [email protected], you do this on-premises via the Get-ADUser command.  It provides it in the usual GUID format, but the immutable ID is stored in base64 so looks totally different.  You can use the website http://guid-convert.appspot.com to perform the conversion for you, or you could just take the immutable ID you noted down earlier for the [email protected] account.   You can’t change the immutable ID when the user has a federated domain UPN, so the first thing you have to do is change the UPN to use your @mytenant.onmicrosoft.com domain.  So using the Set-MsolUserPrincipalName command change the UPN of the [email protected] AzureAD account.  Once changed you can use the following command so that it takes on the Immutable ID of the [email protected].

Set-MsolUser [email protected] -immutableID “Andsh23jhd+djkjs==”

You can now change the UPN back to a federated UPN, this should match the UPN of the [email protected].

For soft matching, and honestly i’d do this anyway as it is trivial to complete.  Make sure the email addresses in the Office 365 account exactly the match those in the on-premises account.  Don’t worry about SIP or other addresses, just the SMTP addresses.  Make sure the primary addresses are the same.  You can do this by updating either the on-premises or the Office 365 account, it doesn’t matter so long as they are the same.

All of this should make it all match up – but you’re lacking on important thing, the on-premises user account needs to be populated with the mailbox details.  To complete this we will need to run a few commands on-premises on the Exchange Management Shell:

Enable-RemoteMailbox mydomain\newaccount -RemoteRoutingAddress [email protected]

You may need to use the -DomainController parameter demending where the Exchange server lives and the account domain is.  You then need to link up the Exchange GUID, without which things such as Autodiscover may have issues:

Set-RemoveMailbox mydomain\newaccount -ExchangeGuid ebc7637a-991a-cca11-00ffc-3209afcab109e

Again you may need to use the -DomainController parameter.

When all this is done you’re ready to let AAD Connect do its stuff.  So move the [email protected] in to scope of AAD Connect, give AD a few moments to replicate, then initiate a delta sync on your AAD Connect server.  Start-ADSyncSyncCycle will do a delta sync for you.  Monitor the event logs to see when it finishes, then check in to Office 365.  The mailbox you were trying to fix should have changed from a cloud based identity to a Synced With identity.  This indicates that the matching has completed correctly and all is well.  If you end up with two identities then your matching has gone wrong somewhere.  So best to go back and check everything matches, figure out what was wrong, then move the new account out of scope, perform the hard delete in Office 365, fix the properties and then let it sync back again.

If you get errors on an account during this process, such as “Exchange: An unknown error has occurred.  Refer to correlation ID:”.  The following command can be really handy in showing you what went wrong:

(Get-MsolUser -UserPrincipalName [email protected]).errors[1].ErrorDetail.objecterrors.errorrecord.ErrorDescription | fl