In environments with multiple Azure AD Connect installations, sometimes, you experience unexpected behavior. For instance, when you want to change the source anchor from objectGUID to mS-DS-ConsistencyGuid for your Hybrid Identity implementation.
The situation
An organization leverages multiple Azure AD Connect installations. One installation is the actively synchronizing Azure AD Connect installation, the other installations are Staging Mode installations. Only the actively synchronizing installation performs exports to the connected Active Directory and Azure AD directories.
All Azure AD Connect installations were initially configured with the objectGUID attribute as the source anchor. The source anchor was not migrated to the mS-DS-ConsistencyGuid attribute till date.
The issue
Changing the source anchor requires running the Configure Source Anchor task in an Azure AD Connect installation. Then, you need to make the same changes on the Staging Mode servers as well.
However, when running the Configure Source Anchor task on the (first) Azure AD Connect Staging Mode server, you receive the following error:
The cause
The error is caused, because Azure AD Connect checks the contents of the mS-DS-ConsistencyGuid attribute of objects in scope to see if no other application, system or service uses the attribute. Overwriting these values could potentially be catastrophic for these solutions.
The solution
The actively synchronizing Azure AD Connect installation is the service that writes values in the mS-DS-ConsistencyGuid attribute. As a Staging Mode Azure AD Connect installation doesn’t perform export actions, it does not actually write to the mS-DS-ConsistencyGuid attribute. Therefore, the issue can be safely ignored, and Azure AD Connect can be instructed to do so.
On the Staging Mode server(s) we need to start Azure AD Connect differently. Instead of starting AzureADConnect.exe from the Desktop or Start Screen, we need to start it from an elevated Command Prompt window with the following two commands:
cd C:\Program Files\Microsoft Azure Active Directory Connect
AzureADConnect.exe /SkipLdapSearch
Then, we can run the Configure Source Anchor task without the error.
Concluding
A Staging Mode server checks the contents of the mS-DS-ConsistencyGuid attribute, as it has no knowledge of any actively synchronizing Azure AD Connect installation. This information is not provided from the endpoints that Azure AD Connect communicates with, although they could…
Further reading
Using ms-DS-ConsistencyGuid as sourceAnchor
Explained: User Hard Matching and Soft Matching in Azure AD Connect
Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 1
Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 2
Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 3
Azure AD Connect v1.5.18.0 brings mS-DS-ConsistencyGUID as source anchor for Groups
Hi Sander,
Based on this article, I conclude:
It is possible in a single AD domain environment to install multiple AADconnect servers, each with a separate OU in scope and each synchronizing to a separate tenant and using ms-DS-consistencyGUID.
For the first installation I can just do the setup of AADconnect, from the second I have to use the switch /SkipLdapSearch.
Is this correct?
Yes, that's correct.
I have Domain A syncing user objects to Tenant A with Azure AD Connect A – ms-ds-ConsistencyGUID is the source anchor. I now want to sync user objects from Domain A to Tenant B with Azure AD Connect B, and I want to use ms-ds ConsistencyGUID as the source anchor.
According to Microsoft, this topology is now supported and apparently, source anchor can be reused. My worry is that to do this I need to run the Azure AD Connect wizard with a switch that suppresses an error stating ms-ds-ConsistencyGUID is already in use. As I am not familiar with the deep architecture, I am afraid that Azure AD Connect B might re-write the ms-ds-ConsistencyGUID on the user object in the domain, breaking the object's linkage to the original Tenant A. I need this domain to keep syncing to both tenants for a time.
So my question: Will my Azure AD Connect B see that ms-ds-ConsistencyGUID is already populated and just continue to use that value without re-writing it? Seems like its just a copy of the ObjectGUID anyway, written by Azure AD Connect A when connected to Tenant A.
Would love your insight, before I try this in production!
Hi Tara,
User objects are referenced by their userPrincipalName or proxyAddresses attributes in Azure AD. Both these attributes reference DNS domain names. DNS domain names can only be verified in one Azure AD tenant. As far as I'm aware you're unable to synchronize one user object from Active Directory to multiple Azure AD tenants at the same time for this reason.
You're right that the value in the mS-DS-ConsistencyGUID attribute for users and groups in Active Directory is the base64 encoded value in the objectGUID attribute. As the objectGUID value doesn't change, there is no reason for Azure AD Connect to change the value in the mS-DS-ConsistencyGUID attribute.