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:

Group

Description

PrivReportingGroup

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.

PrivUserGroup

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.

SQLAccessGroup

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.

ReportingGroup

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:

  1. The installer does not need to have AD Create permissions as most AD administrators are reluctant to giving them out.
  2. The default CRM groups names include a 32 character GUID, which makes it difficult to distinguish and manage in the typical DEV/TEST/PROD installation scenario.
  3. Some organizations have naming standards that work with automated audit and security tools, so the AD team will require a particular prefix or convention.

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:

AD Group

Computer and User Accounts

PrivUserGroup

CRM Server, AsyncService, CrmService, DOMAIN\<CRM_Installer>

SQLAccessGroup

CRM Server, AsyncService, CrmService

ReportingGroup

All production CRM users

PrivReportingGroup

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:

  • Local Admin on the CRM Server
  • Local Admin on the SQL Server
  • SysAdmin server role in the database

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:

CRM_Users

I hope this information helps your planning and installation go smoothly.