If you are an Active Directory Administrator or Active Directory Migration Consultant, then you should find this post enlightening. The ms-DS-ConsistencyGuid attribute is a powerful tool that can be useful in Active Directory migration scenarios. When selected as the sourceAnchor for AADConnect, this attribute links objects in Azure AD (and their respective resources) with their corresponding object in an on-premise Directory. The ms-DS-ConsistencyGuid attribute can be manipulated, re-assigning the linkage between an on-premise object in one Directory to another in a different Directory, assuming all on-premise Directories are synchronizing into the same Azure AD and the same M365 Tenet . In this blog post, we will discuss the usefulness of the ms-DS-ConsistencyGuid attribute during Active Directory migration scenarios and provide a few examples of how to use it.
What is a sourceAnchor?
A sourceAnchor attribute is a bit of a misnomer. It’s not actually a named attribute in an on-premise Directory.
Initially, the sourceAnchor (also sometimes referred to as an immutableId) is not a standard Active Directory attribute, rather it refers to the role of an attribute that used by Azure AD Connect to ‘anchor’ or tie an object in an on-premise Directory to an object in Azure Active Directory. By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor. ObjectGUID is a system-generated attribute; you cannot specify or manipulate this value. This used to complicate and confound migrations.
Enter the ms-DS-ConsistencyGuid.
Version 1.1.524.0 and later of Azure AD Connect supports the use of ms-DS-ConsistencyGuid as the chosen sourceAnchor (immutableId). When using this, Azure AD Connect automatically configures the synchronization rules to:
1) Use ms-DS-ConsistencyGuid as the sourceAnchor for User objects
2) For on-premise AD User object whose ms-DS-ConsistencyGuid attribute isn’t populated, Azure AD Connect writes the Azure AD User’s objectGUID value back to the ms-DS-ConsistencyGuid attribute of the correlated object in the on-premise Active Directory.
Benefits of using the ms-DS-ConsistencyGuid as the sourceAnchor
There are three main benefits of using the ms-DS-ConsistencyGuid as the sourceAnchor:
1) You can specify the value for ms-DS-ConsistencyGuid when creating on-premise AD objects. This is not possible with objectGUID.
2) If you need to reconnect an Azure AD object with a different on-premise AD object (for example, after a forest Restructure), you can simply change the value of ms-DS-ConsistencyGuid in the on-premise AD object that you want to connect, and Azure AD Connect will automatically update the linkage. If you were using an objectGUID as the sourceAnchor, you would need to delete and recreate the object in Azure AD, which would result in loss of data (for example, AAD group memberships, M365 mailbox, etc.).
3) The ms-DS-ConsistencyGuid is replicated more frequently than objectGUID (every 15 minutes by default), so you don’t have to wait as long for changes to replicate from on-premise Active Directory to Azure AD.
How can I use the ms-DS-ConsistencyGuid in an Active Directory migration?
There are many ways that you can use the ms-DS-ConsistencyGuid in your Active Directory migration scenarios. Here are a few examples:
Example 1: User Migration Across Federated Forests with a Shared M365 Tenet
Let’s say you have two federated forests, contoso.com and fabrikam.com, which are both synchronized to the same Azure AD tenant (contosom365.onmicrosoft.com) using Azure AD Connect. You want to migrate users from contoso.com to fabrikam.com, but you don’t want to lose their M365 mailbox data (or any other data associated with their Azure AD account).
To do this, you could:
1) Export the ms-DS-ConsistencyGuid attribute for all user objects in contoso.com using CSVDE or LDIFDE.
2) Populate the ms-DS-ConsistencyGuid attribute for all user objects in fabrikam.com with the values from contoso.com.
3) Disable Azure AD Connect synchronization for contoso.com.
4) Enable Azure AD Connect synchronization for fabrikam.com.
After these mail steps, all M365 databox (and other data associated with the Azure AD account) will be migrated to the new forest, and the users will be able to log in using their existing credentials.
Example 2: Forest Restructure
Say you have an on-premise Active Directory Forest (contoso.com) which is synchronized to Azure AD using Azure AD Connect. You want to restructure your on-premise Forest, and as part of that you want to move all users from contoso.com to a new child domain (child.contoso.com).
To do this, you could:
1) Export the ms-DS-ConsistencyGuid attribute for all user objects in contoso.com using CSVDE or LDIFDE.
2) Populate the ms-DS-ConsistencyGuid attribute for all user objects in child.contoso.com with the values from contoso.com.
3) Disable Azure AD Connect synchronization for contoso.com.
4) Enable Azure AD Connect synchronization for child.contoso.com.
After these mail steps, all M365 databox data (and other data associated with the Azure AD account) will be migrated to the new child domain, and the users will be able to log in using their existing credentials.
Example 3: User Migration Across Domains in the Same Forest
Let’s say you have an on-premise Active Directory Forest (contoso.com) which is synchronized to Azure AD using Azure AD Connect. You want to migrate users from one domain (child.contoso.com) to another domain (child2.contoso.com) in the same forest.
To do this, you would need to:
1) Export the ms-DS-ConsistencyGuid attribute for all user objects in child.contoso.com using CSVDE or LDIFDE.
2) Populate the ms-DS-ConsistencyGuid attribute for all user objects in child2.contoso.child.com with the values from child.contoso.com.
3) Disable Azure AD Connect synchronization for child.contoso.com.
4) Enable Azure AD Connect synchronization for child2.contoso.com.
After these mail steps, all M365 databox data (and other data associated with the Azure AD account) will be migrated to the new domain, and the users will be able to log in using their existing credentials.
The Prestige
If you’re using a toolset like Quest Migration Manager, there may be other properties you’ll typically want to bring over, such as the proxyAddresses attribute from the Source on-premise AD to the Target on-premise Directory. Also, whatever procedure you follow, you’ll want to document as part of your User Cutover procedure, which you’ll likely follow throughout the duration of user migrations.
Conclusion
As I believe this article has shown, the ms-DS-ConsistencyGuid attribute can be extremely useful in Active Directory migration scenarios, as it allows you to maintain the same Azure AD account for a user even if their on-premise Active Directory account is moved to a different domain or forest. This can save a lot of time and effort when migrating users between forests or domains while ensuring that service disruptions are kept to a minimum. If you are planning an Active Directory migration, make sure to take advantage of the ms-DS-ConsistencyGuid attribute to make the process as smooth and seamless as possible.
New to trading? Try crypto trading bots or copy trading
