Planned retirement
Why this needs action before 3 November 2026
Microsoft 365 Message Center notice MC1448379 and current Microsoft Learn guidance state that the public preview of the Entra memberOf dynamic-rule operator is ending. After the deadline, affected dynamic membership groups, dynamic administrative units and Entitlement Management auto-assignment policies stop updating and stay in their last-known state.
This is a difficult failure mode because the configuration can still exist and its previous membership can still be used. Someone removed from a source group may retain access, a new starter may not receive a licence, or an administrative or Conditional Access scope may become inaccurate without a clear outage drawing attention to the problem.
Confirm the notice in your own tenant
Review MC1448379 in the Microsoft 365 Message Center and recheck Microsoft Learn before making production changes. Record the deadline, affected services, owner and migration decision in the organisation's change or risk process.
Avoid a scope misunderstanding
The dynamic-rule operator is retiring—not every use of “memberOf”
Dynamic groups
User or device membership rules containing user.memberOf or device.memberOf are affected. Dependent access, applications and group-based licensing may therefore become stale.
Dynamic administrative units
Affected membership rules can leave administrative scope inaccurate. Validate both the resulting membership and which administrators can manage it.
Entitlement Management
Affected automatic assignment policies are expected to be quarantined: the policy remains, but assignment processing stops until the rule is rebuilt.
Not the same thing
Ordinary Entra or Active Directory group membership, Microsoft Graph membership APIs and the on-premises AD memberOf attribute are not the retiring dynamic-rule operator.
Map the consequence
A stale group can quietly affect several controls
Start with dependencies, not only rules
For every affected object, record what consumes it, the business purpose, the accountable owner and the consequence of someone being incorrectly included or excluded.
Discovery
Find every affected configuration
Export dynamic membership groups
Use the Entra admin centre export and search membership-rule text for memberOf. Include both dynamic user and dynamic device groups.
Check dynamic administrative units
Use Microsoft Graph PowerShell or the administrative-unit inventory to identify dynamic rules containing the operator.
Check automatic access-package assignments
Review Entitlement Management policies and identify automatic assignment rules that depend on group membership.
Map downstream assignments
For each result, identify licences, applications, policies, access packages, administrative roles and collaboration resources that use it.
Do not search only by display name
The risk is in the rule text and its dependencies. A group name may not indicate that it uses memberOf, and the same group may drive several unrelated controls.
Replacement design
There is no single replacement for every scenario
Use authoritative attributes
Where data quality is dependable, build a supported rule from attributes such as job title, department, location, extension attributes or appropriate device properties.
Assign source groups directly
If the consuming service accepts several groups, direct assignment can remove the need for an aggregation group. Confirm whether nested membership is supported.
Use assigned membership
For a small, stable population, a governed assigned group may be proportionate if ownership and periodic review are clear.
Use controlled automation
If no supported rule expresses the requirement, automation may maintain membership—but it needs credentials, monitoring, error handling, ownership and recovery.
Choose the simplest option that represents the business requirement accurately. Replacing one opaque dependency with an unowned script or unreliable attribute does not reduce risk.
Anonymised operational example
Replacing group aggregation with reliable hybrid-directory data
A hybrid organisation used a dynamic group to combine Project Managers and Team Leaders who required Microsoft 365 Business Premium. The original rule depended on membership of two source groups:
user.memberof -any (group.objectId -in ['ID-OF-GROUP-A']) or
user.memberof -any (group.objectId -in ['ID-OF-GROUP-B'])
Because job-title data was accurately maintained in on-premises Active Directory and synchronised to Entra ID, the organisation could express the underlying business requirement directly:
(user.jobTitle -eq "Project Manager") or
(user.jobTitle -eq "Team Leader")
Why this is a stronger design
The replacement removes dependency on two intermediate groups and connects licensing to an authoritative role attribute. Its reliability still depends on accurate job-title maintenance, successful directory synchronisation and evidence that the new population receives the intended licence.
This example reflects a completed operational migration. Historical comparison figures were not retained, so it illustrates the replacement approach rather than quantified results.
Safe migration
Replace, compare and validate before removing the dependency
Capture the starting state
Export the existing rule, membership, processing status, assignments and known exceptions. Record the rollback point.
Build the replacement safely
Use a test group or non-production assignment where possible. Keep production dependencies unchanged while evaluating the new result.
Compare membership
Identify users or devices present only in the old result, only in the new result and in both. Investigate every unexplained difference.
Validate downstream behaviour
Check licences, Conditional Access evaluation, application access, administrative scope and access-package assignments—not membership alone.
Move dependencies in a controlled order
Avoid creating an access or licensing gap. For licence migrations, confirm the destination assignment before removing the original one.
Monitor and close
Test joiner, mover and leaver changes; monitor processing and assignment errors; document residual risk; then pause or remove the obsolete configuration.
Use the RACF-CC Safe Enforcement Pattern
Inventory → pilot → compare → validate → migrate → monitor → reviewThe technically correct replacement is not complete until access, licences and operational outcomes have been verified. Open the Safe Enforcement guide →
Evidence and residual risk
Prove the outcome—not just the rule change
Attribute-based rules transfer risk to data quality
If job title, department or another source attribute is incomplete or slow to update, access and licensing can still become inaccurate. Assign ownership for the source data and monitor exceptions after migration.
Sources and status
Recheck Microsoft guidance before migration
- Microsoft 365 Message Center archive: MC1448379 — public archive of the retirement notice; verify the notice in your own tenant.
- Microsoft Learn:
memberOfdynamic rules and migration — scope, deadline, limitations and Microsoft migration guidance. - Microsoft Learn: Manage dynamic-group processing — processing behaviour and rule-efficiency guidance.
- Microsoft Learn: Dynamic administrative-unit membership — rule management and conversion considerations.
- Microsoft Learn: Access-package automatic assignment — quarantine behaviour and replacement requirement.
- Microsoft Learn: Group-based licensing — safe order of operations and licence-assignment error checks.
Last checked: 10 August 2026. Dates and product behaviour can change. Treat the notice in your organisation's Microsoft 365 Message Center and current Microsoft Learn documentation as authoritative.
Voluntary support
Found this useful? Support Trends4You
Trends4You's practical guides, RACF-CC resources and downloadable tools are provided free of charge. If they've helped you or your organisation, you can support the time and hosting that keeps them freely available.
Support is optional, handled securely by Stripe and does not provide additional access.
