Forum Discussion
Convert On-Prem AD Users from Office 365/Azure AD to In-Cloud accounts
Hi We have currently setup a ADConnect Sync to Office 365, this is working well. We would like to start converting Sync'ed accounts in Office 365/Azure AD to "In Cloud" accounts. Can you advi...
I have tested this scenario half a year ago because I have a client who will need the same. Worked out well. Please try this in a lab environment first.
#Requirements: Managed domain, Global Administrator, Domain Admin, Active Directory Users and Computers, AD Connect, PowerShell-modules MSOnline & ADSync
#Connect with MSOL
$credential = Get-Credential
Connect-MsolService -Credential $credential
#Check DirSync status
Get-MSOLCompanyInformation | select DirectorySynchronizationStatus
#Backup all ImmutableIDs of federated users
Get-MsolUser | select userprincipalname,immutableid | sort userprincipalname | Export-Csv -Path $env:USERPROFILE\Desktop\ImmutableIDs.csv -NoTypeInformation -Force
#Migrate synced user to cloud only
Step 1: Disable DirSync
Set-MsolDirSyncEnabled -EnableDirSync $false
Step 2: Nullify ImmutableID !!! Make sure you add quotation marks to $null
Set-MsolUser -UserPrincipalName user@domain.com -ImmutableId "$null"
Step 3: Move nullified users to non-synced OU
Step 4: Enable DirSync
Set-MsolDirSyncEnabled -EnableDirSync $true
Step 5: Force AD Connect sync
Start-ADSyncSyncCycle -PolicyType Delta
#Revert migration of user
Step 1: Disable DirSync
Set-MsolDirSyncEnabled -EnableDirSync $false
Step 2: Move user to original OU
Step 3: Put back the ImmutableID of the user
Set-MsolUser -UserPrincipalName user@domain.com -ImmutableId "ID"
Step 4: Enable DirSync
Set-MsolDirSyncEnabled -EnableDirSync $true
Step 5: Force AD Connect sync
Start-ADSyncSyncCycle -PolicyType Delta
After converting an on-prem user to a cloud user, by nullifying the ImmutableId, has anyone been able to verify that the PowerShell command, whoami, returns AzureAD\username instead of ONPREM\username ?
This is the issue we're currently experiencing and we are concerned with any possible adverse affects it might cause to the AzureAD user object functionality and stability. We're currently not experiencing any visible issues at the moment, however. -Josh
Josh-M I tried looking into this as well, I did receive some information from Microsoft. I still don't know if this causes any issues, it doesn't seem to negatively impact anything in a sandbox environment. Also with one user in a production environment.
"This a known gap, that we're reviewing. Even though you have migrated the user from AD to Azure AD, the onprem SamAccountName is still intact on the user object, among other on-prem AD attributes. As a result, Azure AD picks those details and shows domain/user instead of AzureAD/user. This attribute cannot be modified or cleared through Graph APIs at this point, so there's no way to change the behavior. Please file a UserVoice suggestion on MS Graph for this so that our teams can get the feedback and prioritize it as needed"
Source:
https://github.com/MicrosoftDocs/azure-docs/issues/38048#issuecomment-528570435
Friends, please vote here to allow this topic and feature request to gain traction to allow conversion of users properly.
- Whoami will always execute in the context of the account logged onto the desktop. If your computer is part of an AD domain and you'velogged on with a domain account, it will be DOMAIN\USER.
I never thought about it until you mentioned it now. whoami returns ONPREM\username for my converted user. I would assume that is because the user is still in an on-prem OU. While that OU is not synced with ADSync, the metadata for that user is still there.
This computer was built from new and only using the AzureAD username so I'm sticking with it being the metadata.
Josh-M Hi Josh, it's an interesting question and it comes up in my mind every now and then. I haven't had any trouble in my lab with users or Microsoft services. Though the lab did not run for long time and I cannot remember what whoami would return.
I have planned the conversion for my client in a few months. This is a 150 seat tenant with only saas apps and all data stored in sharepoint/onedrive. I don't foresee any issues in this scenario, but perhaps your infra is more complex.
Keep us posted, thanks.It’s a good question and I’ll double check in the morning on our tenant.
I do know though that after migrating users to on-cloud and removing the immutable ID, the authentication in tools like Outlook went from being domain\username to email address.
I’ll post back in the morning.
