Monday, November 17, 2014

CRM 2013 Invalid Argument FetchXML Report Errors on Premise

I love it when my former-self comes to the rescue of my present self.  I have been wrestling with an SSRS error that I knew I had seen before.  In searching for an answer, I ran across this blog post I wrote a couple years back.  I'm going to copy it here, just in case my former employer decides to take it down:



Even though the Report Wizard has some inherent limitations, it is still a useful tool for end-users that want ad-hoc reporting, or if you want to see beyond the 10,000 record limit when exporting to Excel.  You may find however that reports created by the Report Wizard return an "Invalid Argument" error. 
This happened to me recently so I followed my usual debugging steps but that did not help because the browser didn't return an error.  I checked the CRM and SSRS event logs, but there wasn't any helpful information in the errors that were logged.  Next I checked the SSRS HTTP Log and found some interesting information.  Note, the default location for the log is:
\Microsoft SQL Server\\Reporting Services\LogFiles
In the log I saw that I was getting a security error:
System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed
When I looked up this error, I ran across KB2590774 which described the exact issue I was facing...unfortunately it involved SPNs; probably my least favorite administrative topic.
The instructions are a little contradictory.  It says that all you need to do is setup an SPN for the CRMAppPool...unless you are running IIS in Kernel Mode (generally the recommended configuration).  If running Kernel mode, you are supposed to review the information in the article about SPNs and IIS 7 Kernel Mode.
I read and confirmed that for my configuration (Scenario 2b - Custom app-pool and host header)the recommendation was to register an SPN for my custom URL on the NetBios name (aka, the computer name).  Unfortunately this did not resolve my issue, even after adding "trust for delegation" in AD.  So I tried the KB's recommendation which was an SPN for NetBios name on the CRMAppPool account:
setspn -s HTTP/my_server_name my_domain\my_CRM_app_pool_identity
After that SPN was applied (always using -S to check for duplicates) the FetchXML reports instantly started working!

No comments: