Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications

|

Missing SPNs for Domain Accounts Running SSRS Service and Execution Account Wreaks Havoc on CRM Outlook Client Configuration

Post Author: Joe D365 |

Here at PowerObjects, we recently performed a MIcrosoft Dynamics CRM 2011 implementation where we learned a few new things we'd like to share with you, the CRM community.

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.

Missing SPNs

(The option "Use another account" was selected, and a Domain Account and Password was completed)

SSRS

("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.

Happy CRM-ing!

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

3 comments on “Missing SPNs for Domain Accounts Running SSRS Service and Execution Account Wreaks Havoc on CRM Outlook Client Configuration”

  1. I am yet o deploy CRM & SQL using Network Sevice accounts as this is not the best recommendation for security. If SQL & CRM installation guidelines are followed using standard domain user accounts selected during the installation wizards then you won't experience any of the problems that you came across here. Even when producing demo & development environments we usete same 'best practices' as this ensures testing environments represent live and you don't come across any catches come go-live time.

  2. Hi,

    We have the exact same problem and I just wanted to ask you exactly what SPNs have you added for SSRS: for the account under which SSRS service runs pointing towards CRM server or SSRS server?

    Thank you for your answer, we don't have much hair left... 🙂

    Saso

  3. Hi Saso,
    We added a SPN for the account running the SSRS services to the Front End CRM server to solve the problem. Two entries, one for the FQDN and one for the NetBIOS name.

    Glad we could help and I hope your hair grows back soon. 🙂

PowerObjects Recommends