The problem first came to light when we were unable to connect to the CRM 2011 environment with the Configuration Wizard of the CRM Outlook Client. We’d been receiving the generic error “There is a problem communicating with the Microsoft Dynamics CRM Server. The server might be unavailable. Try again later. If the problem persists, contact your system administrator.”.
We’d done all of the “normal” steps to troubleshooting this error, and after looking at some of our hair pulled out and laying on the floor, we decided to turn on tracing. Tracing at the client did not reveal the issue, but at the server, tracing revealed an access error for a domain user with a familiar name.
Here’s what we found:
Our client required that the SQL Server Reporting Services (SSRS) Service Account and Execution Account run as a Domain Account. Typically we see the service running as Network Service and the Execution Account unspecified, so this difference was not immediately obvious. The access error was for the domain account that was specified as the Service Account and the Execution Account in SSRS Configuration Manager. Here are the areas in SSRS Configuration Manager where the accounts are set.
(The option “Use another account” was selected, and a Domain Account and Password was completed)
(“Specify an execution account” was checked and a Domain Account and Password was completed)
Additionally, this client required that the CRMAppPool run as a domain account, and that domain account was different than the one used to run the SSRS Service and Execution Account.
(The identity of the CRMAppPool was a domain account rather than Network Service)
CRM Professionals who are accustomed to installing and configuring CRM 2011 Servers are already aware that changing the Application Pool identity to a Domain Account requires that the SPN (service principal name) be set on the CRM Front End Server. The two commands that are run at the command prompt are:
Run once for the NetBIOS name and another time for the FQDN (fully qualified domain name) of the server.
We discovered that the SPN must also be set for the Domain Account running the SSRS Service and the Execution Account.
As I mentioned, before the spn was set for the SSRS user, we’d been unable to connect to the CRM Organization with the Configuration Wizard of the CRM Outlook Client. Tracing at the client did not reveal the issue, but at the server, tracing revealed an access error for the user that was running the SSRS Service and Execution Account.
Lesson Learned: Save your hair, tracing is your friend. GOT IT!
But wait, there’s more!
After the Outlook client issue was resolved, we ran into some issues scheduling reports.
We received the error “Operation failed. One or more steps in the request to create or update the snapshot or schedule failed. The following error or warnings occurred: Unable to create the report that you requested.” while trying to create a report schedule.
Perhaps you’ve read in the CRM 2011 Implementation Guide that when the CRM Application Pool runs under a domain account, that domain account should not be associated to a CRM user. The documentation we’ve seen doesn’t really explain why, but we recently learned that the above error is a side effect of not following that “rule”. Inquisitive minds must know, so KB2593042 offers some other complications one might encounter when they run the CRM Application Pool as a domain account that is also a CRM user.
Lesson Learned: They may not always tell you why, but documented Microsoft recommendations should be followed.
We hope this guidance has found you before you pulled your own hair out. Let our CRM Experts know if you need help with SSRS any other Microsoft CRM issues.
Latest posts by JoeCRM (see all)
- How to Assign a Territory to a Lead in Dynamics CRM - May 17, 2013
- Out of the Box Report: Dynamics CRM User Summary - May 16, 2013
- Dynamics CRM / XRM Integration with GIS and PowerMap - May 15, 2013