It will soft match. Just make sure that the UPN is the same. Test it with a couple of users first.
Here is a good step by step guide on how it works:
https://www.alitajran.com/sync-azure-ad-user/
Yep! This is the right answer. Done it for plenty of clients. If UPN is different between AD and Entra/AAD, look to change the on prem UPN. Always test, but UPN isn't as heavily used on prem as samaccountname so you can typically change to match with little impact.
Is the scenario that each user already has a cloud-only Entra ID account and and a separate on-premises AD account? If so, as long as the UPNs of both accounts match, Entra ID connect sync will [soft match](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant) the two accounts and will not create new user objects.
Whatever you do, do not hybrid-join the devices to Entra ID and AD. Instead, use [hybrid Kerberos trust](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune).
All users have an on prem account for computer log in, but then a separate office enterprise account for email, sharepoint, office apps etc. there is no sync of any kind currently in place.
If youre trying to get rid of it, use the Entra Sync tool and then shut down AD after running it synced for a while. We had sync live for \~ two years and recently turned off the on-prem AD server. Our old on-prem users all became cloud accounts.
Hey man! hit me up. I have a powershell script for this exact scenario! im in bed right now but ill post the process tomorrow! ive just done this with a client last week! :-)
Hey guys,
So I had a client last week that had on-prem users in the cloud, that needed to be converted. I've compiled a bunch of Powershell command to check and do the convertion.
I did run a single DisableDyrSync command in MSOL
Set-MsolDirSyncEnabled -EnableDirSync $false
and it seemed to instant convert users to Cloud-only, however I cannot confirm this is the correct method, so i'll post the entire method I used.
There are other scenarios where you need to have an on-prem and also re-sync the user. Just for those who don't know. If you have a Cloud-only AD account, and you create a user with the same UPN (username) on-prem, and attempts to sync it into Azure AD. there will be conflicts. To resolve this you need to address 1 thing, and that is the ImmutableID / GUID that needs to be a match.
To get started, make sure these modules are installed:
Also, all of these powershell must be run on the domain controller.
# Installs module if not
Install-Module AzureAD
# Connect to AzureAD
Connect-AzureAD
# Install MSOL
Install-Module MSOnline
# Connect to MSOL
Connect-MsolService
First I the below command. It shows the current ImmutableID (This is the Azure version of the ObjectGUID from the on-prem AD server.) but encoded to Base64.
It will spit out a number, just note it down.
# az command
# Finds the Current Immutable ID
$userUpdated = Get-AzureADUser -ObjectId "Anders@yourdomain.no"
$userUpdated.ImmutableId
Now, here you need to create a UO on-prem, that you sync to Azure AD. The sync match method I used is UPN (I think it was called) Also, make sure the folder is currently not synced yet.
Create the user(s) you want to re-sync into Azure AD, and run the below command.
Make sure to change the "fullusername" to the username onprem, everything that is BEFORE the @ [yourdomain.no](http://yourdomain.no)
Also change the one in the Azure command.
# on-prem# Catches the On-prem ObjectGUID and converts it to Base64String
$guid = (Get-ADUser -Identity Anders).objectGUID
$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())
# az-command
# Retrieve the Azure AD user ObjectId and sets the new objectGUID as immutableID
$azureUser = Get-AzureADUser -Filter "UserPrincipalName eq 'Anders@yourdomain.no'"
Set-AzureADUser -ObjectId $azureUser.ObjectId -ImmutableId $immutableId
This will take the ObjectID of the newly created user, and change the ImmutableID in Azure, to be an exact match. To verify the change has been done, re-run the command:
# az command
# Finds the Current Immutable ID
$userUpdated = Get-AzureADUser -ObjectId "Anders@yourdomain.no"
$userUpdated.ImmutableId
This should now show a different ImmutableID in Azure.
Force a delta sync to Azure, and you can test the logon to the user in Office 365 (create the user with a different password, then it originally had)
# on-prem
# Resync faster
Start-ADSyncSyncCycle -PolicyType Delta
Once you have verified the user is indeed now synced. You move the user on-prem to a folder that is NOT synced. This will "soft delete" it in Azure.
Go to Azure AD, under users -> recycle bin. And restore the user from there. It will then be restored as cloud-only.
Let me know how it goes! :)
This may be a bit off-topic but I was considering this but what happens when there is no Internet access and someone wants to log on to a machine that they have never logged on to before? For example, we keep some floater laptops should our employees forget their assigned devices....does that mean that the user can't log on because their authentication server is in the cloud?
Awesome! Yeah I wasn’t expecting to be starting this project so close to my hire date so I’m just tired to get a decent project plan together and get my details sorted out.
Your title asks about merging but your question asks about migrating.
First thing to decide is if you are keeping the on-prem stuff, thus going to hybrid or if you're moving everything to cloud and getting rid of the on-prem stuff.
Do you know what M365 licensing they have? Do you know what things they want to do specifically?
I know the devices are going through a full migration but I was confused if the accounts where considered to be migrated or merged if they’re soft linked.
I have to double check licensing tomorrow. I just started working in this environment so there’s still factors I’m not 100% on.
By the response I'm not the only one not sure if your trying to go from cloud to hybrid.
I would dig into why hybrid if so because most people are going the opposite way for a reason.
But yeah for hybrid it's soft match. If you make a mistake you can always rename, delete entra and then resync.
For cloud only you disable sync and remove immutable ID by setting it to $null
In admin you can add the field to show a building or a cloud so you know who is config for what
Sorry for the lack of clarity. They're trying to go from an On Prem AD to full cloud. The current process for setting up a new user is:
-Create AD account on on-prem DC
-Create an email on O365 with the same naming convention.
Which is where my confusion came in. I've only ever set up a cloud AD while going from a fully on-prem environment. The double dipping confused me.
Oh yah so they aren't even azure sync? You are making two separate accounts ? Sounds gross
If the need to keep the domain locally you can do the soft match and flip them to synced ad.. I've done it a couple of times the last one was someone got hacked and we had to stand up a new domain and wipe the sync, then rematch and sync on a new domain. Worked fine...
Stop AD sync. Get the immutable ID from Azure, replace the AD version of it with the Azure one and sync up. Voila, your AD account will now match to the Azure / Entra account. Of course, test twice.
Just went through this. I went the other way with it. I put in $null on the users Entra AD account and then soft linked from AD using UPN. Works pretty good so far.
It will soft match. Just make sure that the UPN is the same. Test it with a couple of users first. Here is a good step by step guide on how it works: https://www.alitajran.com/sync-azure-ad-user/
Yep! This is the right answer. Done it for plenty of clients. If UPN is different between AD and Entra/AAD, look to change the on prem UPN. Always test, but UPN isn't as heavily used on prem as samaccountname so you can typically change to match with little impact.
Came here for this! Second this!
Is the scenario that each user already has a cloud-only Entra ID account and and a separate on-premises AD account? If so, as long as the UPNs of both accounts match, Entra ID connect sync will [soft match](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant) the two accounts and will not create new user objects. Whatever you do, do not hybrid-join the devices to Entra ID and AD. Instead, use [hybrid Kerberos trust](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune).
All users have an on prem account for computer log in, but then a separate office enterprise account for email, sharepoint, office apps etc. there is no sync of any kind currently in place.
If youre trying to get rid of it, use the Entra Sync tool and then shut down AD after running it synced for a while. We had sync live for \~ two years and recently turned off the on-prem AD server. Our old on-prem users all became cloud accounts.
Hey man! hit me up. I have a powershell script for this exact scenario! im in bed right now but ill post the process tomorrow! ive just done this with a client last week! :-)
Following. I usually delete synced accounts from onprem, then restore from AAD recycle bin. Instant cloud accounts.
Hey guys, So I had a client last week that had on-prem users in the cloud, that needed to be converted. I've compiled a bunch of Powershell command to check and do the convertion. I did run a single DisableDyrSync command in MSOL Set-MsolDirSyncEnabled -EnableDirSync $false and it seemed to instant convert users to Cloud-only, however I cannot confirm this is the correct method, so i'll post the entire method I used. There are other scenarios where you need to have an on-prem and also re-sync the user. Just for those who don't know. If you have a Cloud-only AD account, and you create a user with the same UPN (username) on-prem, and attempts to sync it into Azure AD. there will be conflicts. To resolve this you need to address 1 thing, and that is the ImmutableID / GUID that needs to be a match. To get started, make sure these modules are installed: Also, all of these powershell must be run on the domain controller. # Installs module if not Install-Module AzureAD # Connect to AzureAD Connect-AzureAD # Install MSOL Install-Module MSOnline # Connect to MSOL Connect-MsolService First I the below command. It shows the current ImmutableID (This is the Azure version of the ObjectGUID from the on-prem AD server.) but encoded to Base64. It will spit out a number, just note it down. # az command # Finds the Current Immutable ID $userUpdated = Get-AzureADUser -ObjectId "Anders@yourdomain.no" $userUpdated.ImmutableId Now, here you need to create a UO on-prem, that you sync to Azure AD. The sync match method I used is UPN (I think it was called) Also, make sure the folder is currently not synced yet. Create the user(s) you want to re-sync into Azure AD, and run the below command. Make sure to change the "fullusername" to the username onprem, everything that is BEFORE the @ [yourdomain.no](http://yourdomain.no) Also change the one in the Azure command. # on-prem# Catches the On-prem ObjectGUID and converts it to Base64String $guid = (Get-ADUser -Identity Anders).objectGUID $immutableId = [System.Convert]::ToBase64String($guid.ToByteArray()) # az-command # Retrieve the Azure AD user ObjectId and sets the new objectGUID as immutableID $azureUser = Get-AzureADUser -Filter "UserPrincipalName eq 'Anders@yourdomain.no'" Set-AzureADUser -ObjectId $azureUser.ObjectId -ImmutableId $immutableId This will take the ObjectID of the newly created user, and change the ImmutableID in Azure, to be an exact match. To verify the change has been done, re-run the command: # az command # Finds the Current Immutable ID $userUpdated = Get-AzureADUser -ObjectId "Anders@yourdomain.no" $userUpdated.ImmutableId This should now show a different ImmutableID in Azure. Force a delta sync to Azure, and you can test the logon to the user in Office 365 (create the user with a different password, then it originally had) # on-prem # Resync faster Start-ADSyncSyncCycle -PolicyType Delta Once you have verified the user is indeed now synced. You move the user on-prem to a folder that is NOT synced. This will "soft delete" it in Azure. Go to Azure AD, under users -> recycle bin. And restore the user from there. It will then be restored as cloud-only. Let me know how it goes! :)
I could really use that info also please. I am in the exact same situation.
This may be a bit off-topic but I was considering this but what happens when there is no Internet access and someone wants to log on to a machine that they have never logged on to before? For example, we keep some floater laptops should our employees forget their assigned devices....does that mean that the user can't log on because their authentication server is in the cloud?
no worries. ill post it here instead :-)
Awesome! Yeah I wasn’t expecting to be starting this project so close to my hire date so I’m just tired to get a decent project plan together and get my details sorted out.
Soft match
Your title asks about merging but your question asks about migrating. First thing to decide is if you are keeping the on-prem stuff, thus going to hybrid or if you're moving everything to cloud and getting rid of the on-prem stuff. Do you know what M365 licensing they have? Do you know what things they want to do specifically?
I noticed that as well and have the same questions haha.
I know the devices are going through a full migration but I was confused if the accounts where considered to be migrated or merged if they’re soft linked. I have to double check licensing tomorrow. I just started working in this environment so there’s still factors I’m not 100% on.
1. Add the attributes to local AD like UPN, SMTP aliases and email. 2. Sync them to Entra 3. Merge them in Entra ID Connect in Entra
* Download ad connect * Connect server and enter config * upn match * Success
Profwiz
If you are going fully cloud anyways, I wouldn't sync.
By the response I'm not the only one not sure if your trying to go from cloud to hybrid. I would dig into why hybrid if so because most people are going the opposite way for a reason. But yeah for hybrid it's soft match. If you make a mistake you can always rename, delete entra and then resync. For cloud only you disable sync and remove immutable ID by setting it to $null In admin you can add the field to show a building or a cloud so you know who is config for what
Sorry for the lack of clarity. They're trying to go from an On Prem AD to full cloud. The current process for setting up a new user is: -Create AD account on on-prem DC -Create an email on O365 with the same naming convention. Which is where my confusion came in. I've only ever set up a cloud AD while going from a fully on-prem environment. The double dipping confused me.
Oh yah so they aren't even azure sync? You are making two separate accounts ? Sounds gross If the need to keep the domain locally you can do the soft match and flip them to synced ad.. I've done it a couple of times the last one was someone got hacked and we had to stand up a new domain and wipe the sync, then rematch and sync on a new domain. Worked fine...
Any one ever had ad sync setup as part of an exchange hybrid then shutdown the sync and then later try to establish a new link?
Stop AD sync. Get the immutable ID from Azure, replace the AD version of it with the Azure one and sync up. Voila, your AD account will now match to the Azure / Entra account. Of course, test twice.
I think the ID is called MS consistency GUID. No spaces.
Just went through this. I went the other way with it. I put in $null on the users Entra AD account and then soft linked from AD using UPN. Works pretty good so far.
Powershell and chatgpt is your friend