Intune group, assignment and maintenance window design
Intune rarely blocks you. For almost any outcome (get this app to those laptops, keep that policy away from the kiosks) there are three or four routes that all work on the day you build them. Some take ten minutes and some take an afternoon.
That flexibility is the product’s strength and its main design risk. Nothing in the console distinguishes the route that will still make sense in year two from the one that quietly accumulates into a structure nobody can read. The cost of choosing wrong does not appear at build time. It appears when someone asks why a meeting-room PC is receiving a policy meant for staff laptops, and reconstructing the answer takes a morning.
Microsoft publishes best practices, and they should be the starting point. But on many day-to-day design decisions the guidance stops short of a single answer, because the right one depends on what you are optimising for. This is the design I have ended up with, and so far it holds up: what to standardise, which targeting method belongs where, and how to decide when a change is allowed to reach a device.
Structure: how groups should be built
Define the naming convention before creating the first group. Reading a group name should tell you exactly what it assigns and to what. This is not housekeeping: it is the decision that makes every other rule affordable, because a structure built from single-purpose groups is only navigable if the names carry the meaning. It is also the only decision here that gets more expensive every week it is deferred.
One target type per group: users or devices, never both. Microsoft’s guidance is explicit that groups mixing users and devices produce policy conflicts and unpredictable deployment behaviour.
Exclusion groups must target the same type as the inclusion group. This is not a stylistic preference: it is a support boundary, and it is the single most important rule in this article. Assigning to a device group while excluding a user group is not supported: Intune does not evaluate the relationship between a user and their devices, so the devices of the excluded users are not excluded. It does not raise an error. It silently does nothing, which means an administrator can believe a population is protected from a policy when it is not.
Avoid nesting. A parent group’s effective membership changes silently when someone edits a child, and the administrator who later uses that parent for an assignment gets no visible signal. There is a second, less obvious cost: when a large group is nested into one Intune uses for targeting, Intune reprocesses all of those memberships, and on a large tenant a single nesting change made by a directory administrator can delay assignment processing across the environment.
Pre-create groups as part of the standard operation of adding an application, policy or script, not afterwards, when naming gets improvised under time pressure.
Give each group one purpose, with one deliberate exception: the master group behind an enrollment profile legitimately carries the baseline for that entire profile: the equivalent of the image in the SCCM era.
Targeting: pick the mechanism, not just the group
Groups are not the only way to scope an assignment, and treating them as though they are is the most common source of avoidable complexity.
Use assignment filters for simple device properties. If the targeting depends on OS, manufacturer, model, ownership or device category, a filter does the job without creating a group at all. It is evaluated at assignment time, so there is no directory sync to wait for, and it does not add to the group count. Microsoft’s explicit recommendation is to prefer filters over dynamic device groups whenever the group would only ever be consumed by Intune.
Use the built-in virtual groups. Do not build your own “All users” or “All devices” equivalents: the built-in targets require no directory synchronisation when a device or user is added.
Reserve dynamic groups for what a filter cannot express, and write efficient rules. Avoid memberOf in dynamic membership rules: if devices need targeting by their membership of something else, look for a direct property (enrollment profile name, device category, manufacturer) that expresses the same population.
Never use a dynamic device group as an exclusion in a latency-sensitive scenario. This is the sharpest edge in the whole design. A device enrols, Intune begins delivering policy immediately, and the dynamic group calculation that was supposed to exclude it has not completed. For that window the device receives exactly the configuration the exclusion existed to prevent. It is documented behaviour rather than a defect, and it is invisible afterwards: by the time anyone investigates, group membership is correct and the evidence is gone. Assign to a user group or the built-in All Devices and narrow with a filter instead.
Group reuse versus blast radius
Microsoft recommends reusing groups as much as possible, and the reasoning is sound: every group and every membership change is work Intune must process, so fewer groups means faster, more predictable targeting.
That pulls against the one-purpose rule above, and it is worth being clear that this is a real trade rather than a rule with an obvious answer.
A reused group means adjusting the assignment for one application silently adjusts it for every other object quietly pointing at the same group, and nothing in the interface surfaces those other consumers. Single-purpose groups contain the blast radius of a change at the cost of group count and sync work.
The practical resolution is to reduce how often the question arises. Most of the specificity that tempts people into a group-per-assignment sprawl belongs in an assignment filter, which costs nothing to sync. Use filters first, keep purpose-specific groups for what genuinely needs them, and treat one-purpose-per-group as the rule to relax first if targeting latency ever becomes the constraint.
Maintenance windows: when change is allowed to land
Structure is half the design. The other half is timing, and it is the same problem, because an update ring is an assignment to a group. When the group model is right, maintenance windows become expressible. When it is not, every change becomes a negotiation.
Three things should be decided deliberately and early: which changes are critical and which are not, what window each class of device gets, and who is entitled to defer.
Which changes are critical. A security patch and a driver update are not the same risk.
Which window each class of device gets. Defined by when it is not in use, not by the clock.
Who may defer. The user on a laptop; nobody on a classroom PC.
Define the window by when the device is not in use
Not by the clock. “Patch overnight” is treated as a universal answer and it is not one.
For a shared classroom or meeting-room machine, the day is the risk and the night is free. A hard blackout across working hours (no updates, no reboots, no notifications) with feature updates scheduled by hand into the gaps in the organisation’s calendar is the right shape. In a teaching environment those gaps are the academic breaks, because those are the only weeks the room is reliably empty.
For a user’s laptop the same reasoning produces the opposite answer. At 3am the device is shut in a bag, so an overnight window reaches nothing. Deferral, a deadline, and the user’s own consent do the work instead.
Same product, same settings, opposite configuration, because the question is not “when do we patch?” but “when is this class of device not in use?”.
Do not force reboots on user devices
Devices should not restart outside agreed hours, and not without the user’s consent, unless a security policy genuinely requires it, and in that case it should be a decision someone signs, not a default left enabled.
This is not a comfort argument. A device that reboots into an update during a customer presentation costs more than the vulnerability it closed, and the cost is not confined to that hour: it is the following six months of that person dismissing every restart prompt on sight. That is how a fleet ends up months behind on patching while every policy reads as correctly configured. Forcing reboots makes the compliance graph turn green quickly and makes the underlying position worse.
On shared devices, where nobody owns the machine, the principle survives in a smaller form: a scheduled overnight restart inside the window when the room is empty, with a short cancellable prompt for the night when it is not. It costs almost nothing and it ensures the automation never overrules someone who is actually sitting there.
Suppress update notifications on shared devices only
On a machine projecting to a lecture hall or a meeting room, hiding update and restart notifications is correct: an interruption there is a room full of people watching a dialog box.
On a user’s device the identical setting is a mistake, because it removes the consent the previous rule depends on. You cannot ask people to choose their restart moment while hiding the fact that a restart is due.
That distinction is only expressible if those populations are separate groups with separate assignments, which is the structural half of this article, arriving from the other direction.
Classify change, then defer accordingly
Treating all change as equally urgent is what makes maintenance windows collapse. A critical security patch and a driver update are not the same risk and should not travel at the same speed.
In practice: security updates on a defined ring with deferral measured in days; feature updates deferred by a month or more and piloted on a ring that opts in; driver updates under manual approval, because a bad driver on a projector or a docking station takes a room out of service in a way a bad security patch usually does not; and application updates pinned to a slow, stable channel rather than whatever shipped this week.
The balance is explicit: a device that is patched and low-risk, and a person who can work without the platform interrupting them. Those goals are in genuine tension, and the design should state which one it is trading in each case rather than pretending they align.
Where to start
Spend the first afternoon on the naming convention, before creating a single group.
Then: one target type per group, never mixed. Exclusions matching their inclusion: that one is a support boundary, not a preference. No nesting. Assignment filters for anything that is a simple device property, dynamic groups only for what a filter cannot express, and no dynamic device group used as an exclusion where enrollment timing matters.
Before the first update ring ships, write down which changes are critical, what window each class of device has, and who is allowed to defer. The procedures build themselves once those three answers exist. Without them every deployment is re-litigated from scratch, and the fleet falls quietly behind while every policy reads as green.
The objective throughout is a tenant where a new request is an assignment to an existing, obviously-named group, rather than one where every request begins with an investigation into what is already there. On day one those cost the same, by month eighteen they do not.