We are introducing a new parameter that can be called by using the Set-User cmdlet in Exchange Online PowerShell. The feature is focused for customers doing migration of on-premises mailboxes to the cloud and you will be able to use it within three weeks or so (Edit 1/19: we updated this due to slower than expected rollout): Customers who have Hybrid or on-premises environments with AAD Connect / Dir Sync may have faced the following scenario:

\n
1. User Jon@contoso.com has a mailbox on-premises. Jon is represented as a Mail User in the cloud.
\n
2. You are synchronizing the on-premises directory to the cloud in preparation to migrate to Exchange Online.
\n
3. Due to issues with the on-premises sync or due to a configuration problem, the user Jon@contoso.com does not get the ExchangeGUID synchronized from on-premises to the cloud.
\n
4. If the Exchange GUID is missing from the object in the cloud, assigning an Exchange license to Jon@contoso.com will cause Exchange Online to give the user a mailbox, converting the object from a Mail User to a User Mailbox. (Adding the license is a step required for the migration of the mailbox from on-premises to the cloud.)
\n
5. The end result is the user that has 2 mailboxes: one on-premises and one in the cloud. This is not good. Mail flow issues will follow.
\n

Those doing these types of migrations will know that the ExchangeGUID value is very important as it helps Exchange Online identify that the user has a mailbox on-premises, and if an Exchange license is assigned in the cloud, a new mailbox should not be created. The immediate fix for this situation is to remove the Exchange License from Jon@contoso.com. This will convert the cloud object for Jon back to a Mail User. Mail flow should be restored at this point. The problem now is that you have an “unclean” cloud object for Jon. This is because Exchange online keeps pointers that indicate that there used to be a mailbox in the cloud for this user:

PS C:\\WINDOWS\\system32> Get-User Jon@contoso.com | Select name,*Recipient*
Name PreviousRecipientTypeDetails RecipientType RecipientTypeDetails
---- ---------------------------- ------------- --------------------
Jon UserMailbox MailUser MailUser

Re-assigning the license after that will always err on the side of caution and Exchange Online will try to re-connect the (duplicate, temporary) mailbox in the cloud (and mailboxes can be reconnected for 30 days). Therefore Jon’s account in the cloud can’t be licensed in preparation for migration. Up to now, one of the few options to fix this problem was to delete *only in the cloud* Jon’s object and re-sync it from on-premises. This would delete jon@contoso.com from the cloud – but from all workloads, not only Exchange. This is problematic because Jon could have his OneDrive or SharePoint data in the cloud only and deleting his account means that this will be deleted too. If the account is then re-created, Jon and the tenant admin would have to work to recover to his new account all the data he used to have in OneDrive or SharePoint just because Exchange data needed to be “cleaned up”. The new parameter in the user cmdlet will allow tenant admin to clean up Exchange Online Jon’s object without having to delete it. To clean the object, you can run the following command:

