Fabrikam: A Dynamic Group That Is 340 Members Short

Diagnosis: this is an attribute-hygiene problem, not a group problem.

Dynamic membership is evaluated only against cloud attributes. Two failures combine here:

• department is never populated for a large slice of users (30% blank), so the rule can never match them.
• Where it is populated, the string is inconsistent. Dynamic rules are case-insensitive, but leading/trailing whitespace and typos break -eq matches silently.

Why you cannot just add the missing people: dynamic groups do not accept manual members. Any manual correction is impossible, and any portal edit to department on a synced user is overwritten at the next sync cycle.

Design the fix at the source of authority:

1. Decide per forest which attribute is authoritative for department. Compare department and extensionAttribute3 via Graph (/users?$filter=department eq null) to quantify the gap per forest.
2. If on-premises is authoritative, add a directory-extension mapping to department in the sync configuration, or run HR-driven inbound provisioning to Entra ID so the cloud attribute is mastered by the HR system. Pick one writer per attribute.
3. Normalize at the source (trim, canonical casing, controlled value list). Do not paper over bad data with additional rule clauses.
4. Validate the rule with the portal rule validator against sample users before you commit it; on large tenants, a rule change can take many hours to re-evaluate the whole population, so the first roll-out should be verified on a subset rather than by repeatedly re-editing the rule.

Use administrative units (AUs), not a new custom role.

• Create an AU per business unit and populate it dynamically (for example a membership rule on companyName or an extension attribute that marks contractor cohorts). Note that a dynamic AU supports a single membership rule and only certain user/group properties.
• Assign the helpdesk group an AU-scoped role assignment for User Administrator. A scoped assignment only lets the holder act on objects inside that AU, which is exactly the least-privilege boundary the tenant-wide role lacks.
• Reset scope: User Administrator is enough for password resets on non-privileged users. If the helpdesk must also reset passwords for users holding directory roles, that requires Authentication Administrator - do not grant it unless the process genuinely demands it.
• Make the assignment eligible in PIM with approval and a short activation window rather than permanent active.
• For executive or break-glass-heavy AUs, consider a restricted management administrative unit: inside an RMAU even a Global Administrator cannot modify the objects unless they hold a role scoped to that AU. That is the right control where accidental or malicious global edits are the risk.

Contractors should not be managed through the AU alone - pair the AU with an access package that expires, so account lifecycle and entitlement lifecycle are handled by different mechanisms.

The constraint: a given object must have exactly one source of authority. Running the legacy sync server and a new sync configuration against the same users produces conflicting writes, and you cannot run Connect sync and cloud sync for the same objects. So the cutover is a scope migration, not a parallel run.

Sequence:

1. Inventory what the legacy server actually does today: attribute flow, password hash sync, and any writeback (password, device, group, Exchange hybrid). Writeback support differs between sync engines - this determines whether the forest can move at all, or must move with a compensating control.
2. Compare the attribute set the forest needs against what the target sync engine can flow. Gaps become either directory extensions or a documented exception.
3. Pilot one OU: disable that OU's scope on the legacy server first, force a sync, confirm the objects are no longer sourced from it, then enable the OU on the new configuration. Never enable both directions first.
4. Verify sign-in, password change, and group membership for the pilot cohort, and check the sync error report for duplicate-attribute conflicts from the other two forests.
5. Only then migrate OU by OU. Budget for the weekly-failure risk by taking a backup of the legacy server configuration before you disable anything - you may need to fall back.