This table is used to hold the AD groups that have been unwound and flattened into a list of users.  It included all AD groups that have access to SQL.  It's a prefetch table so it should have data populated on a regular basis.  This is because the unwinding can take a while so it's more user-friendly to do the prefetch.

This table is populated by the Report.ADAcctsInSQL SP.

As far as columns go, we won't document most of them because they're mostly self-explanatory, but there are some control columns that we'll explain lower in this article.  That said, there is a naming convention  you should be aware of.  The purpose of this table, as stated, is to provide a flattened list of AD group users.  It also has the added advantage of having all of the columns from the Collector.ADGroupMembers table and the Collector.Logins table in a single row.  Now you can easily merge AD and SQL account data.

All of the columns start with either 'ADAcct' or 'SQLAcct'.  The meaning here is clear.  However, the control columns don't  follow this paradigm.  The control columns are listed below:

ExecutionDateTime - The data and time the info was collected.

ServerName - Clearly the name of the server the account has access to.

LimitBy - This is the group of servers used to limit the collection in the Report.ADAcctsInSQL SP.  For more info, see that doc.

LimitValue - This is the value used to limit the collection in the Report.ADAcctsInSQL SP.  For more info, see that doc.

Data Duplication

It's possible that data gets held multiple times in this table as it's held per collection.  That's to say that the LimitBy and LimitValue columns.  This is due to the nature of the SP that fills the table.  That SP is called with those 2 params and saved to the table.  Therefore, if you run a collection with @LimitBy = 'SLA' and @LimitValue = 'Gold', and then another collection with @LimitBy = 'Server' and @LimitValue = 'Server1', they'll both be saved to this table and it's quite possible that Server1 is in both collections.