Have you tried to locate the Active Directory security groups that belong to your Dynamics CRM deployment only to find results like this?
First off, why would you ever get results like this? Dynamics CRM 2011 installs 4 Active Directory Security Groups (PrivReportingGroup, SQLAccessGroup, ReportingGroup and PrivUserGroup) by default per deployment. Some people think this is per organization, but that is not correct. No matter how many organizations you have in a CRM deployment, you will only have 4 security groups per deployment in CRM 2011. So, you could have this many groups because you have several CRM deployments installed in this domain. CRM 4.0 also used similar AD security group names, so there may be some left over from old 4.0 deployments or even failed CRM server installation attempts. When you un-install CRM, we do not delete the AD security groups that we create, so I have seen customer’s with orphaned security groups because of that reason as well.
Regardless of why you may have so many, you might want to find out which belong to a specific CRM deployment, or just want to do some clean up in Active Directory. Disclaimer: Make sure you are absolutely positive you do not need the groups before deleting them!
Run this query against any Organization database in the deployment you want to identify AD security group names for:
select ReportingGroupName, SqlAccessGroupName, PrivReportingGroupName from Organization
Note: We do not list the PrivUserGroup name in this table, but it should have the same GUID.
Now you can search in Active Directory and locate the AD security groups that belong to your CRM deployment.
From there you can either move the security groups into a specific Organizational Unit for better organization, or rename them to something that you can easily identify. These groups are tied back to CRM by GUID, so you can move or rename them without issues.
Scenario: What if you renamed your security groups or use pre-created groups for your CRM 2011 server install? In that case you have a bit more work to do, but Sean McNellis covered that in a previous blog post.
Hopefully this information helps to answer the question of which Active Directory security groups belong to your deployment and allows you to do some clean up of old groups in Active Directory.