Intune Filters vs Assignment Groups: Stop Treating Them as Interchangeable

Intune, Microsoft 365 2 Minutes

image

If your Intune estate has grown past a couple of hundred devices, you’ve probably built a forest of dynamic groups that only you understand. You don’t need another group. You need a filter. Here’s where each one earns its keep, and where MSPs keep getting the split wrong.

The mental model

Groups answer who the policy targets. Filters answer which subset of that assignment it actually applies to at evaluation time. A group is resolved at assignment and refreshed on Entra’s schedule. A filter is evaluated per device, per policy, at the point of applicability. That timing difference is the entire reason filters exist — and the reason swapping one for the other silently changes behaviour.

Use groups for ownership of the assignment (department, site, client tenant, pilot ring). Use filters for device traits that change underneath you: OS version, model, enrollment profile, personal vs corporate, join type.

Prerequisites people miss

  • Filters only work on managed devices and managed apps — the supported workload matrix matters. Not every policy type honours filters, and app assignment filters for MAM are a different object from device assignment filters. Check the reference before assuming your policy can be filtered.

  • Dynamic device groups require at least one Entra ID P1 licence in the tenant. Business Premium covers you, but confirm before promising dynamic membership to an M365 Standard client.

  • The “All users” and “All devices” virtual groups bypass normal targeting logic. If a client’s environment feels “haunted”, check whether a legacy assignment is hitting All devices with no filter.

Where to configure

In the Intune admin center, filters live under Tenant administration → Filters. Build the rule, pick the platform, and save — the filter itself has no targets. You apply it at assignment time on any supported policy (Devices → Configuration → your profile → Assignments → Edit filter).

Groups are managed in the same console under Groups, but remember these are Entra ID security groups — any change you make is tenant-wide, not Intune-only.

The rollout pattern that actually works

  1. Ring by group, scope by filter. Three device groups (Pilot, Early, Broad) assigned by user or device attribute. Apply the same policy to all three with different filters (e.g. deviceOwnership -eq "Corporate" plus osVersion -startsWith "10.0.22").

  2. Exclude filters beat exclusion groups. If you’re excluding kiosks from a CA-backed compliance policy, a filter keyed on enrollmentProfileName is faster to audit than a stale exclusion group nobody refreshes.

  3. Name everything for future-you. FLT-Win11-Corp-NotKiosk beats Filter1. Same for groups: prefix by purpose (INT- for Intune-only, SEC- for CA), include platform, include intent.

  4. Test in report-only. Every new filter goes onto one profile assigned to a lab group first. Confirm the Assignment status report matches expectation before widening.

The pitfalls that will bite you

  • Filter evaluation is not group membership. A filter excluding “personal” devices won’t retroactively remove a policy from a device that was previously “corporate” until the device checks in and the assignment re-evaluates. Plan for the delay during ownership changes.

  • Negation logic is deceptively literal. -notEquals treats a null property as “not equal”, so filters on sparsely populated properties (custom enrollment profile names, model on older hardware) can match devices you didn’t intend. Test with -eq plus include/exclude to lock it down.

  • Overlapping filters on the same assignment don’t AND. If you add a filter and also use include/exclude groups, precedence rules apply — exclude always wins, then filters, then includes. Map this out before complaining about “Intune not applying my policy.”

References

Unknown's avatar

Published by directorcia

Published

Leave a comment