By David,
Microsoft is retiring the memberOf operator for Microsoft Entra ID dynamic membership rules. It was the one rule that let a dynamic group take its members from other groups: "everyone in Sales EMEA plus everyone in Sales Americas", without listing a single user attribute. It never left preview, and Microsoft has now set the end date.
After November 3, 2026, anything that uses memberOf stops updating. The groups aren't deleted and nothing throws an error. Membership simply freezes in its last calculated state, and from that day every joiner, mover and leaver makes it a little more wrong.
If you run Azure Virtual Desktop, that matters more than it might seem: dynamic groups are often what decide who gets a desktop, which session hosts a policy targets, and who holds the licence that lets them sign in at all.
The short version: run the PowerShell below this week to find every dynamic group, dynamic administrative unit and auto-assignment policy that uses
memberOf. For each one, rewrite the rule on a user or device attribute, convert it to assigned membership, assign the source groups directly, or replace it with a scheduled sync. Do it before November 3, 2026, while membership is still accurate.
Microsoft details below reflect Microsoft Learn and Microsoft 365 message center notice MC1448379 (5 August 2026) as of October 2026, with links at the end so you can check what has changed. Thanks to Tony Redmond at Office 365 for IT Pros for the early write-up.
What is being retired
A dynamic membership rule normally describes the people or devices that belong in a group: user.department -eq "Finance", or device.displayName -startsWith "AVD-". The memberOf operator described groups instead:
user.memberof -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])
device.memberof -any (group.objectId -in ['<groupObjectId>'])
Entra evaluated the listed groups and copied their direct members into the dynamic group. Admins used it for two reasons that still exist after the retirement:
- Flattening for apps and licensing. Many apps, and group-based licensing, only see a group's direct members. A
memberOfgroup turned several groups into one flat group they could read. - Combining groups without a shared attribute. When the people in three groups have nothing in common in the directory,
memberOfwas the only way to build a single dynamic group of all of them.
The retirement covers three places the operator could appear:
Where memberOf is used | What happens after November 3, 2026 |
|---|---|
| Dynamic membership groups (user and device) | Membership stops updating and stays as last calculated |
| Dynamic administrative units | Membership stops updating, so the scope of delegated admins goes stale |
| Entitlement management auto-assignment policies | Access package assignments stop following the rule |
Exchange Online dynamic distribution groups are a separate feature and aren't affected.
Why Microsoft is pulling it
Microsoft's own explanation is about scale. During the preview, Microsoft found that memberOf can slow dynamic membership processing for every dynamic group in a tenant, even when only one rule in the tenant uses it. The preview always carried that warning: test environments only, at most 500 memberOf groups per tenant, at most 50 source groups per rule, direct members only, and no combining it with any other rule or operator.
Microsoft says it is working on an alternative with the scale and reliability the scenario needs, but there is no replacement date. Plan as though there won't be one before November.
Nothing fails on November 3. The groups keep their members, so access keeps working for everyone already in them. That's the risk: the drift is silent, and it only shows up when someone who left still has access, or someone who joined doesn't.
What a frozen group breaks
Every service that reads the group keeps trusting it. Once membership stops updating:
- Leavers keep access. Someone removed from a source group stays in the frozen group, along with the Teams, SharePoint sites, apps and Conditional Access exclusions it grants.
- Joiners don't get access. Someone added to a source group never reaches the frozen group, so they wait on a ticket that nobody can trace to a rule.
- Licences drift. Group-based licence assignment keeps licensing the frozen membership: leavers keep consuming seats, and new starters sign in unlicensed.
- Conditional Access targets the wrong people. A policy that includes or excludes the group enforces against a list that is weeks or months old.
- Delegated admins see the wrong scope. A frozen dynamic administrative unit keeps giving helpdesk staff rights over people who have moved on, and none over the ones who arrived.
- Access packages stop following the rule. Auto-assignment policies stop adding and removing assignments.
Microsoft's preview notes also say a memberOf group didn't always update when a member left a source group or a source group was deleted. Some of your groups may already be out of date, so check membership as part of the migration rather than assuming today's list is correct.
Where AVD estates feel it first
Azure Virtual Desktop leans on Entra groups at every step from licence to logon, so a frozen group shows up in several places at once:
- Application group assignments. Desktops and RemoteApps are assigned to users or groups. If a desktop application group is assigned to a
memberOfgroup, new starters can't see the desktop in the client, and leavers still can. - Licensing. AVD needs each user to hold an eligible Microsoft 365 or Windows licence. Group-based licensing on a frozen group means new users are refused at sign-in for a reason that looks nothing like a group problem.
- Session host targeting. Dynamic device groups decide which hosts receive Intune configuration, compliance policies and security baselines. A
device.memberofrule stops picking up hosts added by a scale-out or a rebuild, so new hosts run without the policies the rest of the pool has. - Conditional Access for AVD sign-ins. Policies that require MFA or a compliant device for the AVD cloud apps are commonly scoped by group. A frozen exclusion group is the riskiest kind of drift: it keeps exempting people who should no longer be exempt.
- FSLogix and storage access. Share and NTFS permissions on profile shares granted to a frozen group stop following your joiners and leavers.
Step 1: Find every memberOf rule
The scripts in Tony Redmond's article filter on rules that start with memberOf. Because memberOf can't be combined with other rules, that catches most of them, but a rule wrapped in parentheses slips through. The scripts below pull every dynamic object and match the operator anywhere in the rule, case-insensitively.
Dynamic groups
Connect-MgGraph -Scopes Group.Read.All
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
Connect-MgGraph -Scopes AdministrativeUnit.Read.All
Get-MgDirectoryAdministrativeUnit -All -Filter "membershipType eq 'Dynamic'" `
-Property Id, DisplayName, MembershipRule |
Where-Object { $_.MembershipRule -match 'memberof' } |
Select-Object DisplayName, Id, MembershipRule
Entitlement management auto-assignment policies
Auto-assignment rules live on the policy's specificAllowedTargets, so this one reads the raw Graph response:
Connect-MgGraph -Scopes EntitlementManagement.Read.All
$Uri = 'https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentPolicies?$expand=accessPackage'
$Policies = do {
$Page = Invoke-MgGraphRequest -Method GET -Uri $Uri
$Page.value
$Uri = $Page.'@odata.nextLink'
} while ($Uri)
$Policies |
Where-Object { $_.specificAllowedTargets.membershipRule -match 'memberof' } |
Select-Object @{ n = 'AccessPackage'; e = { $_.accessPackage.displayName } }, displayName, id
Export each result with Export-Csv and keep it: the list of source group IDs in each rule is your migration plan, and it's the only record of what the group was meant to contain.
Step 2: Choose a replacement
There is no drop-in replacement, so pick per group, based on what reads it.
| Option | How it works | Best for | Watch out for |
|---|---|---|---|
| Rewrite on an attribute | Replace the rule with one on department, companyName, employeeType, an extensionAttribute or, for devices, the display name | Groups whose source groups were really a proxy for "people in X" | The attribute has to be populated and maintained, usually by HR-driven provisioning or Entra Connect |
| Convert to assigned membership | Switch the group's membership type from dynamic to assigned, keeping today's members | Small, stable groups, or as a stopgap before November 3 | Membership is now manual; someone has to own joiners and leavers |
| Assign the source groups directly | Delete the middleman: assign the app group, licence or policy to each source group | AVD application groups, Conditional Access, Intune policies, which all accept several groups | Services that ignore nested groups need each group assigned on its own, not a parent group |
| Scheduled sync | A runbook copies the source groups' members into an assigned group on a schedule | Apps and group-based licensing that need one flat group | You own the script, its identity and its schedule |
Rewriting on an attribute is the cleanest answer when it fits, because the result is a supported dynamic rule with no moving parts. For AVD session hosts it almost always fits: hosts follow a naming convention, so a rule such as (device.displayName -startsWith "AVD-PROD-") replaces a device.memberof rule and picks up every host a scale-out creates.
Converting to assigned in the Entra admin center is done from the group's Properties page by changing Membership type to Assigned. Do it before November 3, while the membership is still being calculated, so the group you keep is accurate on the day you switch.
A scheduled sync recreates what memberOf did, without the tenant-wide processing cost. A minimal version, to run from Azure Automation with a managed identity that holds GroupMember.ReadWrite.All:
Connect-MgGraph -Identity
$Target = '<target group object id>'
$Sources = @('<source group 1 object id>', '<source group 2 object id>')
$Type = '#microsoft.graph.user' # or '#microsoft.graph.device'
$Wanted = $Sources | ForEach-Object { Get-MgGroupMember -GroupId $_ -All } |
Where-Object { $_.AdditionalProperties.'@odata.type' -eq $Type } |
Select-Object -ExpandProperty Id -Unique
$Current = Get-MgGroupMember -GroupId $Target -All | Select-Object -ExpandProperty Id
$Wanted | Where-Object { $_ -notin $Current } |
ForEach-Object { New-MgGroupMember -GroupId $Target -DirectoryObjectId $_ }
$Current | Where-Object { $_ -notin $Wanted } |
ForEach-Object { Remove-MgGroupMemberDirectoryObjectByRef -GroupId $Target -DirectoryObjectId $_ }
Get-MgGroupMember returns direct members, which matches what memberOf did. Swap it for Get-MgGroupTransitiveMember if you want nested members too, something memberOf never offered. Before you turn removals on, run the script once with the two final lines replaced by Write-Output, and compare the result with the frozen group.
Step 3: Validate, then retire the old rule
- Compare membership. Export the old group's members and the new group's members and diff them. Every difference is either drift the old rule had already accumulated, or a gap in the new one.
- Move the consumers. Point each app group, licence, Conditional Access policy, Intune assignment and share permission at the new group, or update the rule in place if you kept the same group.
- Test a joiner and a leaver. Add a test user to a source group and confirm they reach the desktop, receive a licence and fall inside the right policies; remove them and confirm it all goes away.
- Remove the old rule. Once nothing reads it, delete the old group or administrative unit, so a frozen copy can't be reassigned by mistake next year.
Government clouds
Microsoft's documentation lists memberOf as available in the public cloud only. GCC High and DoD tenants never had the operator, so there is nothing to migrate there. If you manage both commercial and government tenants, run the discovery scripts against the commercial ones.
How Atlas AVD helps
Atlas AVD reads your Entra groups directly, so you can check a tenant without writing any PowerShell:
- Groups lists every Entra group in the tenant, and the Dynamic: Yes filter narrows it to dynamic groups. Open a group to see its Membership Rule and its processing state.
- The Entra Group Membership Report exports a page per group with members, owners, role assignments and, for dynamic groups, the membership rule, which gives you a dated before-and-after record of the migration.
- Automatic AVD Consent, the setting that suppresses the single sign-on consent prompt for session hosts, maintains its own dynamic device group using a
device.displayName -startsWithrule built from your host name prefixes. It doesn't usememberOf, so it keeps working after November 3. If you replaced its rule with a custom membership rule override that usesmemberOf, change the override to a name-prefix rule and re-apply it.
For managed service providers, that's the same check across every customer tenant from one console; see the centralized MSP dashboard. And if you're still designing how groups map to host pools, the top 10 Azure Virtual Desktop mistakes covers the assignment patterns that age well.
FAQ
When does the memberOf rule operator stop working?
Microsoft ends the preview after November 3, 2026. From then on, dynamic groups, dynamic administrative units and entitlement management auto-assignment policies that use memberOf stop updating and keep the members they had at their last calculation.
Will my memberOf groups be deleted?
No. The groups, administrative units and policies stay, with their current members. They just stop changing, so anything that grants access, licences or policy through them goes stale over time.
Are Exchange Online dynamic distribution groups affected?
No. Exchange Online dynamic distribution groups are a separate feature with their own filters, and the retirement doesn't touch them.
What is the replacement for memberOf?
Microsoft hasn't shipped one. Its guidance is to replace memberOf with supported rule operators or convert the group to assigned membership. In practice that means rewriting the rule on a user or device attribute, converting to assigned, assigning the source groups directly, or flattening them with a scheduled sync.
Can I convert a memberOf dynamic group to an assigned group?
Yes. Change the group's membership type from dynamic to assigned in the Entra admin center. Do it before November 3, 2026, while membership is still being calculated, and plan who will maintain joiners and leavers afterwards.
Does this affect Azure Virtual Desktop?
Only if your AVD setup uses a memberOf group somewhere: application group assignments, group-based licensing, Conditional Access, Intune targeting of session hosts or profile share permissions. A frozen group there means new users can't see their desktop or get a licence, and leavers keep access.
Is GCC High affected?
No. Microsoft only offered the memberOf operator in the public cloud, so GCC High and DoD tenants have no memberOf rules to migrate.
Microsoft details in this article are taken from Microsoft Learn as of October 2026: Configure dynamic membership groups with the memberOf operator, Create simpler, more efficient rules for dynamic membership groups, Manage users or devices for an administrative unit with dynamic membership rules and Configure an automatic assignment policy for an access package, and from Microsoft 365 message center notice MC1448379. Dates and guidance change, so check those pages before you plan around them.