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.
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.
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.
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:
test3@domain.com
Status: Failed
test3@domain.com Skipped item details
User status
Data migrated:
Migration rate:
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’.
To sync the user from the Cloud to on-premises you will need to follow these steps :
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 AD run 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”
From Notepad checking the user 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 test3@domain.com |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 match the on-premises user’s ImmutableID.
Once done, Go and force ADConnect to sync the user and you’ll see if the problem has been resolved. The command for changing the Immutableid is as follows:
Set-MsolUser -UserPrincipleName test3@domain.com -ImmutableID IkTni9mw7Ee4YefeGpz7IA==
Ref:
https://docs.microsoft.com/en-us/exchange/hybrid-deployment/create-cloud-based-archive
Reset and manage your Active Directory users' Passwords Active Directory is one of the most…
Finding Exchange Database hidden mailboxes. Story:Maybe you have been in this situation before, trying to…
If you're using a Proxy server in your firewall or in your network and have…
Story:I got some clients that have reported some of their users being locked out and…
Delegate Permissions This is a code that I have wrote recently to check if an…
Story: I got a request from a client who constantly gets CVs and have to…
View Comments
Prior to enabling Azure AD Connect, all email accounts were migrated to Exchange Online. Some users had access to network resources through On-premises AD and others had only accounts on M365 for email, and many had both.
After establishing Azure AD Connect and sync, most accounts from the On-premises AD synced and are OK with a single password to use for network login and Office / Outlook apps. ( A couple of accounts remained separate, and I don't know why).
There are also a number of accounts that never had a need for network logins but have mailboxes on the domain. They appear in AAD but not in the On-premises AD. This still requires administration for these two separate groups from two places.
My questions are:
1) What happens if someone with a cloud-only account develops a need to login to the local domain? Will they need separate accounts or can they somehow be synced?
2) Can others with cloud-only email accounts be incorporated into the On-prem AD?
The case above seems to indicate there is a resolution, but it also seems complicated by involvement with the Hybrid Exchange environment.
Hi Richard,
1- My article presumes that you actually don't have a mailbox or an AD account on-premises so you can create the account on-premises and make sure that UPN matches the Cloud user's UPN and then you'll have to copy the on-premises user's immutable ID or GUID into the Cloud one so there wouldn't be any AAD syncing issues.
2- Yes absolutely, You will have to create those users with matching UPN and SMTP address then copy their immutable ID to cloud users. There's no risk of affecting the cloud users at all. for bulk users you can download CSV of the user list on cloud and bulk create it using the free version of "ADUC Admin Plus" after making sure that the required columns of CSV are filled properly.
Hi,
I have inherited a 365 tenancy and have a couple of users who had been created on the cloud and mailboxes are live and in use for some time.
The same users have also been created in on-prem AD after the cloud accounts.
The issue is I can add to on-prem security group but AAD sync doesn't update the group or any AAD synced groups.
I believe this is a possible solution? Or am I better off just binning off the accounts and recreate from scratch?
Hi Mark, yes indeed this should be the solution by matching the Immutable ID on the on-prem AD and sync it to the Cloud or force it by using set-msoluser -immutableid parameter and then force ADconnect to sync.
ofcoursre it might differ if ADconnect is setup to use a different attibute as the source anchor.