SCCM Active Directory Groups: Building a Security Group Query

Building a user collection based on Active Directory security group membership is a common requirement for targeting user-based application deployments — this WQL query handles it directly, without needing an AD group discovery method configured first.

The Query

select
SMS_R_USER.ResourceID,
SMS_R_USER.ResourceType,
SMS_R_USER.Name,
SMS_R_USER.UniqueUserName,
SMS_R_USER.WindowsNTDomain
from SMS_R_User
where SMS_R_User.SecurityGroupName = "DomainADSecurityGroup"

Using It

Replace "DomainADSecurityGroup" with your actual security group’s object name. Paste this as a query membership rule on a new (or existing) user collection, then update collection membership — every user who’s a member of that AD security group should now appear in the collection. Note: this relies on SCCM’s user discovery having already picked up group membership data, so make sure Active Directory User Discovery is enabled and has run at least once against the relevant OU before troubleshooting an empty collection.

A Common Gotcha: Nested Groups

The SecurityGroupName property reflects group membership as reported by Active Directory User Discovery, which by default resolves direct membership reliably but doesn’t always walk nested group membership the way a live AD query does — a user who’s only in a nested (group-within-a-group) relationship to your target group can be missing from the collection even though they’d show up if you checked their effective AD permissions directly. If a collection looks short compared to what you expect from AD Users and Computers, check whether any missing users are nested rather than direct members before assuming discovery is broken.

Verifying Discovery Data Directly

Before troubleshooting an empty or short collection further, it’s worth confirming the discovery data itself looks right by checking a known user’s discovered security groups directly, rather than assuming the collection query is at fault:

select SMS_R_USER.Name, SMS_R_USER.SecurityGroupName from SMS_R_User where SMS_R_User.UniqueUserName = "DOMAIN\\username"

If that returns the expected group name, the collection query itself is fine and the issue is elsewhere (collection update schedule, incremental updates not enabled); if it doesn’t, the problem is in discovery configuration rather than the collection query.

Resources

• Active Directory
• WQL
• query
• WQL
• our SQL & WQL query library