Home

Bulk change users from synced to cloud only

%3CLINGO-SUB%20id%3D%22lingo-sub-181197%22%20slang%3D%22en-US%22%3EBulk%20change%20users%20from%20synced%20to%20cloud%20only%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-181197%22%20slang%3D%22en-US%22%3E%3CP%3EGood%20afternoon%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20have%20Azure%20AD%20connect%20setup%20and%20it%20syncs%20about%2010%20different%20forests%20into%201%20O365%20tenant.%3C%2FP%3E%3CP%3ENow%20there%20is%201%20company%20that%20wants%20to%20switch%20to%20pure%20cloud%20users%20but%20I'm%20not%20sure%20how%20to%20proceed%20to%20switch%20them%20all%20from%20'synced%20with%20ad'to%20'cloud%20user'.%3C%2FP%3E%3CP%3EIf%20I%20understand%20correctly%2C%20if%20I%20just%20remove%20their%20domain%20from%20Azure%20AD%20by%20rerunning%20setup%20and%20changing%20the%20sync%20options%2C%20the%20users%20won't%20become%20cloud%20users%20but%20will%20instead%20be%20deleted.%3C%2FP%3E%3CP%3ETo%20make%20matters%20worse%2C%20the%20company%20already%20broke%20the%20VPN%20link%20to%20our%20AAD%20so%20the%20domain%20is%20currently%20no%20longer%20syncing%20and%20I%20cannot%20for%20example%20create%20a%20separate%20OU%20in%20their%20on-prem%20AD%20and%20make%20sure%20that%20one%20does%20not%20sync%20and%20put%20the%20users%20in%20there%20(%20I%20think%20that%20would%20solve%20it%20as%20well).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20ideas%20on%20how%20to%20obtain%20our%20goal%20without%20having%20all%20user%20accounts%20end%20up%20in%20deleted%20users%20and%20having%20to%20restore%20them%201%20by%201%20and%20assigning%20a%20new%20password%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EKind%20regards%3C%2FP%3E%3CP%3ESteve%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-181197%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%20AD%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EIdentity%20Management%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182373%22%20slang%3D%22en-US%22%3ERe%3A%20Bulk%20change%20users%20from%20synced%20to%20cloud%20only%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182373%22%20slang%3D%22en-US%22%3E%3CP%3EThe%2072h%20is%20what%20it%20will%20take%20in%20large%20organizations%20with%20hundreds%20of%20thousands%20of%20users%2C%20in%20general%20it%20should%20be%20much%20faster.%20But%20it's%20still%20something%20to%20keep%20in%20mind%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAnd%20yes%2C%20PowerShell%20will%20allow%20you%20to%20delete%20the%20users%20(Remove-MsolUser).%20You%20can%20restore%20them%20from%20either%20the%20portal%20or%20PowerShell.%20Did%20I%20mention%20that%20this%20workaround%20is%20in%20now%20way%20supported%20by%20Microsoft%3F%20%3A)%3C%2Fimg%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182021%22%20slang%3D%22en-US%22%3ERe%3A%20Bulk%20change%20users%20from%20synced%20to%20cloud%20only%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182021%22%20slang%3D%22en-US%22%3E%3CP%3EOh%20wow%20that's%20quite%20an%20impact%20then%20seeing%20as%20this%20applies%20to%20about%2050%20users%20out%20of%20almost%202000...%20%3A)%3C%2Fimg%3E%3C%2FP%3E%3CP%3EAlso%20If%20I%20am%20not%20mistaken%2C%20you%20need%20to%20wait%2072%20hours%20to%20be%20sure%20it's%20really%20off%20and%20then%20re-enable%20it%20which%20can%20also%2C%20in%20theory%2C%20take%20up%20to%2072%20hours.%3C%2FP%3E%3CP%3EI%20tried%20the%20other%20way%2C%20to%20delete%20the%20user%20via%20O365%20portal%20but%20system%20refuses%20since%20the%20account%20is%20still%20labeled%20'synced%20with%20active%20directory'.%20The%20O365%20portal%20tells%20me%20to%20delete%20user%20from%20on-prem%20AD%20which%20would%20be%20pointless%20since%20I%20can%20no%20longer%20reach%20that%20company's%20on-prem%20AD.%3C%2FP%3E%3CP%3EWould%20it%20work%20if%20I%20do%20it%20via%20powershell%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-181873%22%20slang%3D%22en-US%22%3ERe%3A%20Bulk%20change%20users%20from%20synced%20to%20cloud%20only%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-181873%22%20slang%3D%22en-US%22%3E%3CP%3ENo%2C%20step%201%20should%20be%20disable%20DirSync%20on%20O365%20side.%20Whether%20it's%20enabled%20on%20the%20AAD%20Connect%20server%20it%20makes%20no%20difference.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-181847%22%20slang%3D%22en-US%22%3ERe%3A%20Bulk%20change%20users%20from%20synced%20to%20cloud%20only%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-181847%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Vasil%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20for%20your%20reply.%20Am%20I%20correct%20that%20these%20would%20be%20the%20steps%20to%20follow%3F%3C%2FP%3E%3CP%3E1)%20disable%20DirSync%20via%20Set-ADSyncScheduler%20SyncCycleEnabled%20%24false%3C%2FP%3E%3CP%3E2)%20Clear%20the%20immutableIDs%20of%20the%20accounts%20via%20Set-MSOLUser%20-UserPrincipalName%26nbsp%3B%3CEM%3Eusername%3C%2FEM%3E%20-ImmutableID%20%22%24null%22%3C%2FP%3E%3CP%3E3)%20Run%20Azure%20AD%20Connect%20setup%20and%20remove%20the%20domain%20from%20the%20config%3C%2FP%3E%3CP%3E4)%20Re-enable%20the%20sync%20scheduler%20and%20run%20a%20full%20sync%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EExpected%20result%3A%20all%20accounts%20are%20now%20cloud%20accounts%20and%20have%20retained%20their%20last%20known%20password%20with%20no%20impact%20on%20user%20experience%20(no%20need%20to%20re-sign%20in%20in%20Outlook%20client%2C%20other%20office%20apps%20or%20outlook%20mobile%20app%20on%20Android)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EKind%20regards%3C%2FP%3E%3CP%3ESteve%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-181326%22%20slang%3D%22en-US%22%3ERe%3A%20Bulk%20change%20users%20from%20synced%20to%20cloud%20only%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-181326%22%20slang%3D%22en-US%22%3E%3CP%3EYou%20can%20disable%20DirSync%2C%20move%20the%20users%20(domain)%20outside%20of%20the%20DirSync%20scope%2C%20clear%20their%20ImmutableIDs%20in%20the%20cloud%20and%20force%20a%20Full%20Sync.%20Another%20variation%20of%20the%20process%2C%20and%20one%20that%20does%20not%20involve%20disabling%20DirSync%2C%20is%20to%20delete%20them%20in%20O365%2C%20then%20restore%20them%20from%20the%20recycle%20bin.%20If%20you%20do%20it%20fast%20enough%2C%20no%20services%20will%20be%20impacted%20and%20the%20objects%20will%20be%20provisioned%20as%20%22disconnectors%22%2C%20allowing%20you%20to%20manage%20them%20in%20the%20cloud.%20Newly%20created%20objects%20will%20steal%20sync%20from%20the%20on-premised%20AD%20though%2C%20so%20you%20should%20still%20configure%20filtering.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Steve Hernou
Contributor

