Hi Lysa,
It’s not inherently a performance killer to base SCCM collections on AD OUs or security groups, but it’s not considered best practice for large environments. The collection evaluator in SCCM doesn’t constantly poll domain controllers; it queries AD during scheduled discovery cycles, and then evaluates membership based on that data. The real drag comes when you have hundreds of collections tied to dynamic AD queries with frequent incremental updates, this can extend evaluation cycles and delay deployments. Native WQL queries against SCCM’s own SQL database are faster because they avoid the dependency on external AD lookups and rely on data already in the site database. Microsoft’s guidance is to use AD discovery only to bring in resource data, then build collections using attributes stored in SCCM itself.
For a merger-scale architecture, you’ll want to minimize reliance on AD structures for operational targeting and instead design collections around SCCM-native queries, which scale better and reduce evaluation overhead.
I hope the information is helpful to you. If it is, please accept the answer, or give it a thump up to let me know. Have a nice day!
Harry.