Feb 01 2017
- last edited on
May 24 2021
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.
Feb 01 2017 10:01 AM
Feb 06 2017 01:44 PM
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.
Feb 06 2017 10:56 PM
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.
Feb 27 2017 11:17 PM
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.
Nov 07 2017 01:55 PM - edited Nov 07 2017 02:08 PM
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.
Nov 19 2017 10:15 PM
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.).
Apr 10 2018 10:38 AM
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 everything...email aliases, forwarders, delegations etc. Great stuff!
Apr 12 2018 07:05 AM
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?
Apr 12 2018 07:21 AM
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.
Apr 12 2018 10:20 AM - edited Apr 12 2018 10:22 AM
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 .
Apr 13 2018 03:09 AM
Apr 13 2018 06:36 AM
Apr 13 2018 08:19 AM
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
Apr 13 2018 08:46 AM
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.
Apr 13 2018 09:04 AM
Note! DO NOT do this if you are using federated identity, as it is using ImmutableId to identify users.
Apr 16 2018 04:41 AM
Apr 16 2018 07:42 AM
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.
Apr 19 2018 05:17 AM - edited Apr 19 2018 05:17 AM
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?