Entra dynamic group not updating: causes and real fixes

An Entra dynamic group that has stopped updating is usually not broken. It is waiting, it is unlicensed, or it is running a rule that can never match, and all three look identical from the group blade. From 3 November 2026 there is a fourth cause, and it is the quiet one: any rule built on the memberOf operator stops updating and freezes membership exactly where it stands. Here is how to tell the four apart before you rewrite a rule that was correct.

Group membership is an input to nearly everything else in a tenant. A stale group means a policy scoped to the wrong people, licences sitting on leavers, and access that should have been withdrawn a fortnight ago. The scoping half of that problem belongs to the Conditional Access policy design guide. This page is about the group itself, and why it is not moving.

One disclosure. My tenant is a lab with no enrolled devices and a small number of accounts, so I have not watched a tenant with thousands of dynamic groups queue behind itself. What follows is documented behaviour, verified against Microsoft Learn on 10 September 2026, plus the places where I would expect it to hurt.

Read the processing status before you touch the rule

The group Overview page carries a membership processing status and a last updated date. Microsoft’s guidance for dynamic membership problems is to check both before concluding anything, because an Entra dynamic group still working through its first evaluation looks exactly like one with a broken rule.

Editing the rule at that point is the worst move available. The edit restarts evaluation, the clock goes back to zero, and you have destroyed the only evidence you had about whether the original rule worked. Read the status, note the time, and wait.

How long an Entra dynamic group should take to update

Microsoft gives two answers on two pages and both are true. The troubleshooting page says directories with small numbers of users see changes in less than a few minutes, directories with a large number of users can take 30 minutes or longer to populate, and that a group could take up to 24 hours to populate for the first time or after a rule change. The processing page puts the steady state at a few hours, and adds that under certain conditions processing can take more than 24 hours.

Read them together as one working rule: minutes is normal in a small tenant, hours is normal in a large one, and 24 hours is the line past which you have a problem rather than a queue.

Three things drive the number. The count of dynamic groups in the tenant, because every one of them is evaluated. The volume of user and device changes in flight, because they queue. And the rule itself: Microsoft names match, contains and memberOf as inefficient operators that increase processing time. A tenant that has grown to several hundred groups built on -contains has bought itself a slow queue, and every other group in the tenant waits in it.

The memberOf rule stops updating on 3 November 2026

This is the newest cause and it will not announce itself. The memberOf operator never left public preview, and Microsoft’s page now states that the preview ends on 3 November 2026, after which dynamic membership groups, dynamic administrative units and entitlement management auto assignment policies that use memberOf stop updating and remain in their last known state. The message centre notice is MC1448379, published 5 August 2026.

There is no error and no warning on the group. It keeps its members, keeps its rule, and quietly stops reflecting reality. Everything downstream inherits that: group based licensing, Conditional Access assignment, Teams and SharePoint membership, and any administrative unit scoped the same way. New starters do not arrive in the group. Leavers do not leave it.

Until then the operator carries limits that also explain groups which never populated at all. There is a ceiling of 500 memberOf groups per tenant, a maximum of 50 source groups in a single rule, no nesting one memberOf group inside another, and no combining memberOf with any other rule or operator. Only direct members of a source group count, so a source group that is itself built from nested groups contributes nobody.

1# The two shapes to search your rules for before 3 November 2026.
2# Only direct members of the listed source groups are evaluated.
3user.memberof -any (group.objectId -in ['00000000-1111-2222-3333-444444444444'])
4device.memberof -any (group.objectId -in ['00000000-1111-2222-3333-444444444444'])

The documented replacements are an ordinary attribute based rule, or converting the group to assigned membership. Both are worse in the one way memberOf was good. You lose everyone in that group as a concept and have to rebuild it out of attributes you actually maintain, which is a data quality project rather than a group edit. That work lands in under two months.

Rules that can never work

The portal accepts several rules that cannot produce a member under any circumstances. The rule reference, updated 13 August 2026, states the restrictions plainly:

• A single rule cannot contain both users and devices. Pick one object type per group.
• A device rule can reference only device attributes, so membership based on the owner’s department or job title is not possible. Filtering on device properties at policy evaluation time is a Conditional Access device filter job, not a group job.
• You cannot manually add or remove a member. If someone has been adding people by hand, they have been adding them to the wrong group.
• The direct reports rule cannot be combined with any other rule, and it covers a manager’s direct reports only, never the tree below them.
• Multi value extension properties are not supported in rules.
• The organizationalUnit attribute is no longer listed and Microsoft says not to use it.

Then the commonest cause of all, and the least interesting one: the attribute is empty. A rule on department matches nobody when HR maintains department in the HR system and nothing writes it into Entra. In a synchronised tenant that is a question about what the sync engine is actually carrying, which is an Entra Cloud Sync and Connect Sync question rather than a group question. Check the object in the directory, not the source system.

The licence gate, and the limit the documentation disagrees about

Dynamic membership requires a Microsoft Entra ID P1 licence, or an Intune for Education licence, for every unique user who is a member of one or more dynamic membership groups. Not per group, per user. Device members of a device based group need no licence of their own. If you are working out whether the tier is worth buying for this alone, the P1 and P2 licence maths is the same calculation as everything else in that SKU.

The tenant limit is where the documentation contradicts itself. The rule reference, updated 13 August 2026, says a single tenant can have a maximum of 15,000 dynamic membership groups. The service limits page, updated 4 August 2026, gives the same figure and adds that dynamic administrative units and entitlement management automatic assignment policies count towards it. The troubleshooting page, which is the page Google returns first for this exact problem, was last updated on 15 January 2025 and still says the maximum is 5,000, complete with the error text you see when you hit it. Checked on 10 September 2026: the working number is 15,000, and the page most people land on is out by a factor of three.

The failure modes

1. The group populated once and has not changed since. Read the rule before anything else. If it contains memberof, that is your answer from 3 November 2026, and it is worth confirming now rather than in January.
2. Dynamic group policies max allowed groups count reached. The tenant limit, and the error text still quoted on the stale troubleshooting page. Count dynamic administrative units and entitlement management assignment policies as well as groups, because they share the ceiling.
3. The rule saves, the status reads complete, the group is empty. The rule is syntactically valid and semantically false. Query one user you expect to match and look at the attribute in Entra rather than in the HR system or in on premises Active Directory.
4. Membership is correct in the group and wrong everywhere else. The group is not the last step. Group based licensing, Conditional Access assignment and application access each re evaluate on their own schedule, so confirm the consumer has caught up before rewriting a rule that is already right. I have not measured those lags in a production tenant and would not quote a figure for them.
5. Everything slowed at once, across unrelated groups. Processing is tenant wide, so one expensive change starves everything else. Microsoft’s own threshold for a large scale change is more than 500 groups or more than 20,000 membership changes, and for those it documents pausing processing and allowing a minimum of 24 hours for the queue to catch up afterwards.

What I would do differently

Do not create anything new on memberOf. The operator is convenient enough that people are still building with it, and every group built this month is rework in November. Audit for it first, replace it second, and treat the audit as the deliverable: knowing which Conditional Access policies and licence assignments sit on top of a memberOf group is most of the work.

Treat dynamic membership as a convenience, not as a control. A 24 hour envelope is fine for putting new starters into a distribution list and useless for removing access from someone who left this morning. Anything where the speed of removal is the point belongs in assigned membership, or in a policy that evaluates at sign in time rather than one that waits for a group to catch up.

Keep the operators cheap and the group count low. Every Entra dynamic group in the tenant is a recurring cost paid by every other one, and -contains written out of habit where -eq would do is the most common way that bill goes up.

Last verified: 10 September 2026.