How to assign mailbox to a different user with Exchange Online

Sometimes, you might want to assign an already existing mailbox to another user. With on-prem Exchange, this can be easily achieved. In Exchange Online however, there are certain limitations that prevent you from doing this. For starter, you don’t have access to the Disable-Mailbox cmdlet (removing the Exchange license from the user is an entirely different process). If you are desperate enough however, there is a way to actually achieve this.

DISCLAIMER: Attempt these steps only if you are familiar with dirsync and have an understanding how the provisioning process works. There are much easier ways to ensure that the mailbox content can be accessed by another user. Those include converting the mailbox to shared one, granting permissions to another user (with ot without converting the mailbox), exporting the mailbox content to .pst file, copying the mailbox content to another mailbox using the Search-Mailbox cmdlet, etc. In addition, if the mailbox you are trying to ‘attach’ is already removed (i.e. you can see it with the Get-RemovedMailbox cmdlet), you can reconnect it by using the New-Mailbox -Removed mailbox cmdlet.

If you are still reading, I assume you are either too stubborn, desperate or curious to try the process. The key here is to (ab)use the directory synchronization process and the soft/hard match functionality. Those methods will only work if the targeted user object does not have an ImmutableID property, or if you are able to change it. In other words, the object must be a disconnector in the metaverse (or never been synced before). To demonstrate the process, I created a new user object in my local AD and synced it to WAAD: 

Once the object was synced, I provisioned a mailbox for it and sent a message announcing my diabolical plans. I’ve also used PowerShell to gather some information I will later need. Here are the relevant attributes:

PS C:\> Get-Mailbox swapmailbox | fl *guid*

ExchangeGuid           : 96658711-bdb8-4b78-a907-12f0e5cb60ca
Guid                   : 6290c800-2879-4d99-8bd1-acb3ffe36d44

PS C:\> Get-MsolUser -SearchString swap

UserPrincipalName :
ObjectId          : 151a4f28-fb9d-45ef-95bf-b3a7cccfeb2f
ImmutableId       : xiL1lf4nx0W6w4Ac/9qrTA==

The next steps was to force the object in the “disconnector” state. This can be done if you delete the object in the on-prem AD and restore it back from the O365 portal (but leave it deleted in AD!). The corresponding mailbox will then be pushed to the soft-deleted container, but once you recover the user object it will automatically be reconnected. Here are some screens of the process:



So, as you can see the mailbox was automatically reconnected to the recovered account and everything is back to where we started. With one small difference, though: the user object is now a disconnector! Which means, we can play with it’s ImmutableID attribute and match it against another user. Or we can just clear the attribute and use the soft-matching process, but why do it the easy way?

I created a new user in AD, appropriately named ‘mailboxthief’. I used the following cmdlet to convert the objectGUID attribute to ImmutableID:

[system.convert]::ToBase64String((Get-ADUser mailboxthief).objectGUid.ToByteArray())

Then, I replaced the ImmutableID of our disconnector user object swapmailbox with the ImmutableID of the mailboxthief object, thus ensuring that the hard-match process will take place with the next dirsync cycle. Here is the cmdlet:

Set-MsolUser -UserPrincipalName -ImmutableId "1KlUci/w70u0mOz242tEPw=="

Here’s what happened after the next dirsync push:

And here’s how things looked up in Office 365:

Dirsync actually failed to update the UPN, but that can easily be arranged with the Set-MsolUserPrincipalName cmdlet. The important part is that the object is no longer a disconnector, it’s actually linked to the ‘mailboxthief’ object from local AD. And what better proof of that than comparing the GUIDs:

PS C:\> Get-MsolUser -SearchString swap | fl UserPrincipalName,ObjectId,ImmutableId,LastDirSyncTime

UserPrincipalName :
ObjectId          : 151a4f28-fb9d-45ef-95bf-b3a7cccfeb2f
ImmutableId       : 1KlUci/w70u0mOz242tEPw==
LastDirSyncTime   : 01/10/2014 11:42:05

PS C:\> Get-Mailbox swapmailbox | fl *guid*

ExchangeGuid           : 96658711-bdb8-4b78-a907-12f0e5cb60ca
Guid                   : 6290c800-2879-4d99-8bd1-acb3ffe36d44

If you compare those with the values at the beginning, you will see that this is indeed the same mailbox. The WAAD user object linked to it is also the same (note the ObjectId parameter). That object however is now linked to a different object in my local AD, thus the ‘mailboxthief’ has claimed ownership of the ‘swapmailbox’.

Alternatively, the same end result can be achieved if you simply disable dirsync (which will make all objects disconnectors), change the ImmutableID (allowed for disconnectors), force the sync. In case the on-prem object has already been synced previously, you will have to get rid of the linked object in WAAD.

Happy abusing!

This entry was posted in Exchange Online, Office 365. Bookmark the permalink.

6 Responses to How to assign mailbox to a different user with Exchange Online

  1. sajid says:


    Excellent article, could i ask you 1 question, instead of going this process, i change it to shared mailbox then add new user, then remove old user and make it user mailbox… will not simplify ? just curiacity … thanks

    • Vasil Michev says:

      The shared mailbox will still be associated with the user object, if you remove it the mailbox will get deleted. But in general you can follow a similar process with shared mailboxes.

  2. Craig says:


    I’m confused by your reply to Sajid. Are you saying that if you delete the user account associated with the shared mailbox at a later date the mailbox will also be deleted?


    • Vasil Michev says:

      It will be deleted immediately, but can be recovered for some 30 days or so. Shared mailboxes, like User mailboxes, are tied in to a user object. If you delete the user object, the shared mailbox will follow suit. It’s easy to verify – just create a dummy shared mailbox and then delete the corresponding user object from the O365 admin center 🙂

  3. Craig says:

    But Sajid is converting the shared mailbox back to a user mailbox again so the old shared mailbox user object is irrelevant isn’t it?

    • Vasil Michev says:

      Converting between user/shared mailbox does not change the fact that you have a corresponding User object in Azure AD. Testing this takes a minute, try it.

Leave a Reply

Your email address will not be published. Required fields are marked *