The basic scenario in hybrid Exchange environments is that we have to create an Exchange mailbox on-premise, which has to be synced to Exchange Online (O365).
Note: In this graphic I didn’t differ between on-premise or EOP mailflow, thats why I show both solutions.
The game plan is mostly the one where you create an AD user object, which you sync to Azure AD with Azure AD connect service. After that happend successfully, your user is visible in the Office 365 portal.
Quite often it can happen, that some admins make the mistake, that they assign the exchange online plan to soon. Office 365 than goes and checks if there is a mailbox available for the user. If not one will be created in the cloud and we will be not able to sync the one, created on-premise, to the cloud.
The way, how to fix this issue by matching the GUID, I described in another article in this blog. You can find this article HERE.
Here I write about the similar scenario; how to fix issues with enabled cloud-only user accounts in Office 365.
The customer creates a new tenant with or without AAD Connect in Office 365. They create several cloud-only accounts and assign licenses to those accounts. Since these cloud-only accounts don’t have an Exchange GUID from the on-premise Exchange, Office 365 creates a new mailbox in Exchange Online.
Some time later, the customer decides to perform a hybrid migration of all, or some mailboxes to Exchange Online. AAD Connect is configured with Exchange Hybrid settings and Azure AD is able to “soft-match” the cloud users to the on-perm user accounts.
Now we have same user object with two mailboxes, one on-premises and one in the cloud. This is bad. Mail flow will be affected and we will be unable to migrate the user mailbox to Exchange Online because a mailbox already exists there.
Remember: Till now we have exactly the scenario from my other article how to Merge Exchange online Mailbox with on-premise AD account.
But what about simply unassign the Exchange Online license from the account in the Office 365 Admin portal?
If we unassign the license of the user in Office 365, the cloud mailbox at first will be soft-deleted, but when we assign it again, Office 365 will automatically reconnect the soft-deleted mailbox back to the user account. So again, we have the same problem as in the beginning.
It does that, because the PreviousRecipientTypeDetails property on user account is set to “UserMailbox”. When this property is set, user account is “unclean” and Exchange Online will always want to reconnect the soft-deleted mailbox. Even if we manage to permanently delete the cloud mailbox, Exchange Online will create another new cloud mailbox when the user is re-licensed with an Exchange Online plan.
So what to do now? One way is to delete the cloud user object permanently by useing the command:
after this command we’d also have to run the command:
When both commands were ran successfully through remote PowerShell, we are able to start from scratch again.
That means, we have to sync the on-premise Active Directory user object to the cloud, again.
The problem with this is that it’s cumbersome to do and, more importantly, also deletes any prior SharePoint and OneDrive data that the cloud user may have been accumulated.
This picture shows an example from hybrid scenario of a mailbox, before it is migrated to exchange online
Microsoft is rolling out a new switch for the Set-User remote PowerShell cmdlet which addresses the issue of “unclean” accounts/mailboxes.
The new switch gives us a new command option which is called:
By running this command in the remote PowerShell, PowerShell will clear the PreviousRecipientTypeDetails property and return the user account to a “clean” condition. The new command helps to prevent Exchange Online to again create a cloud mailbox for history reason, as shown above.
The new command disconnects the cloud mailbox without affecting other data stored in Office 365, such as SharePoint or OneDrive data.
Important to know about this new command is, that after running it, the once created online mailbox which we have just deleted is deleted permanently. There is no way back to restore it again. So before running this command the user has to save any important e-mails first or export the mailbox to a PST.