Good afternoon

 

We have Azure AD connect setup and it syncs about 10 different forests into 1 O365 tenant.

Now there is 1 company that wants to switch to pure cloud users but I'm not sure how to proceed to switch them all from 'synced with ad'to 'cloud user'.

If I understand correctly, if I just remove their domain from Azure AD by rerunning setup and changing the sync options, the users won't become cloud users but will instead be deleted.

To make matters worse, the company already broke the VPN link to our AAD so the domain is currently no longer syncing and I cannot for example create a separate OU in their on-prem AD and make sure that one does not sync and put the users in there ( I think that would solve it as well).

 

Any ideas on how to obtain our goal without having all user accounts end up in deleted users and having to restore them 1 by 1 and assigning a new password?

 

Kind regards

Steve

5 Replies

You can disable DirSync, move the users (domain) outside of the DirSync scope, clear their ImmutableIDs in the cloud and force a Full Sync. Another variation of the process, and one that does not involve disabling DirSync, is to delete them in O365, then restore them from the recycle bin. If you do it fast enough, no services will be impacted and the objects will be provisioned as "disconnectors", allowing you to manage them in the cloud. Newly created objects will steal sync from the on-premised AD though, so you should still configure filtering.

Hi Vasil,

 

Thanks for your reply. Am I correct that these would be the steps to follow?

1) disable DirSync via Set-ADSyncScheduler SyncCycleEnabled $false

2) Clear the immutableIDs of the accounts via Set-MSOLUser -UserPrincipalName username -ImmutableID "$null"

3) Run Azure AD Connect setup and remove the domain from the config

4) Re-enable the sync scheduler and run a full sync

 

Expected result: all accounts are now cloud accounts and have retained their last known password with no impact on user experience (no need to re-sign in in Outlook client, other office apps or outlook mobile app on Android)

 

Kind regards

Steve

No, step 1 should be disable DirSync on O365 side. Whether it's enabled on the AAD Connect server it makes no difference.

Oh wow that's quite an impact then seeing as this applies to about 50 users out of almost 2000... :)

Also If I am not mistaken, you need to wait 72 hours to be sure it's really off and then re-enable it which can also, in theory, take up to 72 hours.

I tried the other way, to delete the user via O365 portal but system refuses since the account is still labeled 'synced with active directory'. The O365 portal tells me to delete user from on-prem AD which would be pointless since I can no longer reach that company's on-prem AD.

Would it work if I do it via powershell?

The 72h is what it will take in large organizations with hundreds of thousands of users, in general it should be much faster. But it's still something to keep in mind,

 

And yes, PowerShell will allow you to delete the users (Remove-MsolUser). You can restore them from either the portal or PowerShell. Did I mention that this workaround is in now way supported by Microsoft? :)

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
35 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
9 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies