I have got this client who constantly keeps on making the mistake of create user from Cloud and provision them with a license in an Exchange Hybrid environment.
Although this is not difficult to fix but it’s not the recommended approach when creating a new user especially in a Hybrid environment since Exchange on-premises won’t recognize this user and most likely will consider any incoming emails from it as spoof or spam.
How to Create a Cloud user from Exchange On-premises?
From Exchange on-premises ECP Admin panel you have the option to directly create user on-cloud which will also create a user object on on-premises AD.
Second option – Using Powershell
It’s not that much different than the Web UI option but it’s just for people who prefer using PowerShell than GUI
Enable-RemoteMailbox –Identity User –RemoteRoutingAddress user@yourTenant.mail.onmicrosoft.com
The reason to follow those two methods is due to the need of Exchange on-premises being aware of each of those users so mail flow between Exchange on-premises and Online would not get affected and route this users mail to the wrong place or flag it as spammed or spoof …etc.
The Real Question now is: How to Sync Cloud User to On-premises AD ?
If by mistake we created a user on Cloud (Office 365) and we forgot to create an AD User for this account, that user might already have started using his account on Office 365 (Sharepoint, Exchange, Teams) etc.
There also might be the intention of moving users from Cloud to On-premises Exchange in case the company wanted to decrease their spending on cloud users and in this case when Migrating a cloud user to on-premises you will get the following errors:
email@example.com Skipped item details
Last successful sync date:
Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ’03c9764e-8b8e-4f33-94d1-ef098c4de656’. –> Cannot find a recipient that has mailbox GUID ’03c9764e-8b8e-4f33-94d1-ef098c4de656’.
So how do we overcome this situation since syncing a user might require you to delete the cloud user and recreate it on AD?
To sync the user from the Cloud to on-premises you will need to follow these steps :
1- Create an on-premises Mailbox where the following attributes would be matching the cloud user
2- The Location of the OU where the On-premises user is going to be created must be provisioned by ADConnect (Azure AD Connect)
You can look which of these OU are provisioned by Starting AD Connect Sync Manager
By verifying the user you created in the AD is in the right OU, You can now start AD Sync from PowerShell to speed up the process.
Below, You can see the user has been successfully synchronized to the cloud without any issue.
Now we’ll see it from the portal to confirm the user is synced with AD
Depending on the Source anchor being used in ADConnect there might be a GUID conflict or not, You will get an error similar to when trying to migrate the user in the beginning however you can solve this by replacing the cloud user’s GUID (ImmutableID) with the on-premises user which will force the user to merge with the On-prem user.
Let’s confirm in our case if the user on-cloud has a matching GUID with the one on-premises.
From CMD or Powershell you can use the following command to get the user’s ImmutableID (ObjectGUID) .
ldifde -f c:\Test.txt -d “cn=Test3,DC=Domain,DC=com”
Checking the notepad we just exported you can see the Immutable ID on AD for the User test3 is IkTni9mw7Ee4YefeGpz7IA==
To be able to see the user on Office 365, We need to logon to MSOL through Exchange Online powershell
Connect to Exchange Online’s powershell using your Online ECP.
Once you click on Configure this should download an executable file that will launch PowerShell Online which allows you to use the Modern Authentication (MFA) to use PowerShell safely.
Connect-Msoluser will connect you to Office 365 and you’ll be able to get the user’s properties and see if the Immutable ID is matching to the user’s GUID.
Once you’re connect you can use the following cmdlet to get the user’s properties.
Get-MsolUser -UserPrincipalName firstname.lastname@example.org |fl DisplayName,ImmutableID
You can see they are matching each other, In case there’s a conflict then you can simply set the online user’s Immutable ID to the on-premises user and that should solve the problem.