During a multi-forest staged migration, where Domain A (source) and Domain B (target) were both synchronizing into a single Entra ID tenant via Entra Connect, we encountered a membership synchronization issue with mail-enabled distribution groups.

Although users were successfully matched across forests using ms-ds-consistencyguid, mail-enabled group memberships did not merge. Instead, only one forest’s membership list was applied in Entra ID—regardless of where users actually existed or were migrated.

This post explains why that happens, and the precise fix that resolved the issue.

Background: Multi-Forest Sync Behavior in Entra Connect

Entra Connect allows multiple AD forests to sync into a single Entra ID tenant. However, certain object types—especially mail-enabled groups—cannot have attribute arrays merged across connectors.

Key points:

  • The member attribute (group membership) is an array attribute
  • Entra Connect does not merge array attributes across forests
  • Instead, the connector with the highest-precedence inbound rule becomes the authoritative source

Default behavior: the first forest added to Entra Connect typically has higher precedence, making that forest authoritative for group membership.

In our environment, this meant:

  • Even though Domain B contained identical group objects (migrated via Quest)
  • And even though users existed in both forests during transition
  • Memberships in Entra were always taken from Domain A only

This caused migrated users to fall out of critical distribution groups.

Discovery: Where Membership Flow Actually Comes From

Entra Connect uses inbound sync rules—each with a precedence number—to determine how attributes flow into the metaverse.

In most Microsoft examples, member flows through Group Exchange inbound rules. However, in our environment, the member transformation was located in the Group Common inbound rule.

This is important because Group Common applies to all groups:

  • Security groups
  • Distribution groups
  • Mail-enabled security groups

Therefore, any forest with an enabled Group Common rule contributes membership. And whichever forest’s Group Common rule has higher precedence (lower number) becomes the membership “winner.”

For us, that was Domain A.

Root Cause

  • Domain A’s Group Common inbound rule contained the member attribute flow
  • Domain A’s rule had higher precedence
  • Domain B’s memberships were never considered, even when group objects matched via ms-ds-consistencyguid
  • Distribution groups in Entra ID only reflected Domain A’s membership list
  • Migrated users in Domain B dropped from groups unless they still existed in Domain A

This aligned with Microsoft’s design: array attributes do not merge.

Solution: Disable Domain A’s Group Common Inbound Rule

To make Domain B authoritative for group membership, we disabled the inbound rule that supplied membership from Domain A.

Steps

  1. Open Synchronization Rules Editor on the Entra Connect server

  2. Locate the inbound rule labeled similar to:

   In from AD – Group Common (DomainA.com)
  1. Open the rule and verify it contains:
   member → member

under Transformations

  1. Disable the rule entirely for Domain A

  2. Leave Domain B’s Group Common (and optionally Group Exchange) enabled

  3. Run a full synchronization:

   Start-ADSyncSyncCycle -PolicyType Initial

Result

After disabling Domain A’s Group Common inbound rule:

  • Only Domain B’s inbound rules flowed member attributes
  • Domain B became authoritative for group membership
  • Users synced from both forests continued to function normally
  • Distribution groups in Entra ID reflected the correct, complete membership list sourced from Domain B
  • No more disappearing members during staged user migration

Critically, this change did not affect user sync behavior, anchoring, soft deletes, or object matching. Only group membership authority changed.

Verification Process

Using Synchronization Service Manager (MIISClient.exe):

Metaverse Search: Verified that each test group showed only the Domain B connector contributing the member attribute.

Connector Space Preview: For Domain B, Preview → Full Synchronization confirmed membership was properly supplied.

Entra Admin Portal: Group memberships updated as expected after the subsequent export cycle.

Considerations and Safe Practices

  • Always test in staging mode on a secondary Entra Connect server before applying broadly
  • Ensure Domain B group membership is complete before flipping authority
  • Mail-enabled groups require that proxyAddresses and legacyExchangeDN are preserved or identical in Domain B
  • Disabling Group Common for Domain A affects all groups in that forest—confirm that is intended

Conclusion

In a staged migration where multiple AD forests sync into a single Entra tenant, mail-enabled distribution group membership cannot merge across forests. The membership source depends entirely on inbound rule precedence.

In our case, the issue was resolved by disabling the Domain A “Group Common” inbound rule, which contained the membership transformation. This made Domain B authoritative for group membership, allowing us to complete the staged migration without membership loss or distribution group failures.

This approach is clean, repeatable, and aligns with Entra Connect’s supported multi-forest architecture.