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”.
Ken Rose commented
Is there any update on this being implemented?
Randy Fleszar commented
This is your typical Microsoft ********* that's been going on for years. All the busy bodies are busy working on useless features and not features that MSFT users are asking for.
PLEASE MAKE MIGRATING A USER TO CLOUD ONLY A SIMPLE TASK. DELETING AD SYNC FOR THE ENTIRE ORGANIZATION IS NOT AN OPTION AND HAS NOT BEEN FOR THE 10 YEARS I HAVE BEEN DOING THIS.
What's the purpose of this forum if no one is listening? Do you have an answer to this simple question, Microsoft?
Eric Liu commented
Any status on this from MSFT?
This is really frustrating since the cloud users are not able to manage the onprem DL and we dont have any other option to move the DL to cloud. please provide a solution asap for this.
This is still in Planned status for 2+ years. This user voice for AAD is just a joke in my opinion.
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.