After User Sync to Azure AD, migrate to another OnPremise AD

%3CLINGO-SUB%20id%3D%22lingo-sub-1525238%22%20slang%3D%22en-US%22%3ERe%3A%20After%20User%20Sync%20to%20Azure%20AD%2C%20migrate%20to%20another%20OnPremise%20AD%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1525238%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F708639%22%20target%3D%22_blank%22%3E%40Jeffrey_Goins%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20is%20a%20way%20you%20could%20go%20about%20it%3A%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E1.%20Disable%20sync%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Foffice365%2Fenterprise%2Fturn-off-directory-synchronization%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Foffice365%2Fenterprise%2Fturn-off-directory-synchronization%3C%2FA%3E%3C%2FP%3E%3CP%3E2.%20Wait%20for%20your%20objects%20to%20get%20the%20status%20of%20cloud%20managed%20instead%20of%20synced%3C%2FP%3E%3CP%3E3.%20remove%20the%20imutableID%20of%20your%20cloud%20objects.%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20started%3A%26nbsp%3B%3C%2FP%3E%3CPRE%3EGet-MsolUser%20-All%20%7C%20Set-MsolUser%20-ImmutableId%20%24null%3C%2FPRE%3E%3CDIV%20class%3D%22swp_social_panel%20swp_horizontal_panel%20swp_flat_fresh%20%20swp_default_full_color%20swp_individual_full_color%20swp_other_full_color%20scale-100%20%20scale-%22%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3E4.%20Set%20up%20ADconnect%20in%20the%20new%20domains%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3E5.%20Either%20hard%20match%20or%20soft%20match%20the%20on%20prem%20accounts%3A%26nbsp%3B%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3ESoftmatch%3A%20based%20on%20attributes%3A%20UPN%2C%20Default%20smtp%2C%20...%26nbsp%3B%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3EHardmatch%3A%20generate%20and%20set%20immutableID%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3EGenerating%20immutableID%20as%20such%3A%26nbsp%3B%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3E%26nbsp%3B%3C%2FDIV%3E%3C%2FDIV%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%20class%3D%22lia-code-sample%20language-powershell%22%3E%3CCODE%3E%24User%20%3D%20Get-ADuser%20%24UserSamAccount%20-Properties%20*%20-server%20%24DC%0A%0A%24ImmutableID%20%3D%20%5Bsystem.convert%5D%3A%3AToBase64String((%5BGUID%5D(%24User.ObjectGUID)).tobytearray())%3C%2FCODE%3E%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3EMake%20sure%20your%20users%20in%20the%20new%20domains%20have%20the%20required%20attributes%20before%20you%20sync.%20(Correct%20UPN%2C%20ProxyAddresses%2C%20User%20attributes%2C%20...)%20Or%20you%20will%20remove%20the%20attributes%20from%20your%20cloud%20objects%20by%20synching%20the%20incomplete%20users.%20You%20can%20export%20the%20old%20domain%20users%20and%20the%20cloud%20objects%20with%20PowerShell%20just%20to%20be%20on%20the%20safe%20side.%26nbsp%3B%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%20class%3D%22nc_tweetContainer%20swp_share_button%20swp_twitter%22%3EBefore%20you%20do%20any%20operations%20like%20this%20that%20you%20are%20not%20familiar%20with%2C%20always%20test%20run%20this%20in%20a%20demo%20environment!!%26nbsp%3B%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1485346%22%20slang%3D%22en-US%22%3EAfter%20User%20Sync%20to%20Azure%20AD%2C%20migrate%20to%20another%20OnPremise%20AD%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1485346%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ewe%20use%20an%20onpremis%20AD..%20maybe%20contoso.dom%2C%20I%20sync%20users%20to%20Azure%20Ad%20%3CA%20href%3D%22mailto%3Ajon%40company1.com%2C%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ejon%40company1.com%2C%3C%2FA%3E%26nbsp%3B%3CA%20href%3D%22mailto%3Ated%40compandy%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Eted%40company2.com%20%3C%2FA%3Eand%20so%20on.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENo%2C%20the%20companies%20should%20be%20separated%20onpremise%20and%20contos.com%20disappeas%20so%20I%20have%3C%2FP%3E%3CP%3Esomecompany1.dom%20on%20premise%20with%26nbsp%3B%3CA%20href%3D%22mailto%3Ajon%40company1.com%2C%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ejon%40company1.com%3C%2FA%3E%3C%2FP%3E%3CP%3Esomecompany2.dom%20on%20premise%26nbsp%3Bwith%26nbsp%3B%3CA%20href%3D%22mailto%3Ated%40compandy%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Eted%40company2.com%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ebut%20i%20dont%20want%20a%20different%20User%20in%20AzureAD%2C%20when%20Jon%20is%20synced%20from%20somecompany1.dom%20to%20azure%20he%20should%20find%20its%20Onedrive%20and%20Teams%20stuff.%20Is%20it%20possible%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20thougt%20I%20took%20the%3A%20employeeID%20as%20another%20attribut%20for%20Unique%20Identify%2C%20but%20select%20how%20user%20should%20identify%20with%20Azure%20Ad%2C%20whats%20would%20here%20the%20best.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1485346%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EOffice%20365%20OnPremise%20azureSync%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Highlighted
New Contributor

Hi, 

 

we use an onpremis AD.. maybe contoso.dom, I sync users to Azure Ad jon@company1.com, ted@company2.com and so on.

 

No, the companies should be separated onpremise and contos.com disappeas so I have

somecompany1.dom on premise with jon@company1.com

somecompany2.dom on premise with ted@company2.com

 

but i dont want a different User in AzureAD, when Jon is synced from somecompany1.dom to azure he should find its Onedrive and Teams stuff. Is it possible?

 

I thougt I took the: employeeID as another attribut for Unique Identify, but select how user should identify with Azure Ad, whats would here the best.

1 Reply

@Jeffrey_Goins 

 

This is a way you could go about it: 

 

1. Disable sync: https://docs.microsoft.com/en-us/office365/enterprise/turn-off-directory-synchronization

2. Wait for your objects to get the status of cloud managed instead of synced

3. remove the imutableID of your cloud objects. 

For started: 

Get-MsolUser -All | Set-MsolUser -ImmutableId $null
4. Set up ADconnect in the new domains
5. Either hard match or soft match the on prem accounts: 
Softmatch: based on attributes: UPN, Default smtp, ... 
Hardmatch: generate and set immutableID
 
Generating immutableID as such: 
 

 

$User = Get-ADuser $UserSamAccount -Properties * -server $DC

$ImmutableID = [system.convert]::ToBase64String(([GUID]($User.ObjectGUID)).tobytearray())

 

 
Make sure your users in the new domains have the required attributes before you sync. (Correct UPN, ProxyAddresses, User attributes, ...) Or you will remove the attributes from your cloud objects by synching the incomplete users. You can export the old domain users and the cloud objects with PowerShell just to be on the safe side. 
 
Before you do any operations like this that you are not familiar with, always test run this in a demo environment!!