Entra Dynamic Group Not Updating: A Read-First Processing Status, Rule, and Attribute Triage

Helpdesk: "We created SG-Sales-All as a dynamic group yesterday and half of Sales still isn't in it. Priya moved from Support to Sales this morning and she's still getting the Support apps. And the new DEV-Corp-Laptops group hasn't picked up the twelve laptops we enrolled today. Can you delete the group and recreate it, or just add everyone manually?" An hour later, a second ticket: the SG-CA-Pilot group that's built from two other groups stopped adding people last week.

Don't recreate the group yet, and you can't add people to it by hand anyway: Microsoft says you can't manually add or remove members of a dynamic membership group. A dynamic group "updating" only happens when the whole chain holds: the group really is dynamic (not Assigned) → processing is On, not Paused → the rule is valid and uses supported properties and operators → the user or device object in Entra actually holds the value the rule expects (synced attributes have arrived; device rules read device attributes, not the owner's) → Validate Rules agrees the object should be a member → the service has had time to process the change → the workload that uses the group (Intune, licensing, Conditional Access, an app) has picked up the new membership. Microsoft Learn's dynamic membership rules reference, the processing-status article, and the "Fix problems with dynamic membership groups" page are the sources for that chain, not a forum post that says "just delete it and make a new one."

If the group uses the memberOf operator, jump to Step 6. That preview is ending on November 3, 2026, and Microsoft says groups that still use it stop updating after that date. If the problem is an Exchange dynamic distribution group, that's a different object with different timing (Step 8). If the real question is Intune-only targeting by device property, read Intune Assignment Filter Not Working first. This post covers a Microsoft Entra dynamic user or device group whose membership is empty, stale, or missing specific objects.

TL;DR

• Read the Overview page before anything else. It shows Dynamic rule processing status (Evaluating, Processing, Update complete, Processing error, Update paused, Not started) and Last membership change. "Update paused" or "Processing error" explains most stuck groups.
• Most "not updating" groups are actually "not matching." The rule says department -eq "Sales", but the user object says Sales & Marketing, or the on-premises change hasn't synced yet. Read the attribute on the object, then use Validate Rules, which shows the result of each expression.
• Timing is minutes to hours, sometimes longer. Microsoft says small directories typically see changes in less than a few minutes, large ones can take 30 minutes or longer, the first population or a rule change can take up to 24 hours, and heavy change volume can push processing past 24 hours.
• There's no "process now" button. Microsoft's documented workaround is to edit the rule and add a whitespace at the end, which triggers reprocessing.
• Changing the rule removes people. Members who no longer match the new rule are removed, and converting a static group to dynamic removes members who don't match. Validate first.
• memberOf is a preview with real limits, and it ends November 3, 2026. Direct members only, can't be combined with other expressions, no Validate Rules, and child-group removals don't flow through until the rule is modified.

Where in the chain did it break?

Write down the group's object ID, whether it's a user or device group, the rule text, one object that should be in it (UPN or device name), which attribute changed and where it was changed (Entra admin center, HR provisioning, on-premises AD, Intune), and when. Most tickets are solved by "where it was changed."

Step 1: Capture the exact symptom (read-only)

Separate "the group is wrong" from "the thing that uses the group is wrong" before you touch anything. If the user is already a member, editing the rule won't fix the policy.

Step 2: Confirm the group is dynamic and processing is on (read-only)

In the Microsoft Entra admin center → Entra ID → Groups → All groups, open the group. The Overview page shows two fields Microsoft documents for exactly this ticket:

Last membership change shows a date and time, In Progress, or Unknown (the group might be new). Microsoft notes that after you pause and unpause, this field shows a placeholder until processing finishes, so don't read a placeholder as "broken."

Microsoft also says an alert appears at the top of a group's Overview page if processing hits an error, and an alert appears above All groups if no pending dynamic membership updates could be processed for the whole organization for more than 24 hours. That second alert means it isn't your rule.

Microsoft Graph PowerShell, read-only:

# Read-only. Connect-MgGraph -Scopes 'Group.Read.All'
$groupId = '<group object ID>'

# Is it dynamic, and is processing On or Paused?
Get-MgGroup -GroupId $groupId -Property Id,DisplayName,GroupTypes,MembershipRule,MembershipRuleProcessingState |
  Select-Object DisplayName, GroupTypes, MembershipRuleProcessingState, MembershipRule

# How many members does it have right now?
(Get-MgGroupMember -GroupId $groupId -All).Count

# Every dynamic group in the tenant: paused ones, and any rule that uses memberOf
Get-MgGroup -Filter "groupTypes/any(c:c eq 'DynamicMembership')" -All `
  -Property Id,DisplayName,MembershipRule,MembershipRuleProcessingState |
  Select-Object DisplayName, MembershipRuleProcessingState,
    @{n='UsesMemberOf';e={$_.MembershipRule -match 'memberof'}}, MembershipRule

How to read it:

Two group-type facts that close tickets fast: Microsoft 365 groups can include only users, so a "device" Microsoft 365 group can't exist; and role-assignable groups require assigned membership, so a group meant for Entra role assignment can't be dynamic.

Step 3: Read the rule like the parser does (read-only)

Microsoft's rules reference and troubleshooting page list the mistakes that make a rule match nobody, or fail outright:

Other limits worth knowing before you rewrite anything:

• The rule body can't exceed 3,072 characters.
• The rule builder handles up to five expressions and is available only for user groups. Device rules, direct-reports rules, -contains/-notContains, and complex -any expressions go in the text box.
• A Direct Reports rule can't be combined with other expressions, only covers direct reports (not their reports), adds the manager too, and depends on the Manager property being set on each user.
• The "all users" rule user.objectId -ne null includes B2B guests. Add -and (user.userType -eq "Member") if guests shouldn't be in it.

If you're searching for a property you saw in someone else's rule (for example employee type), check it against the current supported-properties list on Microsoft Learn before you build around it. If it isn't listed, the portal will tell you when you save.

Step 4: Read the attribute on the object, not in the source (read-only)

The rule evaluates the value stored on the Entra user or device object. HR tools, on-premises AD, and Intune are only sources. Read the object directly:

# Read-only. Connect-MgGraph -Scopes 'User.Read.All','Device.Read.All','GroupMember.Read.All'
$upn = 'priya@contoso.com'

# User: the values a user rule sees (Graph returns only a default set unless you ask)
Get-MgUser -UserId $upn -Property DisplayName,Department,JobTitle,CompanyName,UserType,AccountEnabled,UsageLocation,OnPremisesSyncEnabled,OnPremisesLastSyncDateTime,OnPremisesExtensionAttributes |
  Select-Object DisplayName, Department, JobTitle, CompanyName, UserType, AccountEnabled, UsageLocation,
    OnPremisesSyncEnabled, OnPremisesLastSyncDateTime,
    @{n='ExtAttr1';e={$_.OnPremisesExtensionAttributes.ExtensionAttribute1}}

# Device: the values a device rule sees
Get-MgDevice -Search "displayName:LAPTOP-0142" -ConsistencyLevel eventual `
  -Property DisplayName,OperatingSystem,OperatingSystemVersion,TrustType,DeviceOwnership,EnrollmentProfileName,DeviceCategory,PhysicalIds,ExtensionAttributes,AccountEnabled,ApproximateLastSignInDateTime |
  Select-Object DisplayName, OperatingSystem, OperatingSystemVersion, TrustType, DeviceOwnership,
    EnrollmentProfileName, DeviceCategory, AccountEnabled, ApproximateLastSignInDateTime,
    @{n='PhysicalIds';e={$_.PhysicalIds -join '; '}}

# Is the user in the group right now?
Get-MgUserMemberOf -UserId $upn -All | Where-Object Id -eq $groupId

Graph property names don't always match rule names one-to-one (the rule's deviceOSType and deviceTrustType correspond to the device's operating system and trust type), so compare values, not labels.

How to read it:

Microsoft's own first troubleshooting step is exactly this: verify the attribute values, make sure some users satisfy the rule, and for devices, check that synced attributes contain the expected values.

Step 5: Use Validate Rules before you edit (read-only)

On the group, open Dynamic membership rules → Validate Rules. Microsoft documents it as:

