question

Can you clarify on what the question is?

It sounds like it's working properly, but instead of using the msd-dsconsistencyguid source anchor, it's using the objectGUID?

By default per the docs here :
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts#using-ms-ds-consistencyguid-as-sourceanchor

Azure AD Connect (version 1.1.524.0 and after) now facilitates the use of ms-DS-ConsistencyGuid as sourceAnchor attribute. When using this feature, Azure AD Connect automatically configures the synchronization rules to:

Use ms-DS-ConsistencyGuid as the sourceAnchor attribute for User objects. ObjectGUID is used for other object types.

For any given on-premises AD User object whose ms-DS-ConsistencyGuid attribute isn't populated, Azure AD Connect writes its objectGUID value back to the ms-DS-ConsistencyGuid attribute in on-premises Active Directory. After the ms-DS-ConsistencyGuid attribute is populated, Azure AD Connect then exports the object to Azure AD.

Please remember to mark one of the responses as answer if your question has been answered. If not please let us know if there are anymore questions. Thanks

Hi Frank,

the question is: why does the cloud user lose sync with the target AD user when the source AD user is removed from sync (i.e. by deleting it)?

Azure AD Connect uses ms-DS-ConsistencyGUID to match users and it is the same for source AD and target AD user.

The workaround is to manually reconfigure the cloud user immutable ID with the target AD user's objectGUID, then the sync works again. But this cannot be the solution.

Best regards
Ben

You experience this behavior because of three reasons:

1. Azure AD Connect writes the mS-DS-ConsistencyGUID during provisioning, e.g. when a user object comes into scope of Azure AD Connect the first time.
   

2. Azure AD Connect writes the Base64 representation of the value in the objectGUID attribute in the mS-DS-ConsistencyGUID attribute.
   

3. When you move a user object between Active Directory forests, the new user object in the destionation Active Directory forest has a different value for the objectGUID attribute than the user object in the source Active Directory forest.

Because the object falls out of scope of Azure AD Connect, Azure AD Connect will apply provisioning logic to the object when it comes back into scope. (1). It uses the value of the objectGUID attribute (which has changed, 3) to write a new value to the mS-DS-ConsistencyGUID attribute (2).

Because the new user object has a new mS-DS-ConsistencyGUID value, Azure AD Connect cannot hard-match the on-premises object to the cloud object. When you also removed e-mail addresses from the proxyAddresses attribute of the on-premises user object, soft-matching based on this attribute is also not possible, in which case Azure AD Connect creates a new cloud object.

Hi Sander,

the ms-DS-ConsistencyGUID is the same for both AD users (I verified that) but as it had been generated when syncing the source AD user for the first time, it matches the objectGUID of the source AD user - should not be an issue.

Nevertheless, we migrated the ConsistencyGUID with ADMT when moving the user to the target AD.
All other attributes like mail and proxyaddresses have been migrated via PowerShell.

So this is why I cannot understand this behaviour as both soft and hard match should work here.

Best regards
Ben

Not sure of your exact process but the hard match works in my case, the only time it doesnt is when I don't move the object out of sight of Azure AD connect in the source forest, at which point the metaverse gets two objects and creates a duplicate. In my setup we have one Azure AD connect with both forests added.

For this reason I do the following as part of the migration process.

1. Disable Sync scheduler (Set-ADSyncScheduler -SyncCycleEnabled $false)
   

2. Perform user migration from source to target forest
   

3. Move the source object out of sight of Azure AD connect
   

4. Re-enable sync scheduler (Set-ADSyncScheduler -SyncCycleEnabled $true)

In the case where I don't do step 1, sometimes the background sync kicks in whilst both source and target user accounts are in place. The conflict then leads to a duplicate account in the tennant.

If I follow step 1-4 above then the hardmatch of ms-DS-ConsistencyGUID takes place 100% of the time and the same Immutable ID exists in the tennat objects before and after the ADMT user migration.

Hi,

thanks for your reply!

We did some testing in the meantime (deleting user in the source forest/disconnected source forest/etc.) and have come to the conclusion that the issue was somehow related to the duplicate proxy addresses, because we did not have this issue with any other user during testing.

We assume that the following happened:
- Office 365 reported duplicated proxy addresses (in this case, soft match will not work)
- We removed sync from the user and added it again - soft match did not work
- Hard match compared immutable ID and objectGUID from target user which is not matching - new user was created
- Manually modified immutable ID to match objectGUID of target user - sync works again

Maybe this has something to do with rule priority in Azure AD Connect (target AD is synced last so source objects do not count anymore).

Hello Benk,

I'm facing the same kind of migration you described.
I have to consolidate several AADC-synchronized forests into one single forest.

Is that you can share with me the different ways you followed to migrate users to the new forest and make the match with AADC.

I'm available if you want to talk privately.

Thank you in advance.

Regards

Hi BocarFofana-0865,

the process is pretty straight-forward:
1. Configure Azure AD Connect to sync user from source forest
2. Migrate Exchange mailbox via HCW or 3rd party tool, if existing
3. Migrate user from source to target forest via ADMT or 3rd party tool - user object in target forest should have the same ms-DS-Consistency-GUID as the source user
4. Depends on the environment (i.e. migrate client from source to target forest so that user must login with new user, etc.)
5. Remove user from source environment (or disable it but removing will show if the migration was successful and AADC only takes the target account for syncing now)

Regards
Ben