Written by Sean McNellis, Microsoft Premier Field Engineer.
As businesses are starting to plan for Microsoft Dynamics CRM 2011 installations and upgrades, we’ve begun to see questions within Microsoft Premier Field Engineering 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. If it is not installed, certain features will not work properly: reporting will not function, creating new organizations, and organization imports 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:
- * 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.
NOTE: The IIS Web Server will also install the following role services:
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 place 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). In the case of a synchronous plugin, the web application server will contact the sandbox service; in the case of an asynchronous plugin, the async service will contact the sandbox service. 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!
Editor’s Note: if you want to check out more great Dynamics CRM content written by Microsoft Premier Field Engineers, make sure you visit Dynamics CRM in the Field.