Allow Conversion of AD Synced Accounts to "In Cloud Only"
Up until recently, we were able to convert a user which was AD Synced to a cloud account by moving it to an OU in AD which was not synced.
After the next sync, Office 365 would move it into the deleted folder. If you recover it, it goes into a cloud account. As of a few weeks ago, Microsoft disabled this.
Looking at countless threads around the internet, and speaking with representatives from Microsoft Office 365 support, everyone is frustrated with this change, and wants it changed back to the way it was.
We are aware of the requirement to be able to convert a synced user to cloud only and are designing that feature, but we have no timelines to share right now.
We reverted the change that would block the “hack” to delete and restore a user to change a user to “Cloud Only”.
I have exactly the same problem now (on-prem->Azure AD->Azure AD DS).
After going through the "ImmutableID " hack, i experienced the below.
Restoring a deleted user in O365/Azure AD (now cloud-only) does not restore/recreate the account in AADDS automatically.
I have to manually update its Azure AD Group membership (remove/readd - only the ones which sync to AADDS) - this will recreate the account in AADDS and set its proper group memberships.
It gets worse if you use dynamic groups as well, because you have to change the rules to "update" the group membership.
This is so painful and breaks the user experience for quite some time, because they loose access to legacy apps which rely on AADDS.
Nick Romanek commented
We are trying to jump on the wave to migrate everything to the cloud but not having this feature makes it much more difficult and time-consuming. Can we please get this implemented soon?
Cabrera, Tai commented
We have the same issue. We need to move users off one by one or in groups. Moving the entire organization at the same time is not feasible for us as we still have some users using network assets and need to be phased out of the domain slowly. Admin said that they reverted the change that would block the "hack" but it doesn't appear to work. Tried restoring user in O365 only to have it delete every time adsync runs.
What a painful issue, we also have the same requirement for a handful of customer accounts. The sync accounts need to be cloud only. Trying to find a way in numerous threads to prevent the accounts logon to the local domain.
Really need a way of converting groups synced from on prem ad to cloud only! deleting and recreating is not the one!
David, for us the issue with doing it that way was that we wanted to do a slow roll. We didn't just want to flip the switch for all users in our org at the same time. That's why we ended up going the route I mentioned below. It was clunky, and Microsoft should have a better way, but I am happy to report that things are much easier to manage now that we're no longer tied to AD/Exchange.
David Schrag commented
Are we sure that the answer isn't as simple as running "Set-MsolDirSyncEnabled -EnableDirSync $false" in Azure AD / PowerShell? Look at https://docs.microsoft.com/en-us/troubleshoot/azure/active-directory/cannot-manage-objects. It says you can run this command if "you want to manage objects in Office 365, Azure, or Intune and you no longer want to use directory synchronization." Isn't that exactly what we're trying to do? Of course, I'm afraid to try it in my production environment unless I'm sure it will accomplish the task properly.
Rasti Mohammed Amin commented
This is really needed in our environment, so many disabled accounts. AD become a graveyard.
Stefan Rairigh commented
This need/issue has been around for many years. There NEEDS to be a method to convert an AD sync'd account to cloud-only. Our need is based on a similar scenario to many others:
-All employees have AD/Sync'd accounts initially created on the local AD.
-An Employee leaves the company.
-We convert the user mailbox to shared, and grant permissions to the former employee's supervisor so they can have access to the former employee's mail.
-We remove the O365 license from the user account in the cloud (freeing up a 365 license).
-We disable the user account on the local AD.
-We are now stuck having a growing list of disabled accounts on the local AD because if any of them are deleted from the local AD, this deletion will replicate on the next ADSync and the respective, now shared mailbox in the cloud will in-turn be deleted.
There is a true and valid need to have a proper procedure (that will not be broken by updates) for converting an AD sync'd account to a cloud-only account. When will this be addressed/resolved?
Looking for any updates as well, looking to decommission local synced environment.
Mike Donnellan commented
Hi Azure AD Team, back running my basement lab again and am surprised that this is still an issue. Any updates? Thanks.
With the ADMX templates now available within Intune, and SharePoint ready for the masses to use as a full time document management system I want us off of our server.
The on-prem server is so many moving parts that are so risky. We just need to move away from it all together.
With no update over a year later, and given the mass cloud-adoption in COVID, and the recent surge in attacks I wished this would have been done.
I would be excited with even a timeline
Mike Deliberto commented
Any update on this? ImmutableID feels like a hack.
An update on this would be nice. I have 200 distribution groups I would like to convert
I've tested this in a lab and after 48 hours dirsync cannot be re-enabled. Best avoided I think.
Karl Schutte commented
Has anyone tried this method with any success? Looks like it does not require the deletion / restore of user accounts.
Migrate to the cloud today*!
*But not actually today as we don't actually provide a way to do that but their some hacks in user forums which we broke. We will fix it sometime in the future, but not this year, or next, it's planned, eventually.
I 100% agree this should be an option. In the meantime, I have figured out a way to manually disconnect objects (through a LOT of trial and error). Here's how to do it via PowerShell, AD Users & Computers, and O365 Admin Portal for anyone who's interested.
[Connects to the Microsoft Online service. Authenticate with global admin credentials.]
Set-MSOLUserPrincipalName -UserPrincipalName firstname.lastname@example.org -NewUserPrincipalName email@example.com
[Changes the UPN from the AD domain to the O365 domain, so you can alter the immutable ID. This is a temporary change. The last step will be to change it back to the original UPN.]
Move account to OU that doesn’t sync in AADC utility (or just delete)
[You can open the AADC utility and check the configuration if you’re unsure which OUs sync with O365/Azure]
Start-ADSyncSyncCycle -PolicyType Delta
[Starts a delta sync from AD to O365/Azure to delete the users you’ve moved out of scope]
Start-ADSyncSyncCycle -PolicyType Delta
[IMPORTANT: Once account(s) show up in deleted users in O365, run the sync command again and wait until it finishes. This ensures that the account(s) are properly disconnected from AD. Otherwise, AD will think they’re out of sync and will keep deleting them from O365.]
[Use this to confirm the second sync cycle has completed before proceeding with the following commands. SyncCycleInProgress: should be False]
Restore User(s) in O365
[Choose password settings as you see fit.]
Set-Msoluser -UserPrincipalName firstname.lastname@example.org -ImmutableID email@example.com
[Set the immutable ID to ANYTHING. We decided to use our Okta username/primary email address/AD UPN, but it can literally be anything. We tested several different values and, in our case, as long as we set the login name in Okta to match, all was well.]
Set-MsolUserPrincipalName -UserPrincipalName firstname.lastname@example.org -NewUserPrincipalName email@example.com
[Switching the UPN back to the original now that we’ve disconnected from AD and changed the immutable ID.]
I am so sick of this. Really time to think about G-suite. It has been over a year since the Azure AD Team "was aware".
Rutherford-Hall, Stuart commented
This is a feature that should have been fundamental to the whole hybrid setup. Why this has not been implemented is beyond me. This is going to prevent organisations making use of other Microsoft products and functionality which is frankly ridiculous. Please raise the priority of this. 482 votes as of today. That shows you how much this is needed!