Reports not working-Microsoft.Crm.CrmException: An unexpected error occurred – System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception-System.ComponentModel.Win32Exception: The target principal name is incorrect
Posted July 27, 2012on:
If we are using FetchXML as the method to query the data to generate the Report in Dynamics CRM (either using OOB report or Custom Reports), we could often see the below error while generating the report.
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
This is caused because, 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.
Simple step to resolve with an example of the server configuration that I have worked with.
CRM Nodes: CRMDEV1.corp.domain, CRMDEV2.corp.domain
CRM Load Balancing URL: http://crmserver.corp.domain
SSRS Node: http://SQLSRV.corp.domain/RSCRMDEV/
CRM App Pool Account: CORP\CRMAppPool
Below configuration needs to be done on the Report Server.
Under the Registry HKLM\SOFTWARE\Microsoft\MSCRM,
add a String “SandboxClientSpn.CRMDEV1.corp.domain”, value “HTTP/CRMFetch(CRMDEVSERVER)”
add a string “SandboxClientSpn.CRMDEV2.corp.domain”, value “HTTP/CRMFetch(CRMDEVSERVER)”
Open command prompt and add a SPN for the Application Pool Account.
SetSpn -a HTTP://CRMFetch(CRMDEVSERVER) CORP\CRMAppPool
Above is a simple workaround to get the issue resolved immediately.
Other way of doing it is to, Configure the SPN’s for CRM Nodes (with and without Fully Qualified Domain Names) along with the AD CRM Server (with and without Fully Qualified Domain names) + Changing the CRM authentication to let useAppPoolCredentials to “true” in web.config. This approach has some additional steps too based on the IIS version and authentication Model (Keberos / Kernel Mode Authentication) etc.,
Hope this helps.