Thursday, January 17, 2013

CRM 2011 rsProcessingAborted error when running custom reports

Have you had a situation where the default reports in CRM 2011 and reports created from VisualStudio work, but reports created from the Report Wizard (or any Fetch based reports) result in a rsProcessingAborted error?


















When you have errors in CRM, the first thing to do is to turn on tracing to get the detailed error. There are a few things you can do to resolve the issue. Lets go through them one by one!

1. Lets consider the error below:

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 error is due to a negotiate exception that is occurring with a fail to the SSPI.  Given the rsProcessingAborted and SSPI failure, we are looking at an SPN issue as none are registered under the domain account currently running the CRM AppPool.  

Here is how to check the list of spn's registered:
C:\>setspn -l <user running crm app pool>

Run the following setspn commands on all CRM app servers which should resolve this reporting issue:

setspn -a HTTP/<crm application server name> <user running crm app pool>
setspn -a HTTP/<crm application server FQDN> <user running crm app pool>

Example:
setspn -a HTTP/CRM1 crmuser
setspn -a HTTP/CRM1.test.com test\crmuser

2. There is another possible cause for the report issue. Lets consider this from the error log:

System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.44.195.20:808 ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: An unexpected error occurred. ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: Could not connect to net.tcp://usolgwwcis001/CrmSandboxSdkListener-w3wp. The connection attempt lasted for a time span of 00:00:20.9960000. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.44.195.20:808.  ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.44.195.20:808
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
   at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
   at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
   --- End of inner exception stack trace ---

This error is due to port 808 not open/ accessible on the CRM front end server. Here is the list of network ports that are needed for Dynamics CRM: http://technet.microsoft.com/en-us/library/hh699823.aspx

We can check if the port is open by trying a telnet command from the sql server reporting services server:
C:\>telnet 10.44.196.22 808

Make sure you can telnet to all of your CRM front end servers, and then try running the report.

3. If opening the port still does not resolve the issue, and you get a similar error regarding connection to port 808, here is one additional thing that you can do:

On the CRM front end server, go to Start menu, and type "windows" in search programs and files section. Choose the "Windows Firewall with Advanced Security" from the list




























Select Windows Firewall properties link.
















Make sure that the Inbound connections is set to "Allow". By default, with the Firewall state set to "Off", the value for the Inbound Connection is set to "Block". 


























If there are other possible solutions to fix the issue, please let me know and I will add them to the list. Thanks for reading!

3 comments: