As customers are starting to plan for CRM 2011 installations and upgrades we’ve begun to see questions regarding environment setups.  Here’s a list of the questions I’ve seen thus far:

 

Q: Are the CRM 2011 Report Extensions (commonly referred to as the “report connector”) an optional component?

A: All installations now require the CRM 2011 Report Extensions to be installed and configured on the SQL Reporting Server.  It is not optional and if it is not installed reporting will not function and any organization imports or upgrades will be blocked until the extensions are installed and configured.

 

Q: Do I need to install the CRM 2011 Reporting Extensions prior to installing CRM?

A: No, these should be installed after you install the CRM 2011 Server components.

 

Q: When installing CRM server roles on different servers (ex: install front-end and deployment components on server1 and back-end components on server2) I am not prompted to install the reporting extensions, why is this?

A: When the CRM server roles are installed separately (without first installing a CRM full-server) you’ll notice that no organizations are created by default. Once the servers are all setup and configured, the first step to setup CRM is to launch deployment manager and create an organization. It is at that time you will be required to input a reporting server that has the CRM 2011 Reporting Extensions installed.

 

Q: On CRM 4.0, as long as the report extensions were not installed, a Reporting Server (or scaled out reporting server farm) could host reports for multiple CRM installations/deployments. How has this changed in CRM 2011?

A: In CRM 2011 the Reporting Extensions are now required, which means each Reporting server (or scaled out reporting server farm) with the report extensions installed may only host reports for a single CRM 2011 Deployment.
NOTE: The Reporting Server (or scaled out reporting server farm) can host reports for multiple tenants (organizations) in the deployment.

 

Q: If I were to run all CRM servers services under different service accounts how many service accounts do I need and what CRM groups should each service account belong to?

A: There are numerous configurations you could use to accomplish this, but if you were to separate everything here is a table explaining what group membership is required, I’ve also included SSRS and SQL server:

Component PrivUserGroup
SqlAccess Group PrivReport Group Report Group Perf Log Users* CRM User?

Deployment Services SvcAcct

þ þ - - NO

Application Service (CrmAppPool)

þ þ - þ NO

Async Service SvcAcct

þ þ - þ NO

Sandbox Server SvcAcct

NO - - þ NO

Sql Server SvcAcct

- - - - - -

SQL Reporting Services SvcAcct

þ - þ - - NO

Email Router SvcAcct**

þ - - - - NO

Installing User***

- - - þ - þ

Users in the CRM instance

NO - - þ - þ

* The performance log user group is a local group on each server and not a domain group
** Email router will run as local system
*** The Installing user should be a separate service account, but it should not be used to run any services.
IMPORTANT: If any of the service accounts are created as users in CRM you may encounter various problems, some of which are potential security issues.

 

Q: I am concerned when it comes to security and want to be sure I limit my attack surface whenever possible.  What Windows Server Roles and Features are required for each CRM Server role?

A: Below is a table broken down by the 8 different server roles CRM installs.

Component Web
App
Org
WS
Disc
WS
Help
Server
Depl
Tools
Depl
WS
Async
Svc
Sandbox
Svc
IIS Web Server Role þ þ þ þ - þ - -
.NET HTTP
Activation
- þ þ þ - þ - -
File Server
Indexing Services
- - - þ - - - -
Windows
PowerShell
- - - - þ - - -

NOTE: The IIS Web Server will also install the following role services:
·Web-Static-Content
·Web-Default-Doc
·Web-Http-Errors
·Web-Http-Redirect
·Web-Dir-Browsing
·Web-Asp-Net
·Web-Windows-Auth
·Web-Stat-Compression
·Web-Dyn-Compression
·Web-Mgmt-Console
·Web-Metabase

 

Q: If I want to split up my roles between a CRM Front-End Server and a CRM Back-End Server, but I don’t want to have a third server just for the purpose of hosting the deployment tools.  Is there a best practice or preferred placement given the two choices?

A: The deployment tools can live on either server.  As you see in the chart above, the IIS Windows Web Server Role is required for both the Front-End Server services as well as the Deployment tools.  If you have a goal of minimizing your attack surface and want to limit your installations of IIS, the best location for the Deployment Tools role would be on the Front-End Server as all web services would be hosted on your Front-End Server and the Back-End Server would be hosting non-IIS based components.

 

Q: How does the CRM Front-End Server Roles contact the CRM Sandbox and Async Services and do I need to set anything up or allow for any firewall exceptions?

A: The CRM Async service is not called directly by any of the other services.  The async service operates out of the AsyncOperations queue and will process records as they’re placed into the queue.  However, the Sandbox service operates differently.  When work is handed off to the Sandbox service it is done so over a TCP channel (port 808 by default) from the CRM web application server.  Also, note: if you are: A) Running the sandbox service on a dedicated server (not installing the full server role) and B) running the sandbox service as a service account identity, and not as network service, a dedicated SPN is required in active directory. The SPN would be homed under the service account running the sandbox service and would look like this: MSCRMSandboxService/<SandboxServerName>.  For example: if my sandbox server was named “CRMSandboxSrv01” and my sandbox service ran under CRM_Sandbox_SvcAcct my SPN would look like: MSCRMSandboxService/CrmSandboxSrv01 and the SPN would live under the CRM_Sandbox_SvcAcct user object in Active Directory.

 

Q: If I want to manage my CRM deployment via PowerShell are there any specific recommendations or “gotcha’s”?

A: Currently, if you wish to manage your CRM deployment via PowerShell the Deployment Web Services must be running as a service account identity and not as Network Service. If you run the deployment web services as Network Service certain functions of the CRM PowerShell add-in will return a security error.

 

If additional questions come up feel free to leave them as comments and we’ll do our best to address them in some way, shape, or form.  I hope this helps clear up the confusion around some of the more complex environment configurations and what operating system features and roles are required for various CRM Server Roles.

Thanks for reading!

Sean

 

Note: this article was edited on 6/7/2018 to reformat the tables and content, the content was not changed.