Azure AD Connect and AD Groups’s ms-DSconsistencyGUID

Question

Hi All,

I’m doing a concept test in a lab environment and migrate groups between on-premises domains (from D12 to D16) both synchronized to a single tenant using Azure AD Connect (AADC version 1.5.45.0).
My goal is to migrate a synchronized group to the new domain. members of a migrated group differ in old and new domain.
My hope is that Azure AD connect combines members and show all members in azure of the synchronized group.

I cant get it to work like that, it always only show the members of the new domain only.

Here is what I tried:
• Create a group in the D12 (old) domain D12SecGroup.
• Use ADMT to migrate the group to the new domain (D16) (with sidhistory, but plays no role in this scenario)
• In D12\D12SecGroup add User12 as member, In D16\D12SecGroup add User16 as member,
• Then write the D12 group objectGUID to D16 group ms-ds-consistencyGUID:

$D12SG2 = Get-ADgroup -Identity D12SecGroup2 -Server DC12.domain12.org  
$D16SG2 = Get-ADgroup -Identity D12SecGroup2 -Server DC16.domain16.org  
$D16SG2 | Set-ADgroup -Add @{'ms-ds-consistencyguid'=[GUID]$D12SG2.ObjectGUID}  

• Start AADC sync cycle and wait a minute or 2
• Check Azure, and I see only User16 as member

I see this same behavior for security groups and Distribution lists.
Is my assumption wrong that is should combine these members?

I don’t see the effect of using ms-ds-consistency guid.
In the test above, I also created a “control” group, where I didn’t copy the ms-ds-consistencyguid. It behaves exactly the same.

Can anyone help me out / point me to documentation/blog that gives more insight in which power this new AADC feature unlocks ?
The only documentation i found was:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-migrate-groups
https://dirteam.com/sander/2020/04/03/azure-ad-connect-v1-5-18-0-brings-ms-ds-consistencyguid-als-source-anchor-for-groups/

thanks in advance,
Sander

Answer 1

You didn't tell us how the Azure AD Connect topolgy looks like, so I'll be assuming that you are using the Multiple forests, single Azure AD tenant topology.

The docs state that "If you have more than one active account or more than one mailbox, the sync engine picks one and ignores the other." The same should apply to security groups. If you are migrating objects from one forest to another, you should exclude the object in the old forest from the sync. Either by deleting the group in the old forest, by deleting the ms-ds-consistencyguid or by setting the value of its adminDescription attribute to "Group_DoNotSync". The group that is synced to the cloud always reflects the setting on-premises. To have users from both the forests in the group, you need to add them to the security group on-premises first.

Answer 2

Thanks for your answer @Daniel Niccoli
I indeed have 2 AD forests and a single server running Azure AD Connect to one tenant.

Excluding a group in the old forest will cause a problem. Because some members of that group are not migrated yet to the new domain, they rely on membership of a group in the old domain.

Azure Groups synchronized from those forests offer access to 2 types of azure resources:

• enterprise apps
• distribution groups.

There is a way to work around it, for enterprise apps its really easy, add the migrated to group to allow access to the enterprise app.
But for distribution groups its a lot more work.
Since they are "universal" AD groups, I can't add members from another forest. I can recreate ~1000 distribution groups in Azure and then nest the synchronised AD distribution groups to the new Azure distribution group.
Current distribution groups have owner/moderation/bypassmod/mustauthtomail2list/owner/nestedDG's settings etc. for 1000s of distribution lists i need to "copy" to the new Azure Distribution group.
I created a script that can do this. however the state of those current AD synced lists are not ideal. the exceptions take me days to figure out what actually the state is of a distribution group.
So I came across the new feature in AADC where I hoped AADC would merge members from 2 AD groups to a single Azure AD Group. but that doesn't work like i expect it to work. maybe it can be done with custom sync rules. but then I dont exactly see what the group ms-dsConsistencyGuid field does for groups.

I'm down to 8 distribution groups I need to figure out why they would fail when i use the current version of the script. then i can run it in production and this issue no longer blocks my project. but it would be nice if it works without having build complex scripts.

I will share the script on GitHub, that i will link in this thread. if anyone in the future might land here. The script creates the distribution groups in Azure and add Azure Recipients to the list. removing all dependencies from one premises AD.

Answer 3

Not a bad solution however I'm surprised you didn't have any issues with Exchange Permissions being lost.

Groups are not soft deleted in Azure but always hard deleted, your process would delete the group and reprovision it. Although you have the same email address and member list. This would mean that any access granted to that group in exchange online would also lost.

The sync chain is as follows:

Before:
OnPremGroupA--->AzureADGroupA--->ExchangeOnlineGroupA--->GrantedAccessToMailbox

After:
OnPremMigratedGroupA--->AzureADMigratedGroupA--->ExchangeOnlineMigratedGroupA

Since the group is fundamentally a new group access will not be re-established.