On a daily basis, our Dynamics 365 support and managed services team at Cobalt helps customers navigate some tricky CRM issues. Our goal is to get you back to accomplishing your task without too much delay, but there are times when an issue takes a little longer than expected.
This is exactly what happened to one of our customers after they attempted to create a report using the built-in Microsoft Dynamics CRM Report Wizard.
Since they had been using both the out of the box CRM reports and the Cobalt custom reports successfully for months, we were surprised to see this. The Cobalt team set to work chasing down possible root causes and have compiled some helpful steps to resolve this issue so that you can get back to cranking out reports.
Need Dynamics CRM or D365 Hosting?
Cobalt has 3 different hosting packages and 15+ years of hosting and Dynamics expertise.
What Does (rsProcessingAborted) Mean?
(rsProcessingAborted) is a generic error message that can appear in many forms. This one in particular informs us that a report cannot be displayed.
As always, the best place to start troubleshooting is the SQL Server Reporting Services (SSRS) logs. In this case we found the following message:
System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://<insertClientCrmOrgHere>/CrmSandboxSdkListener-w3wp. The connection attempt lasted for a time span of 00:00:42.0469367. 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 [2002:c749:241d::c749:241d]:808.
This pointed to a potential firewall issue, but we decided to go through our standard 4-step process for troubleshooting this error just to be sure.
Step 1 – Permissions
The first step is to verify that the account running SSRS has the proper permissions. This should have been setup when CRM was deployed, but if you did not use a dedicated domain account (strongly recommended) you might experience issues with this. Note: you will need access to both the server where SSRS was deployed and a server running Active Directory (AD) for the domain of your CRM deployment.
1) On the SSRS Server, go to Administrative Tools > Services
2) Locate SQL Server Reporting Services (MSSQLSERVER) and make note of the Log On As user
3) On the AD Server, go to Administrative Tools > Active Directory Users and Computers
4) Expand the domain and Organizational Unit (OU) for your CRM deployment (you specified the OU during your CRM installation)
5) You will see the following 4 groups:
- PrivReportingGroup {GUID}
- PrivUserGroup {GUID}
- ReportingGroup {GUID}
- SQLAccessGroup {GUID}
6) Verify that the user from step 2 above is a member of the first 3 groups. If not, add the user to these groups. Note: this user should not be a member of the SQLAccessGroup group.
Step 2 – Set the SPN
This is the step that seems to be overlooked most frequently because most, if not all, CRM features will function properly without it, but making sure that it’s completed will save you a lot of troubleshooting down the road. In this step, we will set the Service Principal Names (SPN) value for the service account running the CRM Application Pool. If you only have one CRM Web server, steps 4 and 5 can be skipped.
1) Open the command prompt with elevated permissions (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
Step 3 – IIS useAppPoolCredentials
The next step is to set the IIS useAppPoolCredentials flag to true for the CRMAppPool service account.
1) On the CRM Server, open IIS Manager
2) Expand the server and navigate to the Microsoft CRM web site
3) Under the Management section in the main panel, select Configuration Editor
4) Using the dropdown in the top left of the main panel, navigate to system.webServer/security/authentication/windowsAuthentication”
5) Find the useAppPoolCredentials in the grid and set the value to True
These first 3 steps typically solve our problems related to CRM reports, so we were stumped. That’s when we discovered this Microsoft article that resulted in us adding step 4 to our checklist.
Step 4 – Firewall
Add an inbound rule to Windows Firewall on the CRM Server to allow for TCP traffic on port 808. This is the port that client computers (i.e. CRM users) use to connect when running Fetch-based reports. Additionally, you will need to make sure that the firewall on your network (or hosting provider’s network) allows TCP over port 808 as well.
Ready to Run Report Wizard Reports
After all of these steps have been taken, open CRM and verify that you are able to successful run the report that originally caused the error. If the error persists, run through the steps to ensure nothing was missed. It is our hope that we are able to help lead you to a resolution but understand that there may be things outside of the scope of this article.
Considering a CRM Migration?
Our team at Cobalt has completed hundreds of secure, seamless CRM migration projects. If you’re considering a move in the next few years, take a look at the best of what we’ve learned through 26+ years of CRM experience:
Our ebook has the best of what we’ve learned after hundreds of seamless, secure migrations with zero downtime. Take a copy for your team with you today and let us know if we can help!