Pick three objects: one that is a member, one that should be but isn't, and one that shouldn't be. If the per-expression details say the missing user fails user.department -eq "Sales", you're done with the rule and back to Step 4's data. If validation says the user is a member but the group doesn't list them, it's processing time (Step 7).

Validate Rules can't be used for memberOf rules. Those are Step 6.

Step 6: memberOf rules: limits now, end date soon (read-only)

"Entra dynamic group memberOf not working" is its own search for a reason. The memberOf operator (user.memberof -any (group.objectId -in ['<id>'])) is a preview, and Microsoft lists these limits:

The bigger problem: Microsoft says the memberOf public preview ends, and after November 3, 2026, dynamic groups, dynamic administrative units, and entitlement management auto-assignment policies that use it stop updating and remain in their last known state. Microsoft lists stale Teams and SharePoint access, Conditional Access targeting, group-based licensing, and access package assignments as examples of the gaps that can follow.

Use the inventory from Step 2 (UsesMemberOf) to find them. Microsoft's migration guidance is to replace memberOf with supported rule operators, or convert the group to assigned membership, then validate membership. If the group is no longer needed, pause or delete it. A memberOf group that's "not updating" this month is a migration ticket, not a processing bug.

Step 7: Give processing the time Microsoft documents (read-only)

Microsoft explains that processing is sequential per tenant: changes are evaluated and applied in order, so a large bulk change elsewhere in the tenant can sit in the queue ahead of yours. If the Overview says Evaluating or Processing and the attributes are right, waiting is the fix.

Forcing it. Microsoft says there's no way to trigger processing on demand, but you can manually trigger reprocessing by updating the membership rule to add a whitespace at the end. Do that once, not in a loop.

Pause and resume. Microsoft publishes PowerShell samples that pause all dynamic groups (or specific ones, or all except some) during an incident, and resume critical groups first, then the rest in batches. Its guidance on when to resume is to wait: the troubleshooting article says at least 12 hours, and the "manage dynamic group processing" article says a minimum of 24 hours, then check audit logs and unpause in phases. If you inherited a tenant full of Update paused groups, that's where they came from. Resume critical groups first instead of flipping all of them back at once.

Microsoft's current rules pages list a maximum of 15,000 dynamic membership groups per tenant (an older section of the troubleshooting page still says 5,000). Fewer, simpler rules process faster either way.

Step 8: The group is right, but the thing using it isn't (read-only)

Exchange Online dynamic distribution groups (DDGs) aren't Entra dynamic groups. Microsoft documents their timing separately: since late May 2026, creating a DDG or changing its rules with 5,000 or fewer matching members populates the list immediately; above 5,000, a background process does it within up to 2 hours (during recalculation the DDG keeps using its previous list). After that, every DDG is refreshed at least once every 24 hours, so a user who changes department can keep receiving the old group's mail until the next refresh. Read it in Exchange Online PowerShell:

# Read-only. Connect-ExchangeOnline
$ddg = Get-DynamicDistributionGroup -Identity 'sales-all@contoso.com'
Get-DynamicDistributionGroupMember -Identity $ddg.Identity | Select-Object DisplayName, PrimarySmtpAddress

# Preview who matches the filter right now, before the next refresh
Get-Recipient -RecipientPreviewFilter $ddg.RecipientFilter -ResultSize 100 | Select-Object DisplayName, Department

If the preview shows the user but the member list doesn't, it's the 24-hour refresh, not the filter.

Step 9: Change one thing (only after the read)

Only after Steps 1–8, and only with change control:

# EXAMPLES: deliberate changes. One at a time; Group.ReadWrite.All and at least Groups Administrator.

# Fix the rule. Members who stop matching are removed; Validate Rules first.
# Update-MgGroup -GroupId $groupId -MembershipRule 'user.department -in ["Sales","Sales & Marketing"] -and user.accountEnabled -eq true'

# Resume a paused group (find out why it was paused first)
# Update-MgGroup -GroupId $groupId -MembershipRuleProcessingState 'On'

