When reports created by report wizard fail when executing with error rsProcessingAborted, there could be a number of reasons. One possible cause is that Service Principal Names SPNs are not set for the Dynamics CRM Service accounts running the CRM Application pool (CRM AppPool).

This issue occurs when you have a dedicated SQL Reporting server and/or when a domain account is used for CRMAppPool. This should not be the cause if you have CRM and reporting server on the same server (or virtual machine) and you are not using a domain account (such as network service). SPNs will be required if you are using a domain account instead of Network Service in this case.

You must already have SRS Data connector for Dynamics CRM installed successfully on the Reporting Server. If not, you need to install it first as it be the cause of the rsProcessingAborted error.

This resolution only applies if Microsoft Dynamics CRM Standard Reports run successfully but reports that were created by report wizard or custom FetchXML reports do not execute successfully. They will usually fail raising the not very helpful “rsProcessingAborted” error.

SQL Reporting Logs will contain this error:

Microsoft.Crm.CrmException: An unexpected error occurred.
System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception.
System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception.
System.ComponentModel.Win32Exception: The target principal name is incorrect

The cause of this error is that the FetchXML query needs to be able to resolve to a HTTP SPN in order to fully communicate between the server. In a scenario where the Microsoft Dynamics CRM application pool is being run by a domain account the query will be looking for a HTTP SPN that does not exist by default.

Sections A and B below will resolve the issue. With the introduction of Kernel Mode authentication in IIS 7 there are additional steps required. For more information see the link at the end of this post:

A) Set the Service Principal Names (SPN) value for the service account running the CRM Application Pool. If there is only one CRM Web server steps 4 and 5 can be skipped.

1. Open an elevated command prompt window. To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

2. Type setspn -a HTTP/<ServerName> <ServiceAccountDomain>\<ServiceAccount>, where <ServerName> is the name of the server, <ServiceAccountDomain> is the name of the domain containing the CRMAppPool service account, and <ServiceAccount> is the name of the CRMAppPool service account.

3. Type setspn -a HTTP/<ServerFQDN> <ServiceAccountDomain>\<ServiceAccount>, where <ServerFQDN> is the fully qualified domain name (FQDN) of the server.

4. Type setspn -a HTTP/<ClusterName> <ServiceAccountDomain>\<ServiceAccount>, where <ClusterName> is the name of the AD RMS cluster.

5. Type setspn -a HTTP/<ClusterFQDN> <ServiceAccountDomain>\<ServiceAccount>, where <ClusterFQDN> is the fully qualified domain name (FQDN) of the cluster.
B) Set the IIS useAppPoolCredentials value to True for the CRM Website:

**Note Installation of the IIS 7 Admin Pack linked below is required. The Admin pack is normally installed by default.

6. In the properties page, set useAppPoolCredentials to True, then select Apply.
To summarise, I used two Set SPN commands to resolve this issue on my VM which had all CRM, SQL RS and SQL Server on the same Virtual machine and when I had a domain service account running the App Pool:

You also must ensure that the Domain service accounts are part of these Active Directory Groups: PrivReporting, PrivUser and SQLAccess Groups

A non-recommended work around is to make these groups have access to the CRM Config DB and each CRM Org DB as well as the Reporting server Database. I strongly don’t recommend doing this as it is much more than what is needed.