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 : swapmailbox@michevdirsync.onmicrosoft.com 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 swapmailbox@michevdirsync.onmicrosoft.com -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 : swapmailbox@michevdirsync.onmicrosoft.com 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!
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.
The method detailed here has nothing to do with migrating users between AD domains…
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.
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
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?
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.
Thanks for this article which I found really useful kicking off my project to migrate a bunch of users using hard matching. I created a script which covered my needs and thought perhaps your readers may find useful. It’s available on my blog here https://cloudwyse.blogspot.com/2019/02/migrate-o365-mailboxes-using-hard.html
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.
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.
Yup. This has always been a workaround, never a supported solution. I’m actually surprised it took that many years to fix it.
Well, according to the AAD changelog, they seem to have reverted the change? 🙂
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#users-removed-from-synchronization-scope-no-longer-switch-to-cloud-only-accounts
Hi,
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!
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.
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.
Thanks.
Regards,
Mike
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.
Excellent article – exactly what I needed to know – also helped me in solving an AD sync conflict I had.
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”.
The soft-matching process is explained here: http://support.microsoft.com/kb/2641663
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?
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.
Vasil,
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?
Cheers
Craig
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 🙂
Greetings,
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
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.
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….
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.