When CRM 2011 Custom Reports don’t work
If your users can run OOTB (out of the box) CRM 2011 reports, but all custom reports (built using the CRM Report Wizard or designed in BIDS) fail with the rsProcessingAborted error (as shown below), then the solution may be relatively simple.
The solution, in most cases, is to add a SPN (Service Principal Name) for the CRM Application account on the HTTP service of the CRM server.
Before proceeding you should be aware of the following:
- Only use this solution if OOTB reports are working. If OOTB reports are not working, please keep Googling (hint: ensure the CRM Reporting Extensions are installed on your SRS server).
- Adding SPNs can only be done by a Domain Administrator (or user with equivalent privileges).
- Adding an incorrect SPN can cause your CRM application to stop working altogether, so ensure you understand the consequences before trying this. I will provide you with the command to remove the SPN you are adding as well, in case you need to roll the change back.
- You should do this off-hours when no one will be adversely affected by temporary loss of CRM access.
To Add the SPN:
On the CRM server, gather 2 pieces of information from the IIS Manager console:
- The CRM server NETBIOS name (shown below in yellow: CRM5DEV-CRM). Substitute this value for the NETBIOSNAME placeholder in the SETSPN commands below.
- The identity of the service account running the CRMAppPool application pool (shown below in green: SALENTICA\SVCCRM5APP). Substitute this value for the DOMAIN\SERVICEACCOUNT placeholder in the SETSPN commands below.
On a domain controller (or any server with the AD services role), issue the following SETSPN command, substituting the placeholder text with your information:
setspn –a HTTP/NETBIOSNAME DOMAIN\SERVICEACCOUNT
Our command and results looked like this:
Allow 15 minutes for these changes to propagate around to all DCs in the domain before testing reports again.
Remember to always test reports from a client workstation, and not from any server related to CRM, SQL, or SRS. Testing reports on a server may give you a false sense of accomplishment and self-worth; the real test is if they run from a client workstation.
If the new SPN makes things worse:
You can delete the SPNs if they cause problems (typical symptoms are that users are now prompted for their credentials when accessing the CRM. They will be prompted 3 times, and regardless of what credentials they use, they will receive a 401 Unauthorized error after the 3rd attempt).
The command to remove the SPN is similar to the ones use to add it, just with the –d switch instead of -a:
setspn –d HTTP/NETBIOSNAME DOMAIN\SERVICEACCOUNT
Hope this helps.
