Moving AzureAD synced account to cloud only

Hi Dean, 

Welcome to Microsoft Q&A Forum! 

Have a good day and I hope you're doing well! 

Based on my research, this behavior can occur when the synchronization link between your on-prem AD and Azure AD hasn’t been fully released, even after deleting the user in Active Directory. Azure AD still considers the account “synced,” so it blocks direct changes to the OnPremisesImmutableId property even when you try to set it to $null through PowerShell. 

Here’s how you can troubleshoot and cleanly move the user to a cloud-only state: 

1. Confirm synchronization status 

On your Azure AD Connect server, check if synchronization is still running: 

Get-ADSyncScheduler 

Reference: Microsoft Entra Connect Sync: Scheduler - Microsoft Entra ID | Microsoft Learn 

If it’s still active, temporarily stop or disable synchronization to prevent the user object from being recreated. 

Import-Module ADSync
Set-ADSyncScheduler -SyncCycleEnabled $False

Reference: Disable the synchronization scheduler

2. Verify the user’s sync properties 

Run: 

Get-MgUser -UserId ******@company.com | OnPremisesSyncEnabled

Reference: Get-MgUser (Microsoft.Graph.Users) | Microsoft Learn 

If OnPremisesSyncEnabled is True or the ImmutableID field isn’t empty, Azure still treats it as synced. 

1. On your Azure AD Connect server, open Synchronization Rules Editor or the sync filter settings.
2. Exclude that user (or the organizational unit containing it) from synchronization scope.
3. Let a couple of sync cycles run, or pause the sync service temporarily.
4. Once you see OnPremisesSyncEnabled turn False in Azure, the account is free from AD Connect management.

Then, proceed to the next stage.

3. Choose a remediation path 

A) Keep the same user object 

Once sync is fully disabled, try clearing the ImmutableID using: 

Update-MgUser -UserId ******@company.com -OnPremisesImmutableId $null

If Azure no longer treats the user as sync-managed, this will succeed, and the account will become a true cloud-only user.

B) Clean rebuild **if Graph still rejects the change **

If the command continues to fail, the cleanest fix (and Microsoft’s official recommendation) is to delete and recreate the user as a cloud-only account:

1. Delete the user from Azure AD: 

Remove-MgUser -UserId ******@domain.com 

Reference: Remove-MgUser (Microsoft.Graph.Users) | Microsoft Learn 

2. Permanently remove it from the recycle bin: 

Remove-MgDirectoryDeletedUser -UserId <ObjectID> 

3. Recreate the user as a new cloud-only account: 

New-MgUser -DisplayName "User Name" -UserPrincipalName ******@domain.com -MailNickname "user" -PasswordProfile @{forceChangePasswordNextSignIn=$true; password="Temp@123"} -AccountEnabled $true 

References: New-MgUser

4. Verify 

Check the properties again to confirm: 

Get-MgUser -UserId ******@company.com | Select OnPremisesSyncEnabled, OnPremisesImmutableId 

Both should return False or empty, confirming the user is now managed purely in Azure AD. 

It’s a confusing issue because Azure holds a “memory” of the AD connection longer than expected, but once the sync is definitively off and the ImmutableID cleared (or the user recreated), the account will behave fully as a cloud-only identity. 

Hope this helps clarify and gets your environment stable again. If anything remains unclear or I’ve missed an aspect of your scenario, please feel free to reach out. I’ll be happy to take another look and help you move things forward. 

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".    

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.