Why? Because it seems I’m getting an increased number of client requests for help with this stuff. And by “this stuff” I mean how to target resources (users, devices, mostly) for various things like policies, deployments, inventory, audit logging, sign-in activity, etc.

Effectively organizing users and devices is foundational to managing policies, deployments, and security at scale. Whether you’re targeting Microsoft Intune policies, Conditional Access rules, or software deployments, how you group objects determines your flexibility and maintainability. Here’s a breakdown of the most common methods.

In case you’re wondering, I’m not focused on security boundary aspects in this article. This is about identifying or targeting resources and accounts for other purposes (refer to the first paragraph above).

1. Naming Conventions

Using standardized prefixes, suffixes, or patterns in object names (e.g., WKS-NYC-FIN-001, JSMITH, SRV-PRNT-DFW-001).

Advantages:

• Instantly human-readable; easy to identify location, department, or type at a glance
• Works across nearly all platforms and tools—no special features required
• Enables simple wildcard filtering in scripts and queries

Disadvantages:

• Brittle—renaming objects when roles/locations change is tedious and error-prone
• Inconsistent adoption leads to gaps; relies heavily on discipline
• Limited queryability in modern identity platforms (dynamic groups can’t always parse naming patterns)

Administrative Overhead: Simple to start, but moderate to maintain at scale due to enforcement challenges.

Notes: More commonly used for devices than users. However, user names and properties should ALWAYS follow a consistent pattern. For example, if you use the “description” property, be consistent. It can (and often will) pay off incredibly later on when you need to mine that property for operational needs.

2. AD Organizational Units (OUs)

Placing objects in a hierarchical OU structure (e.g., OU=Finance,OU=NYC,DC=contoso,DC=com).

Advantages:

• Native GPO targeting—policies link directly to OUs
• Clear visual hierarchy in AD tools
• Well-understood by most Windows admins, LDAP developers

Disadvantages:

• Objects can only exist in one OU—no multi-dimensional grouping
• Moving objects between OUs can break GPO inheritance unexpectedly
• Irrelevant to cloud-only (Entra-joined) devices and increasingly hybrid environments

Administrative Overhead: Simple for on-prem GPO targeting, but complex when trying to maintain parity with cloud workloads.

Notes: For those still tied to Active Directory, OU assignments should be focused on policy relevance more than visual organization, unless you have a VERY simple environment with very few custom Group Policy Objects. Example image below for Active Directory user accounts.

# active directory
Get-ADUser -Filter "*" -SearchBase "OU=Finance, OU=Users, OU=CORP, DC=contoso, DC=local"

3. Security Groups / Entra / M365 Groups

Assigning users or devices to groups, then targeting those groups for policies or access. Or using them filter inventory, audit logs, etc. for reporting, or targeting deployments.

Advantages:

• Objects can belong to multiple groups simultaneously—flexible multi-dimensional targeting
• Native integration with Conditional Access, Intune, RBAC, and app assignments
• Supports nested groups for hierarchical scenarios

Disadvantages:

• Group sprawl is real—without governance, you’ll end up with hundreds of overlapping groups
• Static group membership requires manual updates or automation
• Troubleshooting “why does this user have access?” becomes detective work, especially with nested groups, multi-domain or forest-trust environments

Administrative Overhead: Moderate—requires naming conventions and lifecycle management for the groups themselves.

Notes: The overhead of maintaining static assignments can be mitigated through automation. For example, when onboarding user accounts, you can assign group memberships based on role-mapping such as department, job title, location, and so on.

Azure Management Groups, Azure Subscriptions, Azure Resource Groups, and Entra ID Administrative Units were not included here since they’re intended for security delegation and cost management more than purely for inventory-oriented organization. Azure Policy assignments are kind of a gray area, and I have enough gray as it is.

Examples using PowerShell without real coffee or quality sleep:

# active directory
$groupMembers = Get-ADGroupMember -Identity "Users-Finance-Managers" -Recursive
$managers = Get-ADGroupMember -Filter { name -like "*managers*" } -Recursive
# entra id (or graph)
$entraGroup = Get-EntraGroup -Filter "DisplayName eq 'Finance-Managers'"
$cloudManagers = Get-EntraGroupMember -GroupId $entraGroup.Id |
  Where-Object {$_.'@odata.type' -eq '#microsoft.graph.user'} |
    Select-Object Id, DisplayName, UserPrincipalName, acountEnabled

4. Dynamic Group Membership

Groups whose membership is automatically calculated based on attribute queries (e.g., user.department -eq “Finance”).

Not applicable to Active Directory domains. Void where prohibited, taxed or regulated. Batteries not included.

Advantages:

• Zero manual membership management—objects automatically join/leave as attributes change
• Ideal for large, fluid environments with frequent onboarding/offboarding
• Enables attribute-driven policy targeting without touching group memberships

Disadvantages:

• Membership updates are not instant—can lag by minutes to hours
• Complex rules are hard to debug; subtle syntax errors cause silent failures
• Requires clean, consistent attribute data—garbage in, garbage out

Administrative Overhead: Moderate to complex—rule authoring is straightforward, but ensuring attribute hygiene is ongoing work.

Note: The time it takes to update membership will be affected by total number of dynamic groups in the tenant, as well as number of object changes per update cycle, and dynamic rule configurations which are complex, and/or rely on operators like Match, Contains or memberOf. See link for more.

5. Attribute-Based Filtering (Direct) / Tags

Targeting objects directly by attribute values in policies or queries (e.g., filtering by extensionAttribute1, department, city). This also extends (conceptually at least) to Azure resource tags.

Imagine if you could literally tag every single thing in your home/apartment or vehicle. Everything. And then you had some magical tool that would find anything based on that tag. “Find spatula” or “Find guitar pick” and it lit up and broadcast it’s precise location. That’s kind of what this about.

Advantages:

• No group management overhead—filter directly on source-of-truth data
• Changes to attributes immediately affect targeting (no group sync delay)
• Highly granular; combine multiple attributes for precise scoping

Disadvantages:

• Not all platforms support direct attribute filtering (Intune filters do; some legacy tools don’t)
• Requires well-governed attribute schema and consistent data population
• Can become opaque—”why was this device targeted?” requires querying attributes

Administrative Overhead: Simple if attributes are already populated; complex if you need to establish and enforce an attribute schema from scratch.

Notes: This is more of a late-binding approach. Very much like using Azure resource tags: It lays the groundwork for other processes to query and return matching items based on search criteria. Some common examples: job title, department, physicalDeliveryOfficeName, employeeType, description, any of the various “extension” attributes, and so on. For Azure, this could be resource tags such as (just examples): “environment”, or “cost center”.

More feeble-minded examples using PowerShell:

# azure virtual machines
$azVMs = Get-AzVM -Status | Select-Object Id,Name,ResourceGroupName,PowerState,Location,Tags
# ...filter by name pattern
$azVMs | Where-Object {$_.Name -match "addc"}
# ...filter by location
$azVMs | Where-Object {$_.Location -eq "eastus"}
# ...filter by tag + value, and powered on
#azVMs | Where-Object {$_.Tags['DomainJoined'] -eq 'contoso.com' -and $_.PowerState -eq 'VM Running'}

Lame example of Azure Virtual machine with resource tags. Just add water, makes its own sauce.

Summary

So, in conclusion: there are many ways you can model an environment to make downstream automation, and reporting easier or more flexible. MBA folks might even say “robust” or “synergistic”, or “wholistically synergistic”, which is fine as long as it means they approve your budget request. Just nod and smile, and say thank you.

Final Thoughts

Most mature environments use a combination of these methods. OUs handle legacy GPO needs, dynamic groups automate cloud policy targeting, and attributes or resource tags provide the underlying data that drives additional flexibility. The key is investing in attribute hygiene early—clean data makes every other method more effective.

Start simple, automate where you can, and resist the urge to create a group for every edge case. Establish standards which are published in a central location, and require all staff to comply or have their company photo replaced with an image of dog poo.

Whatever you do, avoid creating secondary inventory data repositories to link things together. You should have ONE and only ONE source of truth for anything. Don’t make a spreadsheet or database to identify who’s in a department, when you can just populate the “department” attribute, group or tag. Make the systems work for you, not the other way around.

If you’re wondering why I chose the bar photo above, it’s because labeling and organizing bottles is common for most bartenders. Also for hospitals, car mechanics, dentists, electricians, and many other careers. It helps you find the right things when you need them. Not paying attention to that early will lead you straight back to the bar, and, well, you know how that ends.

Disclaimer

Blah blah blah… all information provided is for informational purposes only. Use or adaptation, even derivatives of derived derivations, of anything provided herein, in whole, or in part, is without warranty of fitness or purpose of any kind, in any galaxy or spatial realm, time dimensions notwithstanding. You assume any and all risk for damages, interruptions, delays, weird looks, gossip or drink bottles thrown from passing vehicles. The author assumes no risk or liability or blame or backhanded wierdness, even smirks or unusual grunt sounds, even from creatures with more than two legs. And, no, we don’t accept coupons. I’m not an attorney, but my family could form a law firm if they could stop talking about politics and Bruce Springsteen long enough to do the paperwork. I have no idea where this is going, but I’m sure glad you made it this far! Kirk out.