Home

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

%3CLINGO-SUB%20id%3D%22lingo-sub-42908%22%20slang%3D%22en-US%22%3EConvert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-42908%22%20slang%3D%22en-US%22%3E%3CP%3EHi%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20have%20currently%20setup%20a%20ADConnect%20Sync%20to%20Office%20365%2C%20this%20is%20working%20well.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20would%20like%20to%20start%20converting%20Sync'ed%20accounts%20in%20Office%20365%2FAzure%20AD%20to%20%22In%20Cloud%22%20accounts.%20Can%20you%20advise%20or%20does%20anyone%20know%20how%20we%20might%20approach%20this%3F%20Or%20can%20point%20to%20alternative%20resources%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20need%20to%20ensure%20the%20accounts%20in%20Office%20365%2FAzure%20AD%20remain%20active%20and%20usable.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMuch%20appreciated%3C%2FP%3E%3CP%3EPaul%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-42908%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%20Active%20Directory%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EIdentity%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-389851%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-389851%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F113967%22%20target%3D%22_blank%22%3E%40Jamie%20Luce%3C%2FA%3E%2C%20I'm%20sorry%20but%20that%20scenario%20is%20not%20possible.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20I%20understood%20correctly%2C%20you%20want%20to%20make%20resource%20rooms%20cloud-only%20so%20that%20you%20can%20authenticate%20directly%20to%20Office%20365%20(Azure%20AD).%20The%20authentication%20(managed%2Ffederated)%20is%20defined%20per%20domain%2C%20so%20despite%20that%20users%20can%20be%20cloud-only%2C%20the%20authentication%20remains%20the%20same.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHowever%2C%20you%20can%20give%20these%20resource%20rooms%20(users)%20another%20domain%20(resource.domain.com%20etc.)%2C%20which%20is%20not%20federated.%20Then%20give%20them%20an%20alias%20with%20original%20domain.%20With%20this%20scenario%2C%20you%20could%20sync%20them%20from%20on-prem%20AD%20and%20still%20use%20the%20original%20domain%20to%20reserve%20rooms.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20the%20AD-removal-deletion%20issue%2C%20I%20think%20you%20need%20to%20do%20the%20following%3A%3C%2FP%3E%3COL%3E%3CLI%3ERemove%20the%20user%20from%20AD%20(or%20move%20to%20OU%20that%20is%20not%20synced)%3C%2FLI%3E%3CLI%3EUser%20gets%20deleted%20from%20Azure%20AD%20-%26gt%3B%20restore%20the%20user%3C%2FLI%3E%3CLI%3EChange%20UPN%20to%26nbsp%3B%40domain.onmicrosoft.com%3C%2FLI%3E%3CLI%3EClear%20the%20immutableId%20and%20run%20the%20sync%20(or%20wait%20until%20it%20is%20run)%3C%2FLI%3E%3CLI%3ESet%20immutableid%20to%20something%20unique%2C%20such%20as%20user's%20email%20address%3C%2FLI%3E%3CLI%3EChange%20UPN%20back%20to%20original%3C%2FLI%3E%3C%2FOL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-389361%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-389361%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F5953%22%20target%3D%22_blank%22%3E%40Nestori%20Syynimaa%3C%2FA%3E%26nbsp%3BWe%20have%20some%20resource%20rooms%20that%20need%20to%20be%20licensed%20and%20have%20a%20password%2C%20but%20the%20Resource%20Manager%20that%20we%20use%20cannot%20handle%20Multifactor%20Authentication.%26nbsp%3B%20We%20had%20these%20rooms%20syncing%20from%20on%20prem%20before%20but%20now%20we%20just%20need%20them%20to%20be%20cloud%20to%20take%20them%20out%20of%20Multifactor%20(Ping%20Federate).%26nbsp%3B%20We%20are%20creating%20all%20new%20Resources%20as%20cloud%20accounts%20directly%20but%20we%20didn't%20want%20to%20lose%20the%20info%20on%20the%20ones%20we%20were%20already%20using%2C%20so%20we%20deleted%20the%20AD%20account%20on%20prem%2C%20then%20restored%20it%20as%20a%20Cloud%20Account.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThen%20ran%20into%20the%20sync%20problems%20with%20it%20being%20removed%20since%20it%20still%20thought%20it%20was%20a%20deleted%20account.%26nbsp%3B%20I'm%20interested%20in%20those%20instructions%20if%20you%20could%20PM%20them%20to%20me.%26nbsp%3B%20Thanks%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-389171%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-389171%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F113967%22%20target%3D%22_blank%22%3E%40Jamie%20Luce%3C%2FA%3E%2C%20I'm%20not%20quite%20sure%20why%20you%20need%20to%20convert%20federated%20users%20to%20in-cloud%2C%20as%20they%20are%20(typically)%20synchronized%20from%20on-prem%20AD%20and%20are%20depending%20on%20the%20federation%20server%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnyways%2C%20there%20can%20also%20be%20cloud-only%20federated%20users%2C%20so%20you%20can%20change%20the%20UPN%20back%20to%20domain.com.%20You%20just%20need%20to%20give%20immutableId%20that%20matches%20the%20value%20your%20federation%20server%20is%20offering%20for%20the%20user%20when%20he%2Fshe%20logs%20in.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%2C%20this%20is%20possible%20but%20not%20very%20practical%20and%20needs%20some%20setup%20to%20do%20in%20your%20federation%20server.%20If%20you'd%20like%20to%20give%20it%20a%20try%2C%20let%20me%20know%20and%20I'll%20give%20you%20detailed%20instructions.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-389069%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-389069%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F113967%22%20target%3D%22_blank%22%3E%40Jamie%20Luce%3C%2FA%3E%26nbsp%3BI%20don't%20think%20you%20can%20set%20the%20immutableID%20to%20null%20unless%20it%20is%20a%20managed%20domain%20so%20that%20is%20likely%20why%20you%20can't%20change%20back%20to%20federated.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMaybe%20try%20%3CEM%3E%3CSTRONG%3E%3CA%20href%3D%22https%3A%2F%2Fanswers.microsoft.com%2Fen-us%2Fmsoffice%2Fforum%2Fmsoffice_o365admin%2Fmatching-on-premises-user-to-cloud-user%2Ff2a52719-24d2-4436-a257-fc3e60714c65%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ethis%20article%3C%2FA%3E%3C%2FSTRONG%3E%3C%2FEM%3E%20and%20see%20if%20that%20fixes%20it%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-389057%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-389057%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F307646%22%20target%3D%22_blank%22%3E%40crice011%3C%2FA%3E%26nbsp%3BWe%20are%20getting%20an%20error%20%22You%20must%20provide%20a%20required%20property%3A%26nbsp%3B%20Paramet%20name%3A%26nbsp%3B%20FeeratedUser.SourceAnchor%22%26nbsp%3B%20So%20we%20have%20to%20set%20the%20domain%20to%20a%20managed%20domain%20domain.onmicrosoft.com%20then%20we%20can%20set%20the%20ImmutableID%20to%20Null%2C%20we%20can't%20change%20it%20back%20to%20the%20domain.com%20after.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-386949%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-386949%22%20slang%3D%22en-US%22%3EThe%20immutableID%20method%20worked%20for%20me%20as%20well.%3CBR%20%2F%3E%3CBR%20%2F%3EI%20moved%20the%20user%20to%20an%20unsynced%20OU%20but%20it%20kept%20getting%20deleted%20every%20few%20minutes%20when%20dirsync%20ran.%3CBR%20%2F%3E%3CBR%20%2F%3ESteps%20I%20did%3A%3CBR%20%2F%3E1.%20Move%20user%20to%20unsynced%20OU%3CBR%20%2F%3E2.%20Ensured%20AAD%20sync%20was%20not%20including%20that%20OU%3CBR%20%2F%3E3.%20User%20will%20be%20deleted%20from%20Azure%20AD%3CBR%20%2F%3E4.%20Connect%20to%20Azure%20AD%20via%20powershell%3CBR%20%2F%3E5.%20Run%3A%20Get-MsolUser%20-ReturnDeletedUsers%20%7C%20Restore-MsolUser%3CBR%20%2F%3E6.%20Run%3A%20Set-MsolUser%20-UserPrincipalName%20test.user%40example.com%20-ImmutableID%20%22%22%3CBR%20%2F%3E%3CBR%20%2F%3Eno%20more%20being%20logged%20out%20every%20time%20sync%20runs%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-362449%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-362449%22%20slang%3D%22en-US%22%3E%3CP%3EThats%20good%20news...!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-362444%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-362444%22%20slang%3D%22en-US%22%3E%3CP%3EIt%20is%20working.%20I%20did%20so%20last%20night%20with%202%20users.%20They%20were%20successfully%20converted%20to%20Azure%20AD%20users%20(cloud%20users)%20that%20used%20to%20be%20sync'd%20from%20on-prem%20by%20nulling%20the%20ImmutableID%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-362443%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-362443%22%20slang%3D%22en-US%22%3E%3CP%3EI%20did%20log%20a%20ticket%20with%20MS%20last%20few%20weeks%20ago%2C%20they%20also%20said%20they%20will%20revert%20back%20the%20changes.%20I%20am%20wondering%20if%20they%20already%20did%3F%3CBR%20%2F%3E%3CBR%20%2F%3EAnyone%20can%20confirm%20it%20is%20now%20working%20again%3F%20(I%20am%20too%20lazy%20to%20test..LOL).%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-361055%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-361055%22%20slang%3D%22en-US%22%3EI%20have%20just%20logged%20a%20support%20ticket%20with%20Microsoft%20about%20this.%20The%20guy%20on%20the%20other%20end%20mentioned%20that%20they%20did%20remove%20the%20ability%20to%20change%20-ImmutableID%20but%20they%20reverted%20this%20change%20due%20to%20%22customer%20feedback%22.%3CBR%20%2F%3ERunning%20(set-msoluser%20-UserPrincipalName%20%3CNAME%3E%20-ImmutableID%20%22%24null%22)%20fixed%20my%20issue%20of%20the%20cloud%20user%20(that%20originated%20on-prem)%20being%20deleted%20on%20the%20next%20sync%20cycle.%3C%2FNAME%3E%3CLINGO-SUB%20id%3D%22lingo-sub-319244%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-319244%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F42313%22%20target%3D%22_blank%22%3E%40Jessie%20Hernandez%3C%2FA%3E%26nbsp%3Bseems%20to%20be%20answering%20to%20a%20totally%20different%20thing%26nbsp%3Bthan%20what%20was%20asked.%26nbsp%3BYes%2C%20you%20can%20link%20the%20existing%20Azure%20AD%20user%20to%20a%20different%20on-prem%20AD%20user%20using%20the%20%3CSTRONG%3Ems-DS-consitencyGUID%3C%2FSTRONG%3E%20attribute.%20But%20you%20cannot%20use%20it%20to%20make%20users%20cloud-only%20(which%20was%20the%20original%20question).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20method%20suggested%20by%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F260052%22%20target%3D%22_blank%22%3E%40RedRobot%3C%2FA%3E%26nbsp%3Bworks%2C%20because%20you%20can%20change%20the%20ImmutableId%20when%20the%20sync%20is%20not%20enabled.%20However%2C%20this%20is%20a%20very%20heavy%20method%20if%20needs%20to%20be%20done%20daily.%20But%20as%20said%2C%20it%20works.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-318611%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-318611%22%20slang%3D%22en-US%22%3E%3CP%3EI%20thought%20everyone%20else%20said%26nbsp%3B%3CSPAN%3E-ImmutableID%20does%20not%20work%20anymore%3F%3CBR%20%2F%3ECan%20anyone%20confirm%20this%3F%20Or%20have%20you%20tried%20this%3F%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-315216%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-315216%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20ended%20up%20switching%20our%20Azure%20AD%20Connect%20Source%20anchor%20from%20Objectguid%20to%20ms-DS-consistencyGUID%20(as%20recommended%20by%20Support).%26nbsp%3B%20This%20works%20for%20us%20because%20it%20allows%20us%20to%20recover%20deleted%20accounts%20via%20hard%20linking%20to%20on-prem%20AD%20accounts.%26nbsp%3B%20Before%20we%20would%20control%20this%20by%20manipulating%20the%20immutableID%20of%20the%20Azure%20AD%20user.%26nbsp%3B%20Now%20we%20just%20manipulate%20it%20on%20the%20on-prem%20AD%20side.%26nbsp%3B%20Here%20is%20blog%20post%20which%20illustrates%20this%20process%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fblogs.technet.microsoft.com%2Flatam%2F2018%2F03%2F27%2Fusing-the-consistencyguid%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fblogs.technet.microsoft.com%2Flatam%2F2018%2F03%2F27%2Fusing-the-consistencyguid%2F%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-315187%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-315187%22%20slang%3D%22en-US%22%3E%3CP%3EImport-Module%20Azure%3CBR%20%2F%3E%24LiveCred%20%3D%20Get-Credential%3CBR%20%2F%3EConnect-MsolService%20-Credential%20%24LiveCred%3CBR%20%2F%3ESet-MsolDirSyncEnabled%20%E2%80%93EnableDirSync%20%24false%3CBR%20%2F%3E(I%20answered%20%E2%80%98y%E2%80%99%20when%20prompted)%3C%2FP%3E%3CP%3E%3CWAIT%20until%3D%22%22%20you%3D%22%22%20stop%3D%22%22%20getting%3D%22%22%20the%3D%22%22%20adsynced%3D%22%22%20user%3D%22%22%20warning%3D%22%22%20in%3D%22%22%20the%3D%22%22%20o365%3D%22%22%20portal%3D%22%22%20when%3D%22%22%20you%3D%22%22%20go%3D%22%22%20to%3D%22%22%20edit%3D%22%22%20a%3D%22%22%20username%3D%22%22%3E%3C%2FWAIT%3E%3C%2FP%3E%3CP%3ESet-MsolUser%20-UserPrincipalName%20test.user%40example.com%20-ImmutableID%20%22%22%3C%2FP%3E%3CP%3E%3CWAIT%2010%3D%22%22%20minutes%3D%22%22%3E%3C%2FWAIT%3E%3C%2FP%3E%3CP%3ESet-MsolDirSyncEnabled%20%E2%80%93EnableDirSync%20%24true%3CBR%20%2F%3E(I%20answered%20%E2%80%98y%E2%80%99%20when%20prompted)%3CBR%20%2F%3E%3CTHIS%20last%3D%22%22%20step%3D%22%22%20will%3D%22%22%20take%3D%22%22%206-8%3D%22%22%20hours-ish%3D%22%22%20before%3D%22%22%20sync%3D%22%22%20restarts%3D%22%22%3E%3C%2FTHIS%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-312351%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-312351%22%20slang%3D%22en-US%22%3E%3CP%3EThere%20is%20also%20a%20feedback%20request%20on%20Azure.com%20which%20we%20can%20vote%20on%20-%20not%20sure%20which%20one%20will%20get%20their%20attention%20to%20actually%20change%20this%20back%3A%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ffeedback.azure.com%2Fforums%2F169401-azure-active-directory%2Fsuggestions%2F36479119-allow-conversion-of-ad-synced-accounts-to-in-clou%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Ffeedback.azure.com%2Fforums%2F169401-azure-active-directory%2Fsuggestions%2F36479119-allow-conversion-of-ad-synced-accounts-to-in-clou%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-312205%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-312205%22%20slang%3D%22en-US%22%3E%3CP%3EAnyone%20can%20share%20the%20latest%20steps%20(step%20by%20step)%20on%20how%20to%20do%20this%20with%20the%20current%20change%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308955%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308955%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20the%20same%20issue%20and%20received%20the%20same%20info%20from%20Support%20that%20nulling%20the%20immutable%20is%20not%20longer%20supported%20and%20they%20consider%20it%20a%20fix.%20the%20suggested%20uservoice%20to%20get%20it%20changed.%26nbsp%3B%20there%20is%20already%20a%20posting%20on%20uservoice%20for%20this%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Foffice365.uservoice.com%2Fforums%2F312601-office-365-admin-mobile%2Fsuggestions%2F36380371-feature-rollback-users-should-become-incloud-once%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Foffice365.uservoice.com%2Fforums%2F312601-office-365-admin-mobile%2Fsuggestions%2F36380371-feature-rollback-users-should-become-incloud-once%3C%2FA%3E.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPlease%20vote%20it%20can't%20hurt.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308865%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308865%22%20slang%3D%22en-US%22%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CBLOCKQUOTE%3E%3CHR%20%2F%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F457%22%20target%3D%22_blank%22%3E%40Paul%20Bullock%3C%2FA%3E%26nbsp%3Bwrote%3A%3CBR%20%2F%3E%3CP%3EHi%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20have%20currently%20setup%20a%20ADConnect%20Sync%20to%20Office%20365%2C%20this%20is%20working%20well.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20would%20like%20to%20start%20converting%20Sync'ed%20accounts%20in%20Office%20365%2FAzure%20AD%20to%20%22In%20Cloud%22%20accounts.%20Can%20you%20advise%20or%20does%20anyone%20know%20how%20we%20might%20approach%20this%3F%20Or%20can%20point%20to%20alternative%20resources%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20need%20to%20ensure%20the%20accounts%20in%20Office%20365%2FAzure%20AD%20remain%20active%20and%20usable.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMuch%20appreciated%3C%2FP%3E%3CP%3EPaul%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CHR%20%2F%3E%3C%2FBLOCKQUOTE%3E%3CP%3E%3CBR%20%2F%3EOkay..%2C%20Let%20me%20try%20this%20one%20and%20then%20I%20will%20give%20you%20some%20feedback%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308837%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308837%22%20slang%3D%22en-US%22%3E%3CP%3EThere's%20now%20a%20release%20note%20regarding%20this%20change%20at%3A%3C%2FP%3E%3CH1%20id%3D%22toc-hId-476947426%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%20id%3D%22toc-hId-1903958539%22%3EWhat's%20new%20in%20Azure%20Active%20Directory%3F%3C%2FH1%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Ffundamentals%2Fwhats-new%23novemberdecember-2018%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Ffundamentals%2Fwhats-new%23novemberdecember-2018%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20helps%20explain%20the%20background%20reasons%20for%20Microsoft%20having%20to%20fix%20this%20bug.%20The%20main%20thing%20to%20keep%20in%20mind%20is%20that%2C%20unfortunately%20this%20bug%20was%20giving%20the%20wrong%20impression%20that%20accounts%20synchronized%20from%20AD%20were%20'converted'%20to%20cloud-only%20accounts%2C%20when%20in%20reality%20this%20'trick'%26nbsp%3Bwas%20just%20flipping%26nbsp%3Bone%26nbsp%3Bsimple%20DirSyncEnabled%26nbsp%3Bflag%26nbsp%3Band%20keeping%26nbsp%3Ball%20the%20main%20synchronized%20properties%20of%20the%20object.%20The%20Office%20365%20portal%20showed%20the%20accounts%20as%20%22Cloud-only%22%20because%20it%20was%20only%20looking%20at%20the%26nbsp%3B%3CSPAN%3EDirSyncEnabled%26nbsp%3Bflag.%26nbsp%3BSo%26nbsp%3Bthe%20'trick'%20was%20not%20really%20converting%20anything%20at%20all%20in%20first%20place.%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308461%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308461%22%20slang%3D%22en-US%22%3E%3CP%3EI%20will!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308449%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308449%22%20slang%3D%22en-US%22%3E%3CP%3EJan%2C%20I%20would%20really%20like%20to%20know%20the%20updates%20regarding%20your%20ticket%20with%20MS%20once%20you%20have%20them!%20Thanks%20in%20advance%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308397%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308397%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Nestori%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20for%20you%20feedback.%20We're%20a%20%22sluggish%22%20%2B100k%20user%20shop%20with%20presents%20in%20over%20130%20countries%20with%20one%20tenant%2C%20one%20Global%20Forest%20(2%20ADs)%20and%20several%20(%2B40)%20ADs%20%22synced%22%20via%20MIM.%20MS%20told%20us%20to%20disable%20the%20sync%20for%20the%20complete%20tenant%20but%20like%20you%20say%2C%20with%20several%20mutations%20a%20day%2C%20this%20is%20going%20to%20be%20a%20nightmare.%20We're%20still%20in%20contact%20with%20MS%20so%20they%20provide%20us%20with%20some%20guidance%20on%20a%20possible%2C%20working%2C%20workaround.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegards%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EJan%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308384%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308384%22%20slang%3D%22en-US%22%3E%3CP%3EConfirmed%20this%20in%20my%20own%20tests.%20Once%20the%20user%20is%20%22on-prem%20managed%22%2C%20you%20can%20not%20anymore%20modify%20the%20immutableId%20using%20Set-MsolUser%20command.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHowever%2C%20I%20managed%20to%20do%20this%20by%20disabling%20the%20sync%2C%20resetting%20the%20immutableId%20to%20%22%22%20and%20then%20enabling%20the%20sync%20again.%20If%20you%20have%20massive%20number%20of%20users%2C%20and%2For%20need%20to%20do%20this%20just%20once%2C%20this%20could%20do%20it%20for%20you.%20But%20this%20is%20quite%20%22heavy%22%20to%20do%20on%20daily%20basis.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-306898%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-306898%22%20slang%3D%22en-US%22%3E%3CP%3EI%20have%20a%20ticket%20open%20with%20the%20Azure%20AD%20Cloud%20Identity%20team%20and%20they%20confirmed%20this%20as%20well.%26nbsp%3B%20Being%20able%20to%20change%20the%20ImmutableID%20on%20a%20restored%20account%20was%20%22fixed%20(no%20longer%20possible)%22%20starting%20in%20December%20for%20our%20tenant.%26nbsp%3B%20I%20was%20still%20able%20do%20this%20via%20the%20Azure%20AD%20V2%20modules%20but%20that%20route%20is%20going%20to%20get%20%22fixed%22%20soon%20as%20well.%26nbsp%3B%20The%20only%20documented%20option%20I%20saw%20for%20Hybrid%20users%20was%20to%20do%20a%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fexchange%2Frecipients-in-exchange-online%2Fdelete-or-restore-mailboxes%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3ENew-MailboxRestoreRequest%3C%2FA%3E%20to%20copy%20content%20from%20the%20deleted%20mailbox%20into%20an%20empty%20mailbox.%26nbsp%3B%20This%20is%20less%20than%20ideal%20because%20of%20the%20time%20required%20to%20do%20mailbox%20restore%20vs%20just%20re-linking%20an%20Azure%20AD%20account.%26nbsp%3B%20I%20am%20still%20waiting%20to%20see%20what%20they%20propose%20as%20a%20solution%20now%20that%20they%20are%20no%20longer%20allowing%20changing%20the%20immutableID%20for%20identities%20that%20were%20originally%20sourced%20from%20On-Prem%20AD.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-306034%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-306034%22%20slang%3D%22en-US%22%3Ethis%20is%20a%20huge%20change%20I%20was%20doing%20it%20for%20many%20years%20also%20!%3CBR%20%2F%3E%3CBR%20%2F%3EThanks%2C%3CBR%20%2F%3EYousef%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-305843%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-305843%22%20slang%3D%22en-US%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3EIs%20there%20any%20documentation%20of%20this%20correction%20%3F%3C%2FP%3E%3CP%3EMaybe%20it%20was%20a%20bug%20by%20Microsoft%20BUT%20many%20of%20us%20used%20this%20'bug'%20from%20years%20!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-305753%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-305753%22%20slang%3D%22en-US%22%3E%3CP%3E%22The%20SourceAnchor%20attribute%20can%20only%20be%20set%20during%20initial%20installation.%20If%20you%20rerun%20the%20installation%20wizard%2C%20this%20option%20is%20read-only.%20If%20you%20need%20to%20change%20this%20setting%2C%20then%20you%20must%20uninstall%20and%20reinstall.%22%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20cannot%20find%20ANY%20documentation%20which%20suggests%20what%20is%20%22Supported%22%20and%20what%20is%20not.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20goal%20is%20to%20convert%20an%20AD%20Synced%20user%20to%20a%20Cloud%20user%20WITHOUT%20having%20to%20stop%20AD%20Sync%20for%20ALL%20Users.%20%5Bwhich%20seems%20like%20burning%20down%20the%20house%20to%20kill%20a%20spider%5D%3C%2FP%3E%3CP%3EUsed%20to%20just%20move%20user%20to%20a%20non-synced%20OU%2C%20run%20a%20Delta%20sync%2C%20then%20restore%20user%20from%20deleted%20users%2C%20and%20it%20was%20then%20an%20%22In%20Cloud%22%20user.%3C%2FP%3E%3CP%3ENow%20when%20that%20is%20done%2C%20it%20restores%20the%20user%20back%20to%20%22Synced%20with%20Active%20Directory.%22%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESome%20have%20mentioned%20this%20was%20able%20to%20be%20done%20due%20to%20a%20bug%2C%20which%20has%20been%20patched.%3C%2FP%3E%3CP%3EIS%20there%20an%20%22Easy%22%20way%20to%20convert%201%20user%20to%20a%20Cloud%20User%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-304475%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-304475%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20process%20of%20changing%20the%20ImmutableId%20in%20the%20cloud%20directly%20is%20not%20supported%20and%20it%20was%20available%20due%20to%20a%20bug%20in%20Azure%20AD.%20As%20of%20today%2C%20this%20has%20been%20fixed%20and%20so%20it's%20no%20longer%20possible%20to%20update%20the%20ImmutableId%20or%20change%20the%20source%20or%20authority%20to%20%22Cloud-only%22%2C%20unless%20you%20disable%20DirSync%20on%20the%20whole%20Tenant.%20There's%20a%20new%20feature%20in%20AAD%20Connect%20called%20%22Update%20SourceAnchor%22%20that%20will%20change%20AAD%20Connect's%26nbsp%3Bsource%20anchor%20configuration%20from%20ObjectGUID%20to%26nbsp%3Bms-Ds-Consistency-GUID%20attribute%20which%20will%20allow%20you%20to%20manage%20the%26nbsp%3BImmutable's%26nbsp%3B%20value%20in%20local%20AD%2C%20instead%20of%20having%20to%20change%20it%20in%20the%20cloud%20with%20Set-MsolUser.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-204509%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-204509%22%20slang%3D%22en-US%22%3E%3CP%3EI've%20been%20working%20on%20this%20today%20and%20it%20looks%20like%20you%20can't%20null%20out%20the%20ImmutableID%20until%20the%20user%20has%20been%20deleted%20and%20restored.%26nbsp%3B%20So%20I'm%20removing%20the%20accounts%20from%20the%20synced%20OU%2C%20run%20the%20sync%2C%20confirm%20deletion%20with%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%3EGet-MsolUser%20-ReturnDeletedUsers%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20all%20accounts%20that%20are%20being%20converted%20show%20I%20then%20run%20this.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%3E%24DeletedUsers%20%3D%20Get-MsolUser%20-ReturnDeletedUsers%3CBR%20%2F%3Eforeach%20(%24user%20in%20%24DeletedUsers)%20%7B%3CBR%20%2F%3E%3CSPAN%3ERestore-MsolUser%20-UserPrincipalName%20%24user.UserPrincipalName%3CBR%20%2F%3ESet-MsolUser%20-UserPrincipalName%20%24user.UserPrincipalName%20-ImmutableId%20%22%22%3CBR%20%2F%3E%3C%2FSPAN%3E%7D%3C%2FPRE%3E%3CP%3EAfter%20doing%20this%20with%20a%20small%20scale%20test%2C%20accounts%20did%20not%20get%20deleted%20after%20subsequent%20syncs.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-186262%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-186262%22%20slang%3D%22en-US%22%3E%3CP%3EI%20raised%20a%20ticket%20with%20this%20with%20MS%2C%20the%20support%20engineer%20suggested%20nulling%20the%3CSPAN%3EImmutableId%20like%20this%20(or%20piping%20any%20number%20of%20deleted%20users%20in)%3A%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EGet-MsolUser%20-UserPrincipalName%20foo%40domain%20%7C%20Set-MsolUser%20-ImmutableId%20%22%22%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EThat%20was%20suggested%20by%20someone%20above%20in%20the%20thread%20and%20seems%20to%20work%20fine.%20I%20also%20asked%20him%20to%20escalate%20it%20internally%20which%20he%20said%20he%20would.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EAlthough%20this%20might%20not%20be%20a%20supported%20way%20of%20doing%20things%20I%20would%20think%20it's%20still%20quite%20common.%20We%20often%20have%20people%20here%20who%20leave%20and%20then%20we%20need%20to%20keep%20their%20mail%20hanging%20about%20for%20months%20or%20even%20longer%20so%20other%20people%20can%20see%20it.%20Rather%20than%20keeping%20the%20user%20in%20AD%20or%20messing%20about%20with%20PST%20files%20I%20can%20now%20leave%20them%20in%20the%20cloud%20until%20they're%20no%20longer%20needed%20which%20is%20a%20good%20solution%20%3A)%3C%2Fimg%3E%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-186123%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-186123%22%20slang%3D%22en-US%22%3E%3CP%3EI%20ran%20a%20re-homed%20a%20very%20large%20group%20of%20shared%20mailboxes%20over%20the%20weekend.%26nbsp%3B%20Every%20single%20AD%20account%20made%20native%20in%20Office%20365%26nbsp%3B%20was%20successful!%26nbsp%3B%20I%20had%20no%20accounts%20disappear.%26nbsp%3B%20They%20are%20all%20fully%20editable.%26nbsp%3B%20In%20short%2C%20the%20did%20exactly%20what%20I%20wanted%20them%20to%20do.%3C%2FP%3E%3CP%3EIn%20short%20my%20process%20looks%20like%20this.%3C%2FP%3E%3COL%3E%3CLI%3EI%20stop%20the%20ad%20account%20from%20syncing%20(move%20to%20a%20non%20replicating%20OU.)%3C%2FLI%3E%3CLI%3EAfter%20I%20have%20verified%20it%20is%20not%20longer%20visible%20in%20Office%20365%26nbsp%3B%20(Get-MSOLUSER%2C)%20I%20run..%3C%2FLI%3E%3C%2FOL%3E%3CP%3EGet-MsolUser%20-UserPrincipalName%26nbsp%3B%3CUSER%20upn%3D%22%22%3E%26nbsp%3B-ReturnDeletedUsers%20%7CRestore-MsolUser%3C%2FUSER%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B3.%20I%20follow%20this%20with%3A%3C%2FP%3E%3CP%3ESet-MsolUser%20%3CSPAN%3E-UserPrincipalName%26nbsp%3B%3CUSER%20upn%3D%22%22%3E%26nbsp%3B%3C%2FUSER%3E%3C%2FSPAN%3E-BlockCredential%3A%24true%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20is%20pretty%20easy%20to%20do%20in%20bulk.%26nbsp%3B%20My%20last%20step%20will%20be%20to%20remove%20the%20non%20replicating%20AD%20accounts.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-184904%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-184904%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20a%20configuration%20where%20we%20can%20exclude%20the%20accounts%20from%20syncing%20by%20populating%20an%20attribute%20with%20the%20term%20%22noSync.%22%26nbsp%3B%20You%20should%20be%20able%20to%20achieve%20the%20same%20thing%20though%20by%20putting%20these%20accounts%20in%20to%20a%20non%20syncing%20OU.%26nbsp%3B%20Excluding%20the%20accounts%20from%20any%20exposure%20to%20sync%20seems%20to%20be%20a%20key%20element.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-184899%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-184899%22%20slang%3D%22en-US%22%3EI%20haven't%20opened%20a%20ticket%3B%20I'm%20not%20sure%20if%20this%20is%20a%20supported%20methodology.%20The%20shared%20mailboxes%20though%20that%20I%20have%20stopped%20syncing%20still%20have%20not%20disappeared.%20I%20am%20not%20ready%20to%20declare%20victory%20yet%20in%20my%20pilot.%20My%20verdict%20will%20be%20posted%20Monday.%20Its%20looking%20good%20so%20far%20though.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-184756%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-184756%22%20slang%3D%22en-US%22%3E%3CP%3EI've%20migrated%20most%20of%20my%20normal%20users%20now%20so%20was%20just%20checking%20this%20conversion%20of%20shared%20mailboxes%20again.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20work%20around%20of%20blocking%20the%20user%20seems%20to%20have%20stopped%20working%20since%20last%20week%2C%20blocked%20users%20now%20re-delete%20themselves%20when%20the%20dirsync%20runs.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHas%20anyone%20opened%20a%20support%20ticket%20about%20this%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-183183%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-183183%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20going%20thru%20the%20same%20emotion%20here.%20I%20have%20the%20same%20project%20going%20with%20shared%20mailboxes.%26nbsp%3B%20I%20did%20the%20same%20kind%20of%20testing.%26nbsp%3B%20My%20resource%20accounts%20are%20still%20here.%26nbsp%3B%20I%20think%20I%20am%20ready%20to%20do%20a%20pilot%20group%20of%2020%20resources.%3C%2FP%3E%3CP%3EAs%20far%20as%20blocking%20the%20logins%2C%20the%20resources%20should%20continue%20to%20function%20fine.%26nbsp%3B%20We%20have%20all%20of%20our%20cloud%20based%20resources%20set%20that%20way%20and%20have%20had%20no%20issues.%3C%2FP%3E%3CP%3EI%20will%20let%20you%20know%20how%20my%20pilot%20goes.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-183096%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-183096%22%20slang%3D%22en-US%22%3EBefore%20I%20left%20on%20Friday%20I%20recovered%20the%20user%20and%20then%20blocked%20them%20as%20suggested%2C%20they%20were%20still%20there%20today%20and%20hadn't%20been%20deleted.%20I%20just%20unblocked%20the%20user%20and%20waited%20until%20the%20dirsync%20had%20run%20and%20they're%20still%20there%20so%20that%20did%20seem%20to%20work%20yes.%20I%20mainly%20need%20to%20do%20this%20to%20get%20my%20shared%20mailboxes%20off%20premises%20and%20into%20the%20cloud%20so%20I%20suppose%20that%20would%20work%20OK%2C%20people%20should%20still%20be%20able%20to%20access%20them%20if%20they're%20blocked%3F%20Seems%20like%20a%20bug%20though!%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182582%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182582%22%20slang%3D%22en-US%22%3E%3CP%3ENote!%26nbsp%3BDO%20NOT%20do%20this%20if%20you%20are%20using%20federated%20identity%2C%20as%20it%20is%20using%20ImmutableId%20to%20identify%20users.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182575%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182575%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20re-deletion%20of%20users%20is%20a%20totally%20new%20phenomenon%20for%20me%20which%20I%20need%20to%20test%20myself%20too.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnyways%2C%20technically%20the%20objects%20in%20AAD%20are%20linked%20to%20the%20AD%20objects%20with%20ImmutableId%20attribute.%20So%20you%20could%20try%20to%20delete%20this%20link%20by%20emptying%20the%20attribute%20using%20the%20following%20command%26nbsp%3Bbefore%20restoring%20users%3A%3C%2FP%3E%3CPRE%3EGet-MsolUser%20-ReturnDeletedUsers%20%7C%20Set-MsolUser%20-ImmutableId%20%22%22%3C%2FPRE%3E%3CP%3ELet%20me%20know%20whether%20this%20helped.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182562%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182562%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20latest%20batch%20I%20did%2C%20I%20blocked%20the%20credential%20immediately%20after%20undeleting%20the%20account.%26nbsp%3B%20I%20did%20this%20yesterday%20and%20the%20accounts%20are%20still%20there.%26nbsp%3B%20I%20would%20be%20interested%20in%20knowing%20if%20this%20works%20for%20anyone%20else.%3C%2FP%3E%3CP%3E%3CEM%3EGet-MsolUser%20-UserPrincipalName%26nbsp%3B%3CUSERACCOUNT%3E%26nbsp%3B%7CSet-MsolUser%20-BlockCredential%20%24true%3C%2FUSERACCOUNT%3E%3C%2FEM%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182522%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182522%22%20slang%3D%22en-US%22%3EThis%20is%20happening%20for%20me%20as%20well%2C%20only%20tried%20it%20today%20for%20the%20first%20time.%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20user%20re-deletes%20when%20the%20dirsync%20runs%2C%20happened%20twice%20in%20a%20row.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182423%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182423%22%20slang%3D%22en-US%22%3EI%20had%20to%20recover%20the%20user%20one%20more%20time%20and%20then%20it%20stopped.%20Nothing%20I%20did.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182205%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182205%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3EI%20had%20it%20stop%20within%20the%20day.%20I've%20tried%20to%20reproduce%20the%20behavior.%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20seems%2C%20that%20it%20stops%20when%20I%20do%20the%20following%3A%26nbsp%3B%3C%2FP%3E%3CP%3E1)%20On%20the%20local%20server%2C%20remove%20the%20user%20from%20the%20Azure%20Synchronization%20group%3C%2FP%3E%3CP%3E2)%20reactivate%20on%20Office365%20(user%20now%20%22in%20cloud%22)%3C%2FP%3E%3CP%3E-%20User%20keeps%20being%20deleted%3C%2FP%3E%3CP%3E3)%20rejoin%20the%20user%20to%20the%20sync%20group%20on%20the%20local%20server%20(user%20is%20now%20%22AD%20synced%22)%3C%2FP%3E%3CP%3E4)%20remove%20from%20sync%20group%3C%2FP%3E%3CP%3E5)%20reactivate%20on%20Office365%20(user%20now%20%22in%20cloud%22).%3C%2FP%3E%3CP%3E-%20So%20far%20it%20works%20for%20the%20latest%20user%20I%20have%20been%20moving%20today.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EEdit%3A%20I%20guess%20I%20jinxed%20it%2C%20user%20is%20deleted%20again%20.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182132%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182132%22%20slang%3D%22en-US%22%3E%3CP%3EI%20had%20the%20same%20thing%20happen.%26nbsp%3B%20They%20quickly%20restored.%26nbsp%3B%20Oddly%20enough%2C%20these%20were%20shared%20mailboxes.%26nbsp%3B%20For%20a%20regular%20user%2C%20I%20could%20see%20this%20happening%20if%20there%20were%20no%20license%3B%20in%20fact%20I%20think%20this%20is%20designed%20behavior.%3C%2FP%3E%3CP%3EI%20am%20especially%20concerned%20about%20mailboxes%20that%20hit%20the%2030%20day%20deletion%20time.%26nbsp%3B%20Have%20you%20had%20any%20go%20that%20long%3F%26nbsp%3B%20This%20is%20why%20I%20haven't%20yet%20done%20a%20large%20implementation-still%20testing.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-182125%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-182125%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%26nbsp%3B%3C%2FP%3E%3CP%3Ewe%20have%20been%20using%20that%20method%20succesfully%20in%20the%20past.%26nbsp%3B%3C%2FP%3E%3CP%3EWeirdly%2C%20now%20some%20users%20get%20deleted%20and%20need%20to%20be%20recovered%26nbsp%3Brepeatedly%20(within%2010-30%20minutes).%26nbsp%3B%3C%2FP%3E%3CP%3EUnfortunately%20I%20haven't%20been%20able%20to%20identify%20what%20made%20these%20deletions%20stop.%26nbsp%3B%3C%2FP%3E%3CP%3EAnyone%20experiencing%20this%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%3C%2FP%3E%3CP%3ERocky%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-181292%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-181292%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20method%20worked%20great%20for%20me.%26nbsp%3B%20We%20are%20converting%20our%20shared%20mailboxes%20to%20be%26nbsp%3B%3CEM%3Enative%3C%2FEM%3E%20in%20the%20cloud%20(for%20a%20lack%20of%20a%20better.%26nbsp%3B%20It%20pulls%20over%20everything...email%20aliases%2C%20forwarders%2C%20delegations%20etc.%26nbsp%3B%20Great%20stuff!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-129520%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-129520%22%20slang%3D%22en-US%22%3E%3CP%3EIf%20you%20only%20need%20to%20do%20this%20for%20a%20subset%20of%20accounts%2C%20you%20can%20simply%20move%20users%20to%20an%20OU%20which%20is%20not%20synced%20(assuming%20that%20you've%20configured%20to%20sync%20only%20selected%20OUs).%20After%20the%20sync%20runs%2C%20users%20are%20%22deleted%22%20from%20cloud.%20Run%20the%20following%20command%20to%20restore%20the%20users.%3C%2FP%3E%3CPRE%3EGet-MsolUser%20-ReturnDeletedUsers%20%7C%20Restore-MsolUser%3C%2FPRE%3E%3CP%3EWith%20this%20scenario%2C%20users%20are%20restored%20%22as%20they%20were%22%2C%20so%20there%20is%20no%20need%20to%20give%20a%20new%20password.%20However%2C%20you%20should%20notice%20that%20if%20users%20are%20changing%20their%20passwords%2C%20they%20must%20follow%20the%20Office%20365%20password%20policy%20(8-16%20characters%20etc.).%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-125243%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-125243%22%20slang%3D%22en-US%22%3E%3CP%3EBrent%20is%20correct%20if%20you%20only%20need%20to%20convert%20a%20few%20accounts.%20When%20you%20recover%20the%20deleted%20user%2C%20it%20will%20ask%20you%20to%20set%20a%20new%20password%20since%20it%20is%20now%20%22In%20Cloud%22%20and%20not%20managed%20by%20your%20local%20AD%20sync.%3CBR%20%2F%3EIt%20should%20also%20reconnect%20to%20the%20previously%20associated%20mailbox.%20You%20will%20have%20to%20provide%20the%20new%20temp%20password%20to%20your%20user%20and%20have%20them%20change%20at%20first%20logon.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EIf%20you%20need%20to%20convert%20all%20to%20cloud%2C%20then%20the%20disabling%20of%20AAD%20Sync%20is%20the%20way%20to%20go.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-49066%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-49066%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20will%20work%20just%20fine.%20When%20you%20execute%20the%20command%20%3CSTRONG%3ESet-MsolDirSyncEnabled%20%E2%80%93EnableDirSync%20%24false%3C%2FSTRONG%3E.%20You%20disable%20the%20Dirsync%20(when%20you%20execute%20it%20can%20take%20up%20to%2072%20hours%20to%20get%20it%20done).%20After%20this%20all%20the%20users%20in%20the%20office365%20tenant%20will%20keep%20there%20password%20what%20they%20have%20at%20that%20moment.%20Visualy%20it%20just%20removes%20the%20collum%20where%20it%20now%20says%20In%20Cloud%2F%20Synchronized%20with%20active%20directory.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20you%20have%20done%20this%20you%20can%20execute%20the%20command%20get-msolcompanyinformation%20to%20check%20if%20the%20sync%20is%20really%20gone.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E*note%3A%20the%20azure%20ad%20connect%20is%20still%20on%20the%20server%20so%20when%20you%20reboot%20that%20server%20there%20is%20a%20chance%20that%20the%20Sync%20will%20be%20enabled.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-44468%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-44468%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20authority%20for%20an%20AD%20Synced%20account%20will%20always%20be%20Active%20Directory%2C%20which%20means%20that%20management%20happens%20in%20AD.%20To%20make%20accounts%20(and%20that%20means%20ALL%20synced%20accounts%20at%20once)%20cloud%20managed%20accounts%2C%20you%20will%20need%20to%20disable%20directory%20syncing.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20not%20done%20this%20so%20you%20MUST%20test%20this%20before%20implementation.%20Disabling%20and%20re-enabling%20will%20result%20in%20duplicate%20accounts.%20The%20command%20to%20use%20would%20be%20%3CSTRONG%3ESet-MsolDirSyncEnabled%20%E2%80%93EnableDirSync%20%24false%3C%2FSTRONG%3E.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-44407%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-44407%22%20slang%3D%22en-US%22%3E%3CP%3EHi%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20tried%20removing%20the%20user%20and%20re-adding%20however%2C%20this%20prompts%20me%20for%20a%20new%20password.%20Is%20there%20a%20way%20to%20move%20the%20user%20account%20from%20On-Prem%20AD%20to%20Azure%20AD%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECurrently%20the%20users%20i%20want%20are%20using%20AD%20Connect%2C%20however%20most%20of%20the%20users%20do%20not%20need%20full%20AD%20accounts%20just%20email%20which%20is%20in%20Office%20365.%20So%20we%20want%20to%20remove%20them%20from%20the%20local%20network%20only%20but%20keep%20in%20Azure%20AD.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20ideas%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPaul%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-43319%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-43319%22%20slang%3D%22en-US%22%3EThanks%20Brent%2C%20I%20will%20try%20this%20out.%3CBR%20%2F%3E%3CBR%20%2F%3EPaul%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-43249%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-43249%22%20slang%3D%22en-US%22%3EYou%20could%20terminate%20the%20account%20in%20Active%20Directory%20(which%20would%20terminate%20the%20account%20in%20AAD%2FO365)%20after%20forcing%20a%20delta%20sync%2C%20then%20login%20to%20O365%20admin%20center%20and%20%22reactivate%22%20%2F%20%22undelete%22%20the%20account%20and%20assign%20it%20a%20license%20(if%20it%20doesnt%20remember%20the%20license%20it%20had).%3CBR%20%2F%3E%3CBR%20%2F%3EThere%20may%20be%20other%20routes%2C%20but%20I%20know%20that%20should%20accomplish%20what%20you%20need.%3C%2FLINGO-BODY%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-837407%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-837407%22%20slang%3D%22en-US%22%3E%3CP%3EAfter%20converting%20an%20on-prem%20user%20to%20a%20cloud%20user%2C%20by%20nullifying%20the%20ImmutableId%2C%20has%20anyone%20been%20able%20to%20verify%20that%20the%20PowerShell%20command%2C%20whoami%2C%20returns%20AzureAD%5Cusername%20instead%20of%20ONPREM%5Cusername%20%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20is%20the%20issue%20we're%20currently%20experiencing%20and%20we%20are%20concerned%20with%20any%20possible%20adverse%20affects%20it%20might%20cause%20to%20the%20AzureAD%20user%20object%20functionality%20and%20stability.%20We're%20currently%20not%20experiencing%20any%20visible%20issues%20at%20the%20moment%2C%20however.%20-Josh%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-837441%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-837441%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F403557%22%20target%3D%22_blank%22%3E%40Josh-M%3C%2FA%3E%26nbsp%3BHi%20Josh%2C%20it's%20an%20interesting%20question%20and%20it%20comes%20up%20in%20my%20mind%20every%20now%20and%20then.%20I%20haven't%20had%20any%20trouble%20in%20my%20lab%20with%20users%20or%20Microsoft%20services.%20Though%20the%20lab%20did%20not%20run%20for%20long%20time%20and%20I%20cannot%20remember%20what%20whoami%20would%20return.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20planned%20the%20conversion%20for%20my%20client%20in%20a%20few%20months.%20This%20is%20a%20150%20seat%20tenant%20with%20only%20saas%20apps%20and%20all%20data%20stored%20in%20sharepoint%2Fonedrive.%20I%20don't%20foresee%20any%20issues%20in%20this%20scenario%2C%20but%20perhaps%20your%20infra%20is%20more%20complex.%3CBR%20%2F%3E%3CBR%20%2F%3EKeep%20us%20posted%2C%20thanks.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-551993%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-551993%22%20slang%3D%22en-US%22%3E%3CP%3EI%20have%20tested%20this%20scenario%20half%20a%20year%20ago%20because%20I%20have%20a%20client%20who%20will%20need%20the%20same.%20Worked%20out%20well.%20Please%20try%20this%20in%20a%20lab%20environment%20first.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%23Requirements%3A%20Managed%20domain%2C%20Global%20Administrator%2C%20Domain%20Admin%2C%20Active%20Directory%20Users%20and%20Computers%2C%20AD%20Connect%2C%20PowerShell-modules%20MSOnline%20%26amp%3B%20ADSync%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%23Connect%20with%20MSOL%3CBR%20%2F%3E%24credential%20%3D%20Get-Credential%3CBR%20%2F%3EConnect-MsolService%20-Credential%20%24credential%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%23Check%20DirSync%20status%3CBR%20%2F%3EGet-MSOLCompanyInformation%20%7C%20select%20DirectorySynchronizationStatus%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%23Backup%20all%20ImmutableIDs%20of%20federated%20users%3C%2FP%3E%3CP%3EGet-MsolUser%20%7C%20select%20userprincipalname%2Cimmutableid%20%7C%20sort%20userprincipalname%20%7C%20Export-Csv%20-Path%20%24env%3AUSERPROFILE%5CDesktop%5CImmutableIDs.csv%20-NoTypeInformation%20-Force%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%23Migrate%20synced%20user%20to%20cloud%20only%3CBR%20%2F%3EStep%201%3A%20Disable%20DirSync%3CBR%20%2F%3ESet-MsolDirSyncEnabled%20-EnableDirSync%20%24false%3CBR%20%2F%3EStep%202%3A%20Nullify%20ImmutableID%20%3CSTRONG%3E!!!%3C%2FSTRONG%3EMake%20sure%20you%20%3CSTRONG%3Eadd%20quotation%20marks%20to%20%24null%3C%2FSTRONG%3E%3CBR%20%2F%3ESet-MsolUser%20-UserPrincipalName%20user%40domain.com%20-ImmutableId%20%22%24null%22%3CBR%20%2F%3EStep%203%3A%20Move%20nullified%20users%20to%20non-synced%20OU%3CBR%20%2F%3EStep%204%3A%20Enable%20DirSync%3CBR%20%2F%3ESet-MsolDirSyncEnabled%20-EnableDirSync%20%24true%3CBR%20%2F%3EStep%205%3A%20Force%20AD%20Connect%20sync%3CBR%20%2F%3EStart-ADSyncSyncCycle%20-PolicyType%20Delta%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%23Revert%20migration%20of%20user%3CBR%20%2F%3EStep%201%3A%20Disable%20DirSync%3CBR%20%2F%3ESet-MsolDirSyncEnabled%20-EnableDirSync%20%24false%3CBR%20%2F%3EStep%202%3A%20Move%20user%20to%20original%20OU%3CBR%20%2F%3EStep%203%3A%20Put%20back%20the%20ImmutableID%20of%20the%20user%3CBR%20%2F%3ESet-MsolUser%20-UserPrincipalName%20user%40domain.com%20-ImmutableId%20%22ID%22%3CBR%20%2F%3EStep%204%3A%20Enable%20DirSync%3CBR%20%2F%3ESet-MsolDirSyncEnabled%20-EnableDirSync%20%24true%3CBR%20%2F%3EStep%205%3A%20Force%20AD%20Connect%20sync%3CBR%20%2F%3EStart-ADSyncSyncCycle%20-PolicyType%20Delta%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-837464%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-837464%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F403557%22%20target%3D%22_blank%22%3E%40Josh-M%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20never%20thought%20about%20it%20until%20you%20mentioned%20it%20now.%26nbsp%3B%20whoami%20returns%20ONPREM%5Cusername%20for%20my%20converted%20user.%26nbsp%3B%20I%20would%20assume%20that%20is%20because%20the%20user%20is%20still%20in%20an%20on-prem%20OU.%20While%20that%20OU%20is%20not%20synced%20with%20ADSync%2C%20the%20metadata%20for%20that%20user%20is%20still%20there.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20computer%20was%20built%20from%20new%20and%20only%20using%20the%20AzureAD%20username%20so%20I'm%20sticking%20with%20it%20being%20the%20metadata.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-837493%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-837493%22%20slang%3D%22en-US%22%3E%3CP%3EIt%E2%80%99s%20a%20good%20question%20and%20I%E2%80%99ll%20double%20check%20in%20the%20morning%20on%20our%20tenant.%3C%2FP%3E%3CP%3EI%20do%20know%20though%20that%20after%20migrating%20users%20to%20on-cloud%20and%20removing%20the%20immutable%20ID%2C%20the%20authentication%20in%20tools%20like%20Outlook%20went%20from%20being%20domain%5Cusername%20to%20email%20address.%3C%2FP%3E%3CP%3EI%E2%80%99ll%20post%20back%20in%20the%20morning.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-837988%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-837988%22%20slang%3D%22en-US%22%3EWhoami%20will%20always%20execute%20in%20the%20context%20of%20the%20account%20logged%20onto%20the%20desktop.%20If%20your%20computer%20is%20part%20of%20an%20AD%20domain%20and%20you'velogged%20on%20with%20a%20domain%20account%2C%20it%20will%20be%20DOMAIN%5CUSER.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-841212%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-841212%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F403557%22%20target%3D%22_blank%22%3E%40Josh-M%3C%2FA%3E%26nbsp%3BI%20tried%20looking%20into%20this%20as%20well%2C%20I%20did%20receive%20some%20information%20from%20Microsoft.%20I%20still%20don't%20know%20if%20this%20causes%20any%20issues%2C%20it%20doesn't%20seem%20to%20negatively%20impact%20anything%20in%20a%20sandbox%20environment.%20Also%20with%20one%20user%20in%20a%20production%20environment.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%22This%20a%20known%20gap%2C%20that%20we're%20reviewing.%20Even%20though%20you%20have%20migrated%20the%20user%20from%20AD%20to%20Azure%20AD%2C%20the%20onprem%20SamAccountName%20is%20still%20intact%20on%20the%20user%20object%2C%20among%20other%20on-prem%20AD%20attributes.%20As%20a%20result%2C%20Azure%20AD%20picks%20those%20details%20and%20shows%20domain%2Fuser%20instead%20of%20AzureAD%2Fuser.%20This%20attribute%20cannot%20be%20modified%20or%20cleared%20through%20Graph%20APIs%20at%20this%20point%2C%20so%20there's%20no%20way%20to%20change%20the%20behavior.%20Please%20file%20a%20UserVoice%20suggestion%20on%20MS%20Graph%20for%20this%20so%20that%20our%20teams%20can%20get%20the%20feedback%20and%20prioritize%20it%20as%20needed%22%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESource%3A%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F38048%23issuecomment-528570435%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F38048%23issuecomment-528570435%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-855196%22%20slang%3D%22en-US%22%3ERe%3A%20Convert%20On-Prem%20AD%20Users%20from%20Office%20365%2FAzure%20AD%20to%20In-Cloud%20accounts%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-855196%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F404800%22%20target%3D%22_blank%22%3E%40Erikc%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFriends%2C%20please%20vote%20here%20to%20allow%20this%20topic%20and%20feature%20request%20to%20gain%20traction%20to%20allow%20conversion%20of%20users%20properly.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fmicrosoftgraph.uservoice.com%2Fforums%2F920506-microsoft-graph-feature-requests%2Fsuggestions%2F38597974-azuread%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fmicrosoftgraph.uservoice.com%2Fforums%2F920506-microsoft-graph-feature-requests%2Fsuggestions%2F38597974-azuread%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E
Paul Bullock
New Contributor

Hi

 

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

Paul

 

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.

Paul

Hi

 

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?

 

Paul

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 everything...email aliases, forwarders, delegations etc.  Great stuff!

Hi, 

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?

 

Thanks

Rocky

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.

 

Hi,

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?

I haven't opened a ticket; I'm not sure if this is a supported methodology. The shared mailboxes though that I have stopped syncing still have not disappeared. I am not ready to declare victory yet in my pilot. My verdict will be posted Monday. Its looking good so far though.

We have a configuration where we can exclude the accounts from syncing by populating an attribute with the term "noSync."  You should be able to achieve the same thing though by putting these accounts in to a non syncing OU.  Excluding the accounts from any exposure to sync seems to be a key element.

I ran a re-homed a very large group of shared mailboxes over the weekend.  Every single AD account made native in Office 365  was successful!  I had no accounts disappear.  They are all fully editable.  In short, the did exactly what I wanted them to do.

In short my process looks like this.

  1. I stop the ad account from syncing (move to a non replicating OU.)
  2. After I have verified it is not longer visible in Office 365  (Get-MSOLUSER,) I run..

Get-MsolUser -UserPrincipalName <user UPN> -ReturnDeletedUsers |Restore-MsolUser

     3. I follow this with:

Set-MsolUser -UserPrincipalName <user UPN> -BlockCredential:$true

 

This is pretty easy to do in bulk.  My last step will be to remove the non replicating AD accounts.

 

I raised a ticket with this with MS, the support engineer suggested nulling theImmutableId like this (or piping any number of deleted users in):

 

Get-MsolUser -UserPrincipalName foo@domain | Set-MsolUser -ImmutableId ""

 

That was suggested by someone above in the thread and seems to work fine. I also asked him to escalate it internally which he said he would.

 

Although this might not be a supported way of doing things I would think it's still quite common. We often have people here who leave and then we need to keep their mail hanging about for months or even longer so other people can see it. Rather than keeping the user in AD or messing about with PST files I can now leave them in the cloud until they're no longer needed which is a good solution :)

I've been working on this today and it looks like you can't null out the ImmutableID until the user has been deleted and restored.  So I'm removing the accounts from the synced OU, run the sync, confirm deletion with

 

Get-MsolUser -ReturnDeletedUsers

 

When all accounts that are being converted show I then run this.

 

$DeletedUsers = Get-MsolUser -ReturnDeletedUsers
foreach ($user in $DeletedUsers) {
Restore-MsolUser -UserPrincipalName $user.UserPrincipalName
Set-MsolUser -UserPrincipalName $user.UserPrincipalName -ImmutableId ""
}

After doing this with a small scale test, accounts did not get deleted after subsequent syncs. 

 

This process of changing the ImmutableId in the cloud directly is not supported and it was available due to a bug in Azure AD. As of today, this has been fixed and so it's no longer possible to update the ImmutableId or change the source or authority to "Cloud-only", unless you disable DirSync on the whole Tenant. There's a new feature in AAD Connect called "Update SourceAnchor" that will change AAD Connect's source anchor configuration from ObjectGUID to ms-Ds-Consistency-GUID attribute which will allow you to manage the Immutable's  value in local AD, instead of having to change it in the cloud with Set-MsolUser.

"The SourceAnchor attribute can only be set during initial installation. If you rerun the installation wizard, this option is read-only. If you need to change this setting, then you must uninstall and reinstall."

 

I cannot find ANY documentation which suggests what is "Supported" and what is not.

 

The goal is to convert an AD Synced user to a Cloud user WITHOUT having to stop AD Sync for ALL Users. [which seems like burning down the house to kill a spider]

Used to just move user to a non-synced OU, run a Delta sync, then restore user from deleted users, and it was then an "In Cloud" user.

Now when that is done, it restores the user back to "Synced with Active Directory."

 

Some have mentioned this was able to be done due to a bug, which has been patched.

IS there an "Easy" way to convert 1 user to a Cloud User?

 

Hello,

Is there any documentation of this correction ?

Maybe it was a bug by Microsoft BUT many of us used this 'bug' from years !

this is a huge change I was doing it for many years also !

Thanks,
Yousef

I have a ticket open with the Azure AD Cloud Identity team and they confirmed this as well.  Being able to change the ImmutableID on a restored account was "fixed (no longer possible)" starting in December for our tenant.  I was still able do this via the Azure AD V2 modules but that route is going to get "fixed" soon as well.  The only documented option I saw for Hybrid users was to do a New-MailboxRestoreRequest to copy content from the deleted mailbox into an empty mailbox.  This is less than ideal because of the time required to do mailbox restore vs just re-linking an Azure AD account.  I am still waiting to see what they propose as a solution now that they are no longer allowing changing the immutableID for identities that were originally sourced from On-Prem AD.

Confirmed this in my own tests. Once the user is "on-prem managed", you can not anymore modify the immutableId using Set-MsolUser command.

 

However, I managed to do this by disabling the sync, resetting the immutableId to "" and then enabling the sync again. If you have massive number of users, and/or need to do this just once, this could do it for you. But this is quite "heavy" to do on daily basis.

Hi Nestori

 

Thanks for you feedback. We're a "sluggish" +100k user shop with presents in over 130 countries with one tenant, one Global Forest (2 ADs) and several (+40) ADs "synced" via MIM. MS told us to disable the sync for the complete tenant but like you say, with several mutations a day, this is going to be a nightmare. We're still in contact with MS so they provide us with some guidance on a possible, working, workaround.

 

Regards

 

Jan

Jan, I would really like to know the updates regarding your ticket with MS once you have them! Thanks in advance 

There's now a release note regarding this change at:

What's new in Azure Active Directory?

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#novemberdecember-2018

 

This helps explain the background reasons for Microsoft having to fix this bug. The main thing to keep in mind is that, unfortunately this bug was giving the wrong impression that accounts synchronized from AD were 'converted' to cloud-only accounts, when in reality this 'trick' was just flipping one simple DirSyncEnabled flag and keeping all the main synchronized properties of the object. The Office 365 portal showed the accounts as "Cloud-only" because it was only looking at the DirSyncEnabled flag. So the 'trick' was not really converting anything at all in first place. 

 

 


@Paul Bullock wrote:

Hi

 

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

Paul

 



Okay.., Let me try this one and then I will give you some feedback

We have the same issue and received the same info from Support that nulling the immutable is not longer supported and they consider it a fix. the suggested uservoice to get it changed.  there is already a posting on uservoice for this https://office365.uservoice.com/forums/312601-office-365-admin-mobile/suggestions/36380371-feature-r....

 

Please vote it can't hurt.

Anyone can share the latest steps (step by step) on how to do this with the current change?

There is also a feedback request on Azure.com which we can vote on - not sure which one will get their attention to actually change this back:

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/36479119-allow-conversio...

Import-Module Azure
$LiveCred = Get-Credential
Connect-MsolService -Credential $LiveCred
Set-MsolDirSyncEnabled –EnableDirSync $false
(I answered ‘y’ when prompted)

<Wait until you stop getting the ADSynced user warning in the O365 portal when you go to edit a username>

Set-MsolUser -UserPrincipalName test.user@example.com -ImmutableID ""

<Wait 10 minutes>

Set-MsolDirSyncEnabled –EnableDirSync $true
(I answered ‘y’ when prompted)
<This last step will take 6-8 hours-ish before sync restarts>

 

We ended up switching our Azure AD Connect Source anchor from Objectguid to ms-DS-consistencyGUID (as recommended by Support).  This works for us because it allows us to recover deleted accounts via hard linking to on-prem AD accounts.  Before we would control this by manipulating the immutableID of the Azure AD user.  Now we just manipulate it on the on-prem AD side.  Here is blog post which illustrates this process: https://blogs.technet.microsoft.com/latam/2018/03/27/using-the-consistencyguid/

I thought everyone else said -ImmutableID does not work anymore?
Can anyone confirm this? Or have you tried this?

@Jessie Hernandez seems to be answering to a totally different thing than what was asked. Yes, you can link the existing Azure AD user to a different on-prem AD user using the ms-DS-consitencyGUID attribute. But you cannot use it to make users cloud-only (which was the original question).

 

The method suggested by @RedRobot works, because you can change the ImmutableId when the sync is not enabled. However, this is a very heavy method if needs to be done daily. But as said, it works.

I have just logged a support ticket with Microsoft about this. The guy on the other end mentioned that they did remove the ability to change -ImmutableID but they reverted this change due to "customer feedback".
Running (set-msoluser -UserPrincipalName <name> -ImmutableID "$null") fixed my issue of the cloud user (that originated on-prem) being deleted on the next sync cycle.

I did log a ticket with MS last few weeks ago, they also said they will revert back the changes. I am wondering if they already did?

Anyone can confirm it is now working again? (I am too lazy to test..LOL).

It is working. I did so last night with 2 users. They were successfully converted to Azure AD users (cloud users) that used to be sync'd from on-prem by nulling the ImmutableID

The immutableID method worked for me as well.

I moved the user to an unsynced OU but it kept getting deleted every few minutes when dirsync ran.

Steps I did:
1. Move user to unsynced OU
2. Ensured AAD sync was not including that OU
3. User will be deleted from Azure AD
4. Connect to Azure AD via powershell
5. Run: Get-MsolUser -ReturnDeletedUsers | Restore-MsolUser
6. Run: Set-MsolUser -UserPrincipalName test.user@example.com -ImmutableID ""

no more being logged out every time sync runs

@crice011 We are getting an error "You must provide a required property:  Paramet name:  FeeratedUser.SourceAnchor"  So we have to set the domain to a managed domain domain.onmicrosoft.com then we can set the ImmutableID to Null, we can't change it back to the domain.com after.  

@Jamie Luce I don't think you can set the immutableID to null unless it is a managed domain so that is likely why you can't change back to federated.  

 

Maybe try this article and see if that fixes it