If you’re utilizing Entra Connect and planning to phase out Active Directory, you’ll eventually need to uninstall Entra Connect and transition all users to cloud-managed identities. Entra Connect links your AD identities with Entra, providing users with a cloud identity alongside their on-premises identity. Despite this, AD serves as the management authority. Users and groups synchronized through Entra Connect must be managed in Active Directory, and any changes to those accounts are synchronized back to Entra. Therefore, when you’re ready to switch to cloud-managed identities, you have two choices: convert groups of users gradually or bulk convert all users at once.
The simplest method for individual conversions is to move the target users to an Organizational Unit (OU) that Entra Connect is not synchronizing. During the next sync cycle, that user will be deleted in Entra (as it assumes the user was deleted from AD). If you restore the user in Entra, the identity will become cloud-managed. This approach works well for small groups, but for bulk conversion of all users, follow the steps below.
Before proceeding with these steps, ensure that Entra Connect is uninstalled or that its services are halted. Ideally, you are doing this as part of a broader plan to decommission your Active Directory soon after. If the Entra Connect services remain active, and directory sync is re-enabled in your tenant, syncing will resume.
If you have Entra Connect in operation, you will see user identities and groups synchronized from AD, similar to the screenshot below. To fully manage them as cloud identities, we want them to display the cloud icon.
The same management limitations apply to synchronized distribution and security groups. In the example below, this synchronized distribution group can only be managed through Active Directory or Exchange. If we want to include a user in this distribution group, it must be done in AD while the group synchronization is active.
Converting all synchronized objects to cloud-managed is quite straightforward. Open PowerShell and install the MSOnline Module Microsoft Graph Authentication module, and then connect to your tenant with Direct.
Install-Module Microsoft.Graph.Authentication
Connect-MgGraph -Scopes "Organization.ReadWrite.All"Using the deprecated MSOnline module may lead to an authentication error since it is no longer supported in most tenants.
We need to turn off Directory Synchronization in the tenant to convert all synchronized users to cloud users. You can check the current value of the OnPremisesSyncEnabled property:
Get-MgOrganization | FL *
Setting the OnPremisesSyncEnabled value to $False will deactivate directory sync at the tenant level. You can accomplish this with the following command. We first need the tenant ID for the update command, so we will assign that as the $id variable and use it in the next command:
$id = Get-MgOrganization | Select -expandproperty ID
Update-MgOrganization -OrganizationId $id -OnPremisesSyncEnabled:$FalseIf we run our previous command again, we should see a null value for the OnPremisesSyncEnabled property:
This value may change to False or become null immediately. However, your users may continue to appear as synchronized in Entra/M365 for up to 3 days. In my experience, this has usually taken 30 minutes or less, but as per the official Microsoft documentation, it could take over 72 hours depending on the size of the tenant.
If you still have Entra Connect active, which I do not recommend, you can initiate a delta sync from the Entra Connect server. It will indicate success; however, if you check the synchronization service, you’ll find that the Entra Connect server displays as stopped-server-down, unable to complete the synchronization tasks. This reinforces why you need to decommission your Entra Connect setup. If someone mistakenly re-enables DirSync for the tenant, Entra Connect will resume syncing identities as before.
Upon returning to our M365 admin portal, we can confirm that our users are now all cloud-managed. Keep in mind that this may require several hours to days; however, in smaller tenants, it typically takes less than an hour.
Our groups are also now cloud-managed, retaining the member list intact. While the groups might not have any owners, this is a minor drawback since the members remain.
Now that it’s cloud-managed, adding members is possible.
The same applies for security groups:
Optionally, you may clear the ImmutableID for cloud users that were previously synchronized from Entra Connect. The immutable ID serves as the source anchor linking the on-prem identity to the cloud identity (with the AD attribute being mS-DS-ConsistencyGUID). Clearing the ImmutableID will create the impression that this cloud identity was never synchronized with Entra Connect. This is relevant only if the tenant is ever re-synchronized with Active Directory, which is quite unlikely; nonetheless, I will explain the process.
First, we need to connect to MgGraph Beta with the appropriate permissions. As of this writing, we can only view the user immutable ID using the beta SDK:
Install-Module Microsoft.Graph.Beta -scope currentuser
connect-mggraph -scopes "user.readwrite.all"Here’s an example of a user created by Entra Connect that has a value for ImmutableID. You should look for the OnPremisesImmutableId attribute. Users created natively in the cloud will not have this value.
Get-MgBetaUser -userid youruser@smbtothecloud.com | FL *
To retrieve all users with this attribute set:
$users = Get-MgBetaUser -All | Where-Object {
$_.OnPremisesImmutableId -ne $null
}
$users
We can then clear the attribute for all users:
foreach ($user in $users) {
try {
Update-MgBetaUser -UserId $user.Id -OnPremisesImmutableId $null
}
catch {
Write-Warning "Failed to clear Immutable ID for $($user.UserPrincipalName): $_"
}
}Finally, check to confirm that it has been cleared for one of the users:
If at any point you need to re-enable directory sync for the tenant:
Update-MgOrganization -OrganizationId $id -OnPremisesSyncEnabled:$True