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
This will return something like this:
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.
As always our PFE team is ready to help if you need the assistance. In addition, we have a plethora of other services we offer such as developer training, admin workshops, and code reviews. If you would like to have another Microsoft PFE or I visit your company and assist with the ideas presented on our blog, contact your Microsoft Premier Technical Account Manager (TAM) for booking information. For more information about becoming a Microsoft Premier customer email PremSale@microsoft.com, tell them CRMInTheField or I sent you.
Thanks! Shawn Dieken
Microsoft Premier Field Engineer
Used this today, thanks for the post! I'll be clearing out many orphaned groups after our AD migrations are completed.
Awesome - That's what we like to hear Pete! Let us know if there are any other areas you'd like to see on the blog by using our "Email the blog author" link.
I have a quick query regarding the organzational unit. If we are upgrading from MS CRM 4.0 to MS CRM 2011.
During the import organization wizard, does it attaches the migrated organization with the old OU (crm 4.0) or attaches with the new OU. I am a bit confuse on this bit.
Appreciate if you can answer that query at your earliest.
P.S. Eventually I want to upgrade from CRM 4 to CRM 2013 and I am doing migrate approach (new crm + new sql).
If you do an in place upgrade, then CRM would keep the same security groups in the same OU. If you do a migration upgrade (which is sounds like you have planned for CRM 2013), then you would have new security groups created as that's a new CRM deployment. Each CRM deployment has one set of CRM security groups in AD. Here is a blog post on locating with CRM security groups belong to which CRM deployment. blogs.msdn.com/.../how-to-find-which-active-directory-security-groups-belong-to-your-crm-deployment.aspx
We recommend the migration upgrade approach like you are doing for CRM 2013 vs. the in place upgrade whenever possible. It just allows for better testing, fallback, etc.
1. As you have mentioned that every new CRM deployment creates new groups in AD. if you use the same OU for every deployment does the installation wizard creates new groups in the same OU or updates it. is it a good practice to create different OU for different evrionments i.e. DEVCRMOU , UATCRMOU, PRODCRMOU?
2. While you importing an CRM 4.0 organization into the CRM 2011 instance, does it link this deployment with the old OU/Groups which were created as part of CRM 4.0 deployment because the guids are saved in the organization table.
Thanks for this great blog.
great blog. Can you comment also on what needs to be considered before changing the OU name where CRM creates the AD groups?
Thanks and best regards
You can safely change the OU names where the CRM security groups reside as well. CRM identifies these groups based on SID, so it does not matter what the security group or OU are named.
great to know and many many thanks for the quick reply.
Thanks for the blog post. I have a question concerning these groups though - is it safe to change the scope of these groups?
I want to be able to nest one of these groups inside of another relating to our SharePoint platform, but as they are 'Domain Local' groups out of the box, they cannot be nested in other groups. Could I switch the scope to 'Universal' without breaking our CRM deployment?
Cheers in advance. Regards, Jon.
It's been a long time since I have looked at that, but I don't think that is technically supported. I don't remember why, but there was a reason why they were domain local groups. I would suggest opening a support ticket to confirm and get the latest update on that question.