# Re-trigger evaluation of an unchanged rule (Microsoft's workaround: add a trailing whitespace)
# $g = Get-MgGroup -GroupId $groupId -Property MembershipRule
# Update-MgGroup -GroupId $groupId -MembershipRule ($g.MembershipRule + ' ')

Retest:

1. Watch the Overview page go from Evaluating / Processing to Update complete, and check Last membership change.
2. Re-run Validate Rules on the same three objects from Step 5.
3. Confirm the downstream workload separately (Step 8). Don't edit the rule again because Intune hasn't caught up.

Know what a change does before you save it. Microsoft says that when a rule is enabled or changed, members who no longer meet it are removed and new matches are added; users who meet both the old and new rule stay, without their licenses or role assignments being temporarily removed. Converting a static group to dynamic keeps matching members, removes the rest, and Microsoft warns that original members might lose access until the rule is fully processed.

When a change is justified

FAQ

Why is my Entra dynamic group not updating?
In order of how often it happens: the object's attribute doesn't match the rule exactly (or the on-premises change hasn't synced); processing is paused or hit a rule error; the change is still within the documented processing time; or the rule uses memberOf, which has preview limits and stops updating after November 3, 2026. Read the group's Overview status, then the attribute on the object, then Validate Rules, before editing the rule.

How long does it take for a dynamic group to update in Entra ID?
Microsoft says small directories typically see changes in less than a few minutes, large directories can take 30 minutes or longer, and the first population or a rule change can take up to 24 hours depending on size. Its processing article says changes are usually done within a few hours but can take more than 24 hours under heavy change volume or complex rules. Synced attributes also wait for the directory sync cycle first.

How do I force dynamic group processing?
There's no on-demand trigger. Microsoft's documented workaround is to update the membership rule by adding a whitespace at the end, which triggers reprocessing. If the group is Update paused, set processing back to On instead. Don't loop either change.

Why is my dynamic group with memberOf not working?
The memberOf operator is a preview: only direct members of source groups are added, removals from child groups don't flow through until the rule is modified, it can't be combined with other expressions, and Validate Rules doesn't support it. Microsoft is ending the preview; after November 3, 2026, groups that use it stop updating. Replace it with supported attributes or convert the group to assigned membership.

Why isn't my Intune dynamic device group updating?
Usually the device attribute the rule tests isn't set yet or doesn't use the documented value (Company not Corporate, AzureAD / ServerAD / Workplace for trust type), or the rule references a user attribute, which device rules can't use. Read the device object with Get-MgDevice, validate the rule, and remember the device still has to check in after it joins the group. For Intune-only device-property targeting, Microsoft recommends assignment filters instead.

Related posts

• Intune Assignment Filter Not Working (when a filter should replace a dynamic device group)
• Entra Connect Sync Errors Detected (when the attribute never arrives from on-premises AD)
• AADSTS53003 Blocked by Conditional Access (when a widened dynamic rule pulls users into a block policy)
• AADSTS50105 User Not Assigned to the Application (when app access depends on group membership)
• Conditional Access Baseline for Entra ID (pilot groups and rollout waves)

Free checklist

Dynamic groups are often the pilot and exclusion groups behind Conditional Access, so a rule that stops updating (or a memberOf group frozen after November 3) quietly changes who a policy hits. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=entra-dynamic-group-not-updating

If you want a starting policy set and the exclusions pattern written down before your group-targeted policies grow, the Entra ID Conditional Access Starter Pack has a starter policy library, a break-glass and exclusions playbook, and read-only Graph exports for policies and named locations: https://cashflow4375.gumroad.com/l/nhuyrc?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=entra-dynamic-group-not-updating

Admin Pack Studio; not affiliated with Microsoft. Steps 1–8 only read: the group Overview page, Validate Rules, Get-MgGroup, Get-MgGroupMember, Get-MgUser, Get-MgDevice, Get-MgUserMemberOf, Get-DynamicDistributionGroup, Get-DynamicDistributionGroupMember, and Get-Recipient -RecipientPreviewFilter. Update-MgGroup, pausing or resuming processing, and converting group types are deliberate changes. Change one rule at a time, validate against known members first, and check current Microsoft Learn for limits and preview status, which change often for dynamic groups.