PS C:\\> Set-User Jon@contoso.com -PermanentlyClearPreviousMailboxInfo
Confirm
Are you sure you want to perform this action?
Delete all existing information about user “Jon@contoso.com\"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to continue?
Yes  Yes to All  No  No to All  [?] Help (default is \"Y\"): Y

Executing this leaves you with a clean object that can be re-licensed without causing the 2-mailbox problem. Now you can on-board Jon’s on-premises mailbox following the usual steps. An alternative – a call to support to do the clean-up for you - is also not needed. Remember, cleaning up the user means that the older associated disconnected (duplicate) cloud mailbox is not recoverable. If you want to keep it or be able to check it’s content, we recommend using Soft Deletion or Inactive Mailboxes to keep the mailbox.

Note: This command is expected to be executed when you have an on-premises mailbox and a mailbox in the cloud for the same object due to bad AAD Connect configuration, to clean the object that can be re-licensed. The procedure allows you get out of the dual mailbox state and enable you to re-try on-boarding the mailbox immediately.
If you execute this for a user whose mailbox is cloud only after delicensing the user (and intend to later re-license the same user and expect to have a new clean mailbox for the user) - then this will not happen immediately. To avoid potential loss of mailbox data due to unintended/mistaken execution of the command, we retain the mailbox data for 30 days so that you may recover it. If your intention is to clean-up cloud only mailbox then you may hard delete the user account to re-create a clean mailbox.

Mario Trigueros Solorio

We are introducing a new parameter that can be called by using the Set-User cmdlet in Exchange Online PowerShell. The feature is focused for customers doing migration of on-premises mailboxes to the cloud and you will be able to use it within three weeks or so (Edit 1/19: we updated this due to slower than expected rollout): Customers who have Hybrid or on-premises environments with AAD Connect / Dir Sync may have faced the following scenario:

\n
1. User Jon@contoso.com has a mailbox on-premises. Jon is represented as a Mail User in the cloud.
\n
2. You are synchronizing the on-premises directory to the cloud in preparation to migrate to Exchange Online.
\n
3. Due to issues with the on-premises sync or due to a configuration problem, the user Jon@contoso.com does not get the ExchangeGUID synchronized from on-premises to the cloud.
\n
4. If the Exchange GUID is missing from the object in the cloud, assigning an Exchange license to Jon@contoso.com will cause Exchange Online to give the user a mailbox, converting the object from a Mail User to a User Mailbox. (Adding the license is a step required for the migration of the mailbox from on-premises to the cloud.)
\n
5. The end result is the user that has 2 mailboxes: one on-premises and one in the cloud. This is not good. Mail flow issues will follow.
\n

Those doing these types of migrations will know that the ExchangeGUID value is very important as it helps Exchange Online identify that the user has a mailbox on-premises, and if an Exchange license is assigned in the cloud, a new mailbox should not be created. The immediate fix for this situation is to remove the Exchange License from Jon@contoso.com. This will convert the cloud object for Jon back to a Mail User. Mail flow should be restored at this point. The problem now is that you have an “unclean” cloud object for Jon. This is because Exchange online keeps pointers that indicate that there used to be a mailbox in the cloud for this user:

PS C:\\WINDOWS\\system32> Get-User Jon@contoso.com | Select name,*Recipient*
Name PreviousRecipientTypeDetails RecipientType RecipientTypeDetails
---- ---------------------------- ------------- --------------------
Jon UserMailbox MailUser MailUser

Re-assigning the license after that will always err on the side of caution and Exchange Online will try to re-connect the (duplicate, temporary) mailbox in the cloud (and mailboxes can be reconnected for 30 days). Therefore Jon’s account in the cloud can’t be licensed in preparation for migration. Up to now, one of the few options to fix this problem was to delete *only in the cloud* Jon’s object and re-sync it from on-premises. This would delete jon@contoso.com from the cloud – but from all workloads, not only Exchange. This is problematic because Jon could have his OneDrive or SharePoint data in the cloud only and deleting his account means that this will be deleted too. If the account is then re-created, Jon and the tenant admin would have to work to recover to his new account all the data he used to have in OneDrive or SharePoint just because Exchange data needed to be “cleaned up”. The new parameter in the user cmdlet will allow tenant admin to clean up Exchange Online Jon’s object without having to delete it. To clean the object, you can run the following command:

PS C:\\> Set-User Jon@contoso.com -PermanentlyClearPreviousMailboxInfo
Confirm
Are you sure you want to perform this action?
Delete all existing information about user “Jon@contoso.com\"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to continue?
Yes  Yes to All  No  No to All  [?] Help (default is \"Y\"): Y

Executing this leaves you with a clean object that can be re-licensed without causing the 2-mailbox problem. Now you can on-board Jon’s on-premises mailbox following the usual steps. An alternative – a call to support to do the clean-up for you - is also not needed. Remember, cleaning up the user means that the older associated disconnected (duplicate) cloud mailbox is not recoverable. If you want to keep it or be able to check it’s content, we recommend using Soft Deletion or Inactive Mailboxes to keep the mailbox.

Note: This command is expected to be executed when you have an on-premises mailbox and a mailbox in the cloud for the same object due to bad AAD Connect configuration, to clean the object that can be re-licensed. The procedure allows you get out of the dual mailbox state and enable you to re-try on-boarding the mailbox immediately.
If you execute this for a user whose mailbox is cloud only after delicensing the user (and intend to later re-license the same user and expect to have a new clean mailbox for the user) - then this will not happen immediately. To avoid potential loss of mailbox data due to unintended/mistaken execution of the command, we retain the mailbox data for 30 days so that you may recover it. If your intention is to clean-up cloud only mailbox then you may hard delete the user account to re-create a clean mailbox.

Mario Trigueros Solorio

ChristosG76 

i think i found the solution for this....you need to move those users to a non synced OU, and after it will remove the user account from the cloud. It will be in the deleted users for 30 days. Just simply recover that user in the cloud and it will be just a cloud user. After this just move that onprem AD user back to the original synced OU and run a Delta AD sync. For me there was an error, i needed to wait for a few seconds before the Delta sync. After the new sync i could see everything in Teams and Outlook calendar. It is syncronized very well, like for the new users!

I hope it helps.

 Im in the same situation as you. Have you found any solution for that?

wbanta999 you can exclude specific named accounts from the teams retention policy via the compliance portal.

Hello,

I have a number of 365 accounts created prior to setting up the Hybrid with my on premise Exchange Server.  We want to keep mailboxes on the on premise server.  We set up the Hybrid configuration in an attempt to get Calendars in Teams to sync with the on premise mailbox.  This functionality works if I create a new user locally however the 80+ users that had 365 mailboxes created previously are not so lucky.

If I delete the online mailbox using this procedure, it works, the mailbox gets deleted online, I can confirm by going into the mail tab of the user and I get the message \"This user's on-premises mailbox hasn't been migrated to ‎Exchange Online‎. The ‎Exchange Online‎ mailbox will be available after migration is completed\"

However, for these users the Teams calendar sync does not work while it does work with newly created users.  Obviously since this functionality works with new users there must be something else that needs to be done with these users whose online mailboxes get deleted with this method.

Do you have any suggestions?

Hi, i have tried everything in this post and lots of other posts. But i cant change MailUser to UserMailbox

I have removed license and waited overnight before running the PermanentlyClearPreviousMailboxInfo but its still MailUser. I dont get any errors and . Users that where made in the cloud and not onprem is working. The onprem isnt available so i have run

Set-MsolDirSyncEnabled -EnableDirsync $False

and

Set-MsolDomainAuthentication -DomainName <YourO365Domain.com> -Authentication managed

This is a user that was made in the cloud and working

\"

PS C:\\Windows\\system32> get-exorecipient email address removed for privacy reasons

ExternalDirectoryObjectId : 11111111-ab97-44e4-81ac-000000000000
Identity : Yyyyyy
Alias : Yyyyyy
EmailAddresses : {SIP:email address removed for privacy reasons, SMTP:email address removed for privacy reasons, SPO:SPO_11111111-0000-40c7-ba4c-cdf
26ac1eb49@SPO_00000000-0010-4e37-a6aa-111111111111}
DisplayName : Yyyyyy
Name : Yyyyyy
PrimarySmtpAddress : email address removed for privacy reasons
RecipientType : UserMailbox
RecipientTypeDetails : UserMailbox
ExchangeVersion : 0.20 (15.0.0.0)
DistinguishedName : CN=Yyyyyy,OU=xxxxx.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NORP
xxxxxxx,DC=PROD,DC=OUTLOOK,DC=COM
OrganizationId : NORPxxxxxxx.PROD.OUTLOOK.COM/Microsoft Exchange Hosted Organizations/xxxxx.onmicrosoft.com
- NORPxxxxxxx.PROD.OUTLOOK.COM/ConfigurationUnits/xxxxx.onmicrosoft.com/Configuration

\"

This is a user that was made onprem and dont get mailbox

\"

PS C:\\Windows\\system32> get-exorecipient email address removed for privacy reasons

ExternalDirectoryObjectId : ffffffff-0dd5-4cfd-bd03-ffffffffffff
Identity : Xxx Xxxx
Alias : xxxx
EmailAddresses : {SIP:email address removed for privacy reasons, SMTP:email address removed for privacy reasons, X500:/o=Xxxx Exchange/ou=Exchange Administrative G
roup (FYDxxxxxxxxxxxx)/cn=Recipients/cn=Xxx Xxxx13b}
DisplayName : Xxx Xxxx
Name : Xxx Xxxx
PrimarySmtpAddress : email address removed for privacy reasons
RecipientType : MailUser
RecipientTypeDetails : MailUser
ExchangeVersion : 0.20 (15.0.0.0)
DistinguishedName : CN=Xxx Xxxx,OU=xxxxx.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=N
ORPxxxxxxx,DC=PROD,DC=OUTLOOK,DC=COM
OrganizationId : NORPxxxxxxx.PROD.OUTLOOK.COM/Microsoft Exchange Hosted Organizations/xxxxx.onmicrosoft.com
- NORPxxxxxxx.PROD.OUTLOOK.COM/ConfigurationUnits/xxxxx.onmicrosoft.com/Configuration

\"

The command  Set-User email address removed for privacy reasons -PermanentlyClearPreviousMailboxInfo does not clear the \"MailboxLocations\" from the EXO.

I had problem when migrating an on prem mailbox to EXO (hybrid). User A was offboarded and disabled on the on-prem. The disabled user A's mailbox is connected to user B. Now, user B has the ExchangeGUID of user A which is correct.

After the delta sync, when I run the migration of user B to EXO I get the below error.

Error: RecipientGuidMismatchPermanentException: Recipient's GUID '00000000-0000-0000-0000-000000000000' does not match the expected value 'xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx'. This issue could occur if mailbox guid 'xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx' is stamped on multiple recipients. Check for the potential mailbox guid conflict, eliminate it and try again.

So to identify which recipient has the same mailbox GUID I ran get-recipient 'xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx' and the result gave me only user B.

But when I run get-user 'xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx' then it showed me both user A (mailuser) and user B (mailuser). 

I deleted User A from Azure AD and then started the migration for user B and it went ok.

User A MailboxLocations has a stamp of mailboxGUID 'xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx' which was casuing the conflict. 

Thanks for the reply, but is that really the first step? Or I might have missed it?

I'm referring to this migration guide which gives the following pre-requisites:

• Create a subdomain for mail routing to Microsoft 365 or Office 365
• Create a subdomain for mail routing to your Google Workspace domain
• Check Google Cloud platform permissions
• Provision users in Microsoft 365 or Office 365

The provision users section says:

Before proceeding with either method, make sure that Mail Users have been provisioned for every user in the organization who will be migrated (either now or eventually). If any users aren't provisioned, provision them using the instructions in Manage mail users.

What's interesting is the paragraph that follows that one.

For more advanced scenarios, you may be able to deploy Azure Active Directory (Azure AD) Connect to provision your Mail Users. See Deploy Microsoft 365 Directory Synchronization in Microsoft Azurefor an overview, and Set up directory synchronization for Microsoft 365 for setup instructions. Then, you need to deploy an Exchange server in your on-premises environment for user management, and mail-enable your users using this server. For more information, see How and when to decommission your on-premises Exchange servers in a hybrid deployment and Manage mail users. Once the Mail Users have been created in Microsoft 365, the Azure AD Connect may need to be disabled in order to allow the migration process to convert these users into mailboxes - see Turn off directory synchronization for Microsoft 365.

I hadn't thought of it before, but connecting the above paragraph with the scenario I mentioned and this blog post almost seems to suggest that the workaround is setup an Exchange on premise server! It would be nice if there was a better way of course; that's a lot of rigaramole.

There is a few variables here but if the users already have a mailbox setup that shouldn't prevent you from doing a Gsuite migration to Exchange Online. In fact giving them a license and setting up mailbox/forwarding is the first step. 

reading the tea leaves... if you need to sync local AD users to Azure AD use hard match to match your existing cloud only objects. 

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/hybrid-identity-getting-users-aligned/ba-p/2274690

I know this was originally meant to aid in migrating Exchange on premise users to Exchange Online; however, the same use case exists today for migrating Google Workspace to Exchange online.

If anyone from the The_Exchange_Team is reading, is it possible to accomplish the same result (i.e.-PermanentlyClearPreviousMailboxInfo) during a Google Workspace to Exchange Online migration?

I suspect there might be quite a few customers who:

• Use Googe Workspace for Mail and Calendar
• Use Microsoft Teams, and therefore have cloud licenses for Exchange online for all or most users
• Use M365 apps like Word, Powerpoint, and Excel online
• Likely have Sharepoint and maybe even OneDrive content that can't be deleted
• Later decide to migrate from Google Workspace to Exchange for mail and calendar
• Are now stuck wondering if the migration tool will work or not, as all users already have mailboxes

Case

Users have mailbox on-prem and in EXO(not used). In order to migrate user, the EXO mailbox needs to be removed.

Mailbox didn't go away; I was running command Set-User xxxxx-PermanentlyClearPreviousMailboxInfo.
Nothing happends.

Solution

It all worked out after I removed the \"Information Protection for O365 – Standard and Exchange Online license”. Then mailbox disappeared immediately, and users could be migrated from on prem to EXO.

Hold

Mailbox may have some lock on it.

Get-mailbox xxxxx | select UserPrincipalName, name, RecipientType, *Hold*

Set-Mailbox xxxx@xxx -RemoveDelayHoldApplied