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:

122516 1326 Howtoassign1

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==

122516 1326 Howtoassign2

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:

122516 1326 Howtoassign3

 122516 1326 Howtoassign4

 122516 1326 Howtoassign5

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:

122516 1326 Howtoassign6

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

122516 1326 Howtoassign7

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!

28 thoughts on “How to assign mailbox to a different user with Exchange Online

  1. Brian Klish says:

    Not sure the current status of this, but we used detach a student mailbox from their AD account in one domain and attach it to a staff AD account in another domain. Now that we’ve migrated to Exchange Online and we’re now a Hybrid setup I’m worried about the things discussed here. I assume if I use the Active Directory Migration Tool to instead migrate the AD Account from one domain to another then it would maintain the AD Connect properties? Can you confirm? If so I’m thinking that would be the better way to go for us when we need to do that.

    1. Vasil Michev says:

      The method detailed here has nothing to do with migrating users between AD domains…

  2. Prince says:

    We have a SMB on office 365 Hybrid setup which will be full in each year. Now we are creating a new SMB each year and moving emails using search-mailbox. I am looking for a solution where I could rename the original SMB to “SMP plus year name(SMB_2019)” as a cloud only SMB on Dec 31st and provision new mailbox for the Original AD account replicating to cloud mailbox. So that we could avoid moving emails.

  3. Santhosh Kumar says:

    Hi Vasil,

    We are migrating two Exchange 2010 org to single O365 tenant. We are syncing forestA and ForestB in AAD. If we are planning to migrate ForestA & ForestB users to new child domain in ForestA after the mailbox migration, how should we plan it. What are the change I would need to do. Could you help me on this please

  4. Anelko says:

    Thanks for the guidance!
    Could you please tell me, if there is possibility to handle cases, where the new AD account is already synchronized to O365 by AD Connect?

    1. Vasil Michev says:

      No, this method relies on hard-matching the user, which is done as part of the DirSync provisioning logic. If the account is already synced to O365, a matching ImmutableID will already exist. You can however delete the cloud object and redo the match. Or, if the cloud object already has a mailbox, you can copy the mailbox content.

  5. Gediminas says:

    wow, good news, I am in the middle of one project migrating users from one forest to another with on-prem Exchange and this functionality is needed.

  6. Gediminas says:

    I guess this could be relevant:
    Users removed from synchronization scope no longer switch to cloud-only accounts
    Type: Fixed
    Service category: User Management
    Product capability: Directory

    We’ve fixed a bug in which the DirSyncEnabled flag of a user would be erroneously switched to False when the Active Directory Domain Services (AD DS) object was excluded from synchronization scope and then moved to the Recycle Bin in Azure AD on the following sync cycle. As a result of this fix, if the user is excluded from sync scope and afterwards restored from Azure AD Recycle Bin, the user account remains as synchronized from on-premises AD, as expected, and cannot be managed in the cloud since its source of authority (SoA) remains as on-premises AD.

    Prior to this fix, there was an issue when the DirSyncEnabled flag was switched to False. It gave the wrong impression that these accounts were converted to cloud-only objects and that the accounts could be managed in the cloud. However, the accounts still retained their SoA as on-premises and all synchronized properties (shadow attributes) coming from on-premises AD. This condition caused multiple issues in Azure AD and other cloud workloads (like Exchange Online) that expected to treat these accounts as synchronized from AD but were now behaving like cloud-only accounts.

    At this time, the only way to truly convert a synchronized-from-AD account to cloud-only account is by disabling DirSync at the tenant level, which triggers a backend operation to transfer the SoA. This type of SoA change requires (but is not limited to) cleaning all the on-premises related attributes (such as LastDirSyncTime and shadow attributes) and sending a signal to other cloud workloads to have its respective object converted to a cloud-only account too.

    This fix consequently prevents direct updates on the ImmutableID attribute of a user synchronized from AD, which in some scenarios in the past were required. By design, the ImmutableID of an object in Azure AD, as the name implies, is meant to be immutable. New features implemented in Azure AD Connect Health and Azure AD Connect Synchronization client are available to address such scenarios:

    Large-scale ImmutableID updates for many users in one shot

    For example, while implementing Azure AD Connect you make a mistake, and now you need to change the SourceAnchor attribute. Solution: Disable DirSync at the tenant level and clear all the invalid ImmutableID values. For more information, see Turn off directory synchronization for Office 365.

    Large-scale ImmutableID update for many users in a staged approach

    For example, you need to do a lengthy AD DS inter-forest migration. Solution: Use Azure AD Connect to Configure Source Anchor and, as the user migrates, copy the existing ImmutableID values from Azure AD into the local AD DS user’s ms-DS-Consistency-Guid attribute of the new forest. For more information, see Using ms-DS-ConsistencyGuid as sourceAnchor.

    Rematch on-premises user with an existing user in Azure AD For example, a user that has been re-created in AD DS generates a duplicate in Azure AD account instead of rematching it with an existing Azure AD account (orphaned object). Solution: Use Azure AD Connect Health in the Azure portal to remap the Source Anchor/ImmutableID. For more information, see Orphaned object scenario.

    1. Vasil Michev says:

      Yup. This has always been a workaround, never a supported solution. I’m actually surprised it took that many years to fix it.

  7. Alan Tesser says:

    First, I need to give a huge thanks for this post, I’ve been using this approach to disconnect mailboxes and connect to new users (mainly interns that were permanently hired) for a long time. Yesterday though, I tried doing that and I got an error when changing the immutableID (I ‘triple’ checked that the user was a disconnector). I found on another blog that it was really a Microsoft change, and that it’s now possible to use the mS-DS-ConsistencyGuid attribute to make changes (however, I did not find how to do it).
    Are you still having the same issue? If so, do you already have any alternatives?
    Thank you!

    1. Vasil Michev says:

      I believe the behavior was changed recently, so we’re no longer able to use this workaround. I’m OOO for few days and I will probably not be able to test it right now, but if it’s indeed true, the only other method would be to disable DirSync/make the changes/re-enable DirSync.

  8. Mike says:

    Hi Vasil,

    Great Article! I was looking for something like this.
    We are migrating our users from the Domain to the Sub-domain and after the ADMT migration we were thinking to use you method so we can sync back the migrated users with their mailxboxes.

    Please let me know your thoughts.


  9. Nick Eckermann says:

    Forest A and B AD Connect synced to 1 tenant.

    Forest A
    Exchange server
    User Accounts and mailboxes
    Forest B
    Linked mailboxes in Forest A

    The mailboxes are not working after migrating them to the cloud. OWA works, but outlook prompts for 1000 passwords and sometimes it connects and sometimes it doesn’t.

    If I remove the disabled account on the exchange domain side do you think I just just change the guid to the user account in the active user forest? There is not exchange schema in that domain at this time.

  10. Jane Dumke says:

    Excellent article – exactly what I needed to know – also helped me in solving an AD sync conflict I had.

  11. aizat says:

    Hi. Nice guide. But how to perform soft-matching? I am referring to this sentence, ” Or we can just clear the attribute and use the soft-matching process”.

  12. 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?

    1. 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.

  13. 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?


    1. 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 🙂

  14. 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

    1. 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.

      1. William says:

        Hello sir. Great article. Quick question. In an exchange hybrid environment, if a shared mailbox was created in office 365 exchange admin center, can this process be used to sync the mailbox with a previously unassociated on-prem account? I would assume that it can, but still felt I should ask….

        1. Vasil Michev says:

          It can, but keep in mind that this process is in no way supported by Microsoft, so if anything breaks you are on your own.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.