SOLVED

Forest migration with Office 365 - strange sync behaviour Azure AD Connect

%3CLINGO-SUB%20id%3D%22lingo-sub-848845%22%20slang%3D%22en-US%22%3EForest%20migration%20with%20Office%20365%20-%20strange%20sync%20behaviour%20Azure%20AD%20Connect%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-848845%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%40all%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ewe%20currently%20experience%20a%20strange%20behaviour%20with%20Azure%20AD%20Connect%20and%20migrating%20users%20between%20AD%20forests.%20The%20scenario%3A%3C%2FP%3E%3CP%3E-%20Multiple%20source%20forests%3B%20users%20with%20on-prem%20mailboxes%3C%2FP%3E%3CP%3E-%20One%20target%20forest%3C%2FP%3E%3CP%3EOnly%20user%20mailboxes%20are%20migrated%20at%20the%20moment%2C%20as%20the%20users%20must%20stay%20in%20their%20forest%20for%20now.%20The%20migration%20workflow%20is%20as%20follows%3A%3CBR%20%2F%3E-%20Sync%20user%20from%20source%20forest%20to%20Azure%20AD%20(attribute-based)%20--%26gt%3B%20consistency%20GUID%20is%20written%3CBR%20%2F%3E-%20%22Copy%22%20user%20to%20target%20forest%20with%20ADMT%20(without%20sync%20attribute)%3CBR%20%2F%3E-%20Remove%20sync%20attribute%20from%20source%20forest%20user%3B%20AADC%20sync%3CBR%20%2F%3E-%20Add%20sync%20attribute%20to%20target%20forest%20user%3B%20AADC%20sync%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhile%20this%20worked%20flawlessly%20for%20two%20forests%20we%20now%20see%20the%20behaviour%20that%20Azure%20AD%20Connect%20somehow%20%22merges%22%20the%20two%20users%20from%20both%20forests%20and%20writes%20the%20consistency%20GUID%20to%20both%20user%20accounts.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENo%20matter%2C%20which%20changes%20we%20configure%20for%20the%20source%20forest%20user%20(remove%20UPN%2C%20e-mail%20address%2C%20aso.)%20the%20user%20is%20always%20synced%20and%20moreover%2C%20his%20settings%20overwrite%20any%20settings%20of%20the%20target%20forest%20user%20(i.e.%20proxy%20addresses%2C%20display%20name%2C%20etc.).%3C%2FP%3E%3CP%3EThe%20only%20workaround%20at%20the%20moment%20is%20to%20remove%20the%20sync%20attribute%20temporarily%2C%20delete%20the%20source%20forest%20user%20and%20set%20the%20sync%20attribute%20on%20the%20target%20forest%20user.%20If%20we%20just%20remove%20the%20source%20account%2C%20Azure%20AD%20Connect%20runs%20into%20an%20error%20because%20it%20does%20not%20find%20the%20account%20anymore.%3C%2FP%3E%3CP%3EBut%20this%20is%20no%20solution%20here%20as%20the%20source%20forest%20user%20must%20remain.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20can%20reproduce%20this%20behaviour%20in%20another%20customer%20environment.%20We%20use%20the%20May%2019%20version%20of%20Azure%20AD%20Connect.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHas%20anyone%20ever%20seen%20this%20or%20can%20give%20us%20hints%20on%20how%20to%20solve%20this%20issue%20or%20optimize%20the%20migration%20process%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBest%20regards%3C%2FP%3E%3CP%3EBen%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-848845%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EExchange%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EHybrid%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-848951%22%20slang%3D%22en-US%22%3ERe%3A%20Forest%20migration%20with%20Office%20365%20-%20strange%20sync%20behaviour%20Azure%20AD%20Connect%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-848951%22%20slang%3D%22en-US%22%3EIssue%20solved%20-%20the%20sync%20rules%20had%20to%20be%20re-ordered%20so%20that%20the%20sync%20rules%20concerning%20the%20target%20forest%20are%20executed%20last.%3C%2FLINGO-BODY%3E
Highlighted
New Contributor

Hi @all,

 

we currently experience a strange behaviour with Azure AD Connect and migrating users between AD forests. The scenario:

- Multiple source forests; users with on-prem mailboxes

- One target forest

Only user mailboxes are migrated at the moment, as the users must stay in their forest for now. The migration workflow is as follows:
- Sync user from source forest to Azure AD (attribute-based) --> consistency GUID is written
- "Copy" user to target forest with ADMT (without sync attribute)
- Remove sync attribute from source forest user; AADC sync
- Add sync attribute to target forest user; AADC sync

 

While this worked flawlessly for two forests we now see the behaviour that Azure AD Connect somehow "merges" the two users from both forests and writes the consistency GUID to both user accounts.

 

No matter, which changes we configure for the source forest user (remove UPN, e-mail address, aso.) the user is always synced and moreover, his settings overwrite any settings of the target forest user (i.e. proxy addresses, display name, etc.).

The only workaround at the moment is to remove the sync attribute temporarily, delete the source forest user and set the sync attribute on the target forest user. If we just remove the source account, Azure AD Connect runs into an error because it does not find the account anymore.

But this is no solution here as the source forest user must remain.

 

We can reproduce this behaviour in another customer environment. We use the May 19 version of Azure AD Connect.

 

Has anyone ever seen this or can give us hints on how to solve this issue or optimize the migration process?

 

 

Best regards

Ben

1 Reply
Highlighted
Best Response confirmed by Vasil Michev (MVP)
Solution
Issue solved - the sync rules had to be re-ordered so that the sync rules concerning the target forest are executed last.