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.
If PREEMPTIVE_OS Group Lookup is sitting near the top of your wait stats, these are the next places to look.
- The waits that usually matter, ranked, with what each one is telling you.
- SOS_SCHEDULER_YIELD Wait Type, the closest wait worth investigating when this one is high.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply