Group structure is one of those decisions that feels low-stakes early and becomes load-bearing later. Get it wrong and you spend the next two years working around it.
The architecture article covered the principles – dynamic versus assigned groups, the role of filters, why you want fewer groups than you think. This article covers how to actually build it: what to create first, what to name things, and what to avoid.
Start with device groups, not user groups
Most Intune policy targets devices, not users. Configuration profiles, compliance policies, and endpoint security policies all apply to device objects. Start there. The first groups you create should be your core device assignment groups – the ones that will carry your baseline policies for the life of the environment.
I use three device groups as the foundation for every deployment. A pilot group for testing policy changes before broad rollout. A production group that carries all devices that have passed pilot. And an exclusion group for devices that need to be held back from specific policies – typically shared devices, kiosks, or lab machines that don’t fit the standard configuration.
The pilot group is assigned. You add devices manually when you’re ready to test something. The production group is dynamic, built on a rule that captures all enrolled Windows devices not in an exclusion group. The exclusion group is assigned – you add devices to it deliberately when you need to hold them back.
If a device isn’t in your pilot group and isn’t excluded, it’s in production. That’s the only way the model stays manageable.
Naming convention
Groups need names that communicate purpose without requiring you to open them. The naming convention I use encodes the platform, the scope type, and the function:
Intune - Devices - Windows - PilotIntune - Devices - Windows - ProductionIntune - Devices - Windows - ExclusionIntune - Devices - macOS - PilotIntune - Devices - macOS - ProductionIntune - Users - All LicensedIntune - Users - Pilot
The prefix keeps Intune-related groups together in the directory. The platform segment tells you immediately what the group is for without opening it. The function segment – Pilot, Production, Exclusion – tells you its role in the assignment model.
Avoid names like “All Windows Devices” or “Intune Users” without additional context. Those names age badly. Six months from now, when you have five groups that could plausibly be described as “all Windows devices,” the ambiguity becomes a real problem.
Dynamic group rules
The production device group should be dynamic. The rule captures all enrolled devices of a given platform. For Windows:
(device.deviceOSType -eq "Windows") and (device.enrollmentProfileName -ne null)
That rule will pull in every Windows device that has gone through enrollment. If you need to exclude specific device types – Surface Hubs, HoloLens, shared devices registered differently – add those conditions to the rule rather than managing exclusions through the assigned exclusion group. Keep the exclusion group for operational hold-backs, not structural ones.
For macOS, the equivalent rule targets device.deviceOSType -eq "MacMDM". For iOS and Android, you’ll need separate groups per platform – iOS and AndroidForWork respectively.
One thing worth knowing: dynamic group membership evaluation is not instant. After a device enrolls, it can take several minutes – sometimes longer in large tenants – before it appears in dynamic groups and receives its policies. This is normal. It’s not a reason to use assigned groups instead. It’s just something to account for when you’re testing enrollment and expecting immediate policy application.
User groups
User-targeted policy is less common in a well-designed Intune environment, but you’ll need it for a few things – app availability assignments, some VPN profiles, and anything where the user context matters more than the device context. The user group structure can be simpler than the device structure.
Start with two: a licensed users group and a pilot users group. The licensed users group is dynamic, built on the Intune license attribute. Everyone with a valid Intune license is in scope. The pilot users group is assigned – you add specific users when you want them to receive something ahead of the broader population.
Don’t recreate your org chart in Entra groups. Department-based groups exist in most directories already. Use them for user targeting if they’re accurate and well-maintained. If they’re not – and in most environments they aren’t – don’t build your Intune assignment model on top of unreliable data.
What not to build
The most common mistake I see is building too many groups too early. A group for each department. A group for each location. A group for each application. The intent is granular control. The result is an assignment model that nobody can reason about, where the same device is in fifteen groups and nobody is sure which policy wins when they conflict.
Every group you create is a thing you have to maintain. Build the minimum structure that supports your assignment model, then add groups only when a real requirement demands it.
Intune filters are the right tool for targeting within a broad group – targeting specific OS versions, device models, or enrollment types without creating a new group for each combination. Use them before reaching for a new group. The group structure should stay flat and legible. Filters handle the nuance.
Intune Deployment Guide · Phase 2: Identity and Tenant Foundation
‹ Previous: [2.2] Groups, Roles, and Access Boundaries
Next: [2.2.2] Privileged Identity Management: Architecture and Build Guide ›
