A cluster of preemptive waits track Windows group membership and directory queries, and this page covers them together:
PREEMPTIVE_OS_NETGROUPGETUSERS, NETLOCALGROUPGETMEMBERS, NETUSERGETGROUPS, NETUSERGETLOCALGROUPS, NETUSERMODALSGET, DOMAINSERVICESOPS, and DIRSVC_NETWORKOPS.
They fire when SQL Server asks Windows who belongs to what: resolving a Windows group login’s membership, xp_logininfo enumerating group members, IS_MEMBER() checks that miss the token cache, and assorted directory service operations. Each call can round-trip to a domain controller.
Are They a Problem?
At background levels, no. They become interesting in two familiar ways. Frequency: security audit scripts and applications calling xp_logininfo or IS_MEMBER at high rates generate DC traffic per call, and our own security audit tooling is polite about this for exactly that reason. Duration: slow DCs stretch every lookup, and group-heavy environments (users in hundreds of groups, nested group chains) make each answer expensive to compute.
Login-time group resolution feeding token creation is also part of why users-in-many-groups log in slowly.
What To Do
- Find the frequent callers (audit jobs, apps doing per-request membership checks) and cache results instead of re-asking.
- For duration problems, it is the standard AD latency escalation with evidence attached.
- Keep group nesting sane for SQL-facing groups; token size and lookup cost both follow it.
How To See It
Rank waits with Get-WaitStatistics, reading the family with the authentication waits; they rise together when AD struggles.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply