Convert On-Prem AD Users from Office 365/Azure AD to In-Cloud accounts




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 advise or does anyone know how we might approach this? Or can point to alternative resources?


We need to ensure the accounts in Office 365/Azure AD remain active and usable.


Much appreciated



60 Replies
You could terminate the account in Active Directory (which would terminate the account in AAD/O365) after forcing a delta sync, then login to O365 admin center and "reactivate" / "undelete" the account and assign it a license (if it doesnt remember the license it had).

There may be other routes, but I know that should accomplish what you need.
Thanks Brent, I will try this out.




I have tried removing the user and re-adding however, this prompts me for a new password. Is there a way to move the user account from On-Prem AD to Azure AD?


Currently the users i want are using AD Connect, however most of the users do not need full AD accounts just email which is in Office 365. So we want to remove them from the local network only but keep in Azure AD.


Any ideas?



The authority for an AD Synced account will always be Active Directory, which means that management happens in AD. To make accounts (and that means ALL synced accounts at once) cloud managed accounts, you will need to disable directory syncing.


I have not done this so you MUST test this before implementation. Disabling and re-enabling will result in duplicate accounts. The command to use would be Set-MsolDirSyncEnabled –EnableDirSync $false.

This will work just fine. When you execute the command Set-MsolDirSyncEnabled –EnableDirSync $false. You disable the Dirsync (when you execute it can take up to 72 hours to get it done). After this all the users in the office365 tenant will keep there password what they have at that moment. Visualy it just removes the collum where it now says In Cloud/ Synchronized with active directory.


When you have done this you can execute the command get-msolcompanyinformation to check if the sync is really gone.


*note: the azure ad connect is still on the server so when you reboot that server there is a chance that the Sync will be enabled.




Brent is correct if you only need to convert a few accounts. When you recover the deleted user, it will ask you to set a new password since it is now "In Cloud" and not managed by your local AD sync.
It should also reconnect to the previously associated mailbox. You will have to provide the new temp password to your user and have them change at first logon.

If you need to convert all to cloud, then the disabling of AAD Sync is the way to go.

If you only need to do this for a subset of accounts, you can simply move users to an OU which is not synced (assuming that you've configured to sync only selected OUs). After the sync runs, users are "deleted" from cloud. Run the following command to restore the users.

Get-MsolUser -ReturnDeletedUsers | Restore-MsolUser

With this scenario, users are restored "as they were", so there is no need to give a new password. However, you should notice that if users are changing their passwords, they must follow the Office 365 password policy (8-16 characters etc.).

This method worked great for me.  We are converting our shared mailboxes to be native in the cloud (for a lack of a better.  It pulls over aliases, forwarders, delegations etc.  Great stuff!


we have been using that method succesfully in the past. 

Weirdly, now some users get deleted and need to be recovered repeatedly (within 10-30 minutes). 

Unfortunately I haven't been able to identify what made these deletions stop. 

Anyone experiencing this?




I had the same thing happen.  They quickly restored.  Oddly enough, these were shared mailboxes.  For a regular user, I could see this happening if there were no license; in fact I think this is designed behavior.

I am especially concerned about mailboxes that hit the 30 day deletion time.  Have you had any go that long?  This is why I haven't yet done a large implementation-still testing.



I had it stop within the day. I've tried to reproduce the behavior. 

It seems, that it stops when I do the following: 

1) On the local server, remove the user from the Azure Synchronization group

2) reactivate on Office365 (user now "in cloud")

- User keeps being deleted

3) rejoin the user to the sync group on the local server (user is now "AD synced")

4) remove from sync group

5) reactivate on Office365 (user now "in cloud").

- So far it works for the latest user I have been moving today. 


Edit: I guess I jinxed it, user is deleted again . 

I had to recover the user one more time and then it stopped. Nothing I did.
This is happening for me as well, only tried it today for the first time.

The user re-deletes when the dirsync runs, happened twice in a row.

The latest batch I did, I blocked the credential immediately after undeleting the account.  I did this yesterday and the accounts are still there.  I would be interested in knowing if this works for anyone else.

Get-MsolUser -UserPrincipalName <useraccount> |Set-MsolUser -BlockCredential $true

This re-deletion of users is a totally new phenomenon for me which I need to test myself too.


Anyways, technically the objects in AAD are linked to the AD objects with ImmutableId attribute. So you could try to delete this link by emptying the attribute using the following command before restoring users:

Get-MsolUser -ReturnDeletedUsers | Set-MsolUser -ImmutableId ""

Let me know whether this helped.

Note! DO NOT do this if you are using federated identity, as it is using ImmutableId to identify users.

Before I left on Friday I recovered the user and then blocked them as suggested, they were still there today and hadn't been deleted. I just unblocked the user and waited until the dirsync had run and they're still there so that did seem to work yes. I mainly need to do this to get my shared mailboxes off premises and into the cloud so I suppose that would work OK, people should still be able to access them if they're blocked? Seems like a bug though!

I am going thru the same emotion here. I have the same project going with shared mailboxes.  I did the same kind of testing.  My resource accounts are still here.  I think I am ready to do a pilot group of 20 resources.

As far as blocking the logins, the resources should continue to function fine.  We have all of our cloud based resources set that way and have had no issues.

I will let you know how my pilot goes.  

I've migrated most of my normal users now so was just checking this conversion of shared mailboxes again.


The work around of blocking the user seems to have stopped working since last week, blocked users now re-delete themselves when the dirsync runs.


Has anyone opened a support ticket about this?