Entra ID memberOf dynamic rules stop updating on 3 November 2026: find and replace them

The memberOf operator let a dynamic group in Microsoft Entra ID pull in the members of other groups, which made it popular for licensing and app assignment. It never left preview, and Microsoft is ending that preview: after 3 November 2026, anything still using it stops updating. Nothing shows an error; access just quietly goes stale. In this post I'll explain what Microsoft has announced, give you Graph PowerShell to find every affected group, administrative unit and access package policy, and show how to replace them and prove the result.

What is changing#

A memberOf rule looks like this, and could only be written in the rule syntax box because the rule builder never supported it:

user.memberof -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])
device.memberof -any (group.objectId -in ['<groupObjectId>'])

Microsoft explains that during the preview it saw memberOf slow down dynamic membership processing for all groups in a tenant, even when only one such rule existed. That's why the preview is being retired instead of moving to general availability.

Who is affected#

Any tenant that used the operator in one of three places:

• Dynamic membership groups (user or device).
• Dynamic administrative units.
• Entitlement management auto-assignment policies for access packages.

What breaks if you do nothing#

Membership freezes at its state on the retirement date. Joiners who are added to a source group don't get access, and leavers who are removed keep it. Microsoft lists the consequences: outdated Teams and SharePoint access, Conditional Access policies targeting the wrong people, group-based licenses that no longer follow staff changes, and stale access package assignments. Because the group still exists and still has members, nothing looks broken in the portal. Leavers keeping access is a security finding; joiners lacking a license is a helpdesk ticket.

What to do now#

1. Find every rule that uses memberOf#

Run this with Microsoft Graph PowerShell. It needs read permissions only:

Connect-MgGraph -Scopes 'Group.Read.All','AdministrativeUnit.Read.All','EntitlementManagement.Read.All'

# Dynamic groups
Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
    -Property Id, DisplayName, MembershipRule, MembershipRuleProcessingState |
  Where-Object MembershipRule -match 'memberof' |
  Select-Object DisplayName, Id, MembershipRuleProcessingState, MembershipRule

# Dynamic administrative units
$au = Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/beta/directory/administrativeUnits?$select=id,displayName,membershipType,membershipRule'
$au.value | Where-Object { $_.membershipRule -match 'memberof' } | ForEach-Object { "AU: $($_.displayName)" }

# Access package auto-assignment policies
$pol = Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentPolicies'
$pol.value | Where-Object { ($_ | ConvertTo-Json -Depth 20) -match 'memberof' } | ForEach-Object { "Policy: $($_.displayName)" }

The two Invoke-MgGraphRequest calls return the first page only; follow @odata.nextLink if you have many units or policies. Microsoft's own guidance also suggests exporting dynamic groups from the Microsoft Entra admin center and searching the rules, which is a good cross-check.

2. Record what each group feeds#

Before you change anything, write down where each group is used: license assignments, Conditional Access, Intune assignments, Teams or SharePoint, app assignments. Also save the current member list, so you can compare later:

Get-MgGroupMember -GroupId '<groupId>' -All |
  Select-Object Id, @{n='UPN';e={$_.AdditionalProperties.userPrincipalName}} |
  Export-Csv .\before-<groupId>.csv -NoTypeInformation

3. Choose a replacement for each group#

To change a group's rule from PowerShell:

Connect-MgGraph -Scopes 'Group.ReadWrite.All'
Update-MgGroup -GroupId '<groupId>' -MembershipRule '(user.department -eq "Sales")' -MembershipRuleProcessingState 'On'

For administrative units, Microsoft's guidance is the same: replace the rule with supported logic or switch the unit to assigned membership. For access package policies, replace the memberOf logic with attribute-based rules where possible, or plan another assignment method, such as users requesting access or an admin direct assignment.

4. Make the changes in a sensible order#

Start with groups that feed licensing and Conditional Access, because stale membership there costs money or weakens security. Change one group, let processing finish, and check it before moving to the next: a rewritten rule that matches nobody removes everyone's license just as surely as a frozen rule leaves leavers in place.

How to verify#

• Re-run the step 1 script: it should return nothing.
• On each changed group's overview page in the Microsoft Entra admin center (Entra ID › Groups › All groups), the dynamic rule processing status shows processing has completed, and MembershipRuleProcessingState is On.
• Compare the new member list with your before-*.csv export. Differences should be people you can explain, such as leavers the old rule hadn't removed yet.
• Test a joiner and a leaver: add a test user to the attribute or source group and confirm they gain the license or access, then remove them and confirm they lose it.
• For access packages, check the policy's assignments list for the same joiner and leaver.

If licenses don't follow the new membership, group-based licensing errors covers the common causes.

Timeline#

If you're reading this after the date, the steps are the same: replacing or removing the memberOf configuration is still the fix, so work through the list in the same order and compare each group against its expected membership.

References#

• Configure dynamic membership groups with the memberOf operator (preview) (including "Migrate before the preview ends")