There are plenty of articles talking about mS-DS-ConsistencyGuid AD attribute so I’ll be brief and describe it here in my own words first, before jumping to the main topic: How best to handle this attribute with Quest ODM (OnDemand Migration) attribute mapping template. Once this attribute mapping is put in place, it will cover you for the most migration scenarios involving hybrid on-prem and Azure (Entra ID) integrations.
How mS-DS-ConsistencyGuid came into existence
When Azure AD (now Entra ID) was first introduced, Microsoft needed a firm way of matching two identities: on-prem AD objects (user accounts, groups, computers etc.) and their cloud counterparts. They were looking for some on-prem AD attribute that would be 1) Unique 2) Immutable so that it’s derived value, encoded with Base64 string, would then be written as ImmutableID on the cloud matched object. At first objectGUID attribute was selected also calling it SourceAnchor, which was a good choice because it was indeed meeting all these two key requirements, except… Soon after the “Immutable” piece started causing issues during directory migrations because it was, well… too “Immutable”. ObjectGUID is owned by the system and cannot be modified, period!
This is when mS-DS-ConsistencyGuid AD attribute was introduced where during migrations you could actually set it to objectGUID of originating Source (migrated from) AD object since Target (migrated to) object would obtain a different, newly generated objectGUID value. This way, if cloud object and its ImmutableID remains the same like in intra-forest on-prem AD migration scenarios for hybrid environments, or when there’s a need to simply preserve ImmutableID between two cloud tenants when trying to match using Quest ODM, SourceAnchor can be carried over from one environment to another and thus be preserved.
It’s also worth to mention that when mS-DS-ConsistencyGuid is used as SourceAnchor and it’s empty, then AAD (Entra ID) Connect will populate it with objectGUID value and now stick to it during its matching logic. You may still come across the environments with some “edge” cases, where this attribute is empty representing an older AAD (Entra ID) sync engine behaviour, or if service account did not have permissions to write back to AD. But in most scenarios it would still be populated with the value used for the cloud-end matching and it would be beneficial to have this value preserved during migrations. For more reading here’s Microsoft article with the key Entra ID concepts: Microsoft Entra Connect: Design concepts – Microsoft Entra ID | Microsoft Learn
Now we won’t be talking about some advanced scenarios when ImmutableID cloud values are manipulated to re-match objects (yes, it can be done!), or when instead of selecting “Let Azure manage the source anchor” during AAD (Entra ID) Connect installation (it will assume mS-DS-ConsistencyGuid) some other attribute was selected instead on the drop-down list. But even then, described further Quest ODM attribute mapping approach can still be used as a base rule for a different attribute to preserve its SourceAnchor value.
Quest ODM (OnDemand Migration) attribute mapping
Now back to the main topic of this article. When migrating AD objects and setting up workflows, Quest OnDemand Migration tool relies on template that contains set of rules of how and where to create objects, match them, and in particular how to map AD attributes. But it so happens that out of the box ODM AD does not contain mapping for mS-DS-ConsistencyGuid AD attribute, meaning it will be lost during migration. As a result an object with the different ImmutableID will be created in the cloud tenant when synced from on-prem not allowing Quest ODM match Tenant to Tenant on ImmutableID, or match on ImmutableID on-prem to pre-existing cloud object will fail causing migration issues involving object re-matching scenarios. How do we solve it?
Fortunately, Quest OnDemand Migration has attribute mapping logic that can be tailored to your particular migration scenario. Enter the following mapping statements for mS-DS-ConsistencyGuid attribute. This way it will 1) Copy objectGUID if mS-DS-ConsistencyGuid is empty in Source 2) Copy mS-DS-ConsistencyGuid if it’s already populated in Source 3) Will not overwrite pre-existing mS-DS-ConsistencyGuid Target value on merge. This will account for pretty much all migration scenarios, it’s that simple! 🙂
VALUE: if(empty([mS-DS-ConsistencyGuid]),ConvertValue(“base64STR”, objectGUID),[mS-DS-ConsistencyGuid])
CONDITION: empty(T.[mS-DS-ConsistencyGuid])
NOTE: Condition part of this mapping is optional. It may not evaluate Target attribute on creation and will not write mS-DS-ConsistencyGuid value at first, then on next run it will populate attribute according to VALUE logic. So make sure AAD (Entra ID) Connect sync cycle only picks up the objects after attribute is already set or ImmutableID will be incorrectly sourced from the Target objectGUID value. For example, put AAD (Entra ID) Connect sync schedule on pause, create objects outside of sync scope or simply remove CONDITION if overwriting on merge is not an issue. Alternatively, you can simply enter Action = “create” into Condition field and it will make this mapping apply only once at object creation.
