The installation of Dynamics CRM 2011 in tightly controlled multi-domain Active Directory environments can be a real challenge. Dynamics CRM’s tight integration with Active Directory (AD) is a double-edge sword: having built-in Kerberos single-sign on (SSO) for end-users is a big win for organizations using the Microsoft AD for desktop authentication, but the extraordinary permissions required by the CRM Installation Wizard to setup the directory groups and create SQL databases can be difficult to collect in an enterprise-class environment. The easiest way to install CRM is for the installer to have Domain Admin in the AD and SysAdmin in the SQL Server, unfortunately in a large organization, it can be impossible to find a single person (or account) invested with such omnipotence. Fortunately you can specify groups that already exist using the command-line installation option and a configuration file.
The Dynamics CRM Installation Guide has a description of the services, components and the four AD groups:
Privileged Microsoft Dynamics CRM user group for reporting functions. This group is created during Microsoft Dynamics CRM Server Setup and configured during Microsoft Dynamics CRM Reporting Extensions Setup.
Privileged Microsoft Dynamics CRM user group for special administrative functions; including CRMAppPool identity (domain user or NetworkService). The users who configure Microsoft Dynamics CRM Server 2011 must be added to this group.
All server processes/service accounts that require access to SQL Server; including CRMAppPool identity (domain user or NetworkService). Members of this group have db_owner permission on the Microsoft Dynamics CRM databases.
All Microsoft Dynamics CRM users are included in this group. This group is updated automatically as users are added and removed from Microsoft Dynamics CRM. By default, all Microsoft Dynamics CRM Reporting Services reports grant Browse permission to this group.
A strong case can be made for pre-creating the four Active Directory groups that CRM uses:
Even with pre-created groups though, regulations like SOX and PCI may dictate that an organization maintain centralized access control. By default, Dynamics CRM will automatically add and remove CRM users in the AD ReportingGroup group. In situations where adding users to groups is centrally administered, Dynamics CRM cannot automatically add new users to the AD group. This configuration requires the AutoGroupManagementOff parameter to be specified in the installation configuration files (CRM Server and Reporting Extensions).
There are a number of considerations and additional steps required for an AutoGroupManagementOff installation when using domain accounts to run the CRM services (the recommended approach). CRM has four service accounts, SQL Server can use another 2-6 service accounts and the CRM Email Router should have its own service account. That means each environment can require over 10 Active Directory user accounts and four groups and you are also responsible for making sure the correct users are added to the correct groups. The permutations quickly start adding up.
Note: you also have to consider multi-domain issues if the DEV environment is in a different domain than PROD. This may require you to create additional user accounts for your installer and developer users. You will want to determine if cross-domain access issues will prevent you from connecting to the CRM server.
The final piece of the puzzle is ensuring the correct service accounts are members of the right groups. I have found that there is conflicting and incorrect documentation regarding the group membership requirements. The table below lists the user accounts needed in each group:
Computer and User Accounts
CRM Server, AsyncService, CrmService, DOMAIN\<CRM_Installer>
CRM Server, AsyncService, CrmService
All production CRM users
SSRS Service Account
A key piece that seems to have been overlooked is the requirement that the AsyncService be a member of the PrivUserGroup and SQLAccessGroup groups. If this is omitted the service account cannot login to the SQL Server and the Async services will not start. There are also several errors in the event log, one of which refers to the missing CrmKey:
Exception type: CrmConfigObjectNotFoundException
Exception message: CrmKey With Id = 00000000-0000-0000-0000-000000000000 Does Not Exist
One special service account not listed above is the DeploymentService. According to the documentation, this service is required for using the Deployment Web Service or Windows PowerShell. Accordingly, this service requires very elevated privileges:
Considering how many accounts, groups and administration steps are involved with the AutoGroupManagementOff installation, it may be helpful to create a spreadsheet to help track the details. A sample spreadsheet is shown below:
I hope this information helps your planning and installation go smoothly.
Great blog. However i have a few questions.1. Which CRMAppPool identity account needs to be in the PrivUserGroup,the Services and CRMAppPool IIS Application Pool Identity or the CRMAppPool IIS Application Service Account? 2. Are we required to have an account for Email, SQl, SSRS and scribe? And what the account for scribe is for?3. In your table for AD groups and computer and accounts which CrmService are you reffering to?
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.