Error viewing custom reports on Dynamics 365 9.1 on-premise

Hi @Henrik Lyneborg

like you’re hitting an SSRS authentication issue specific to custom reports in Dynamics 365 (Customer Engagement) 9.1 on-prem: the out-of-the-box reports work, while the custom report created in the report wizard fails. That pattern commonly points to a Kerberos/SSPI double-hop / SPN problem, where SSRS can’t authenticate successfully when the report is executed using the Dynamics FetchXML/report flow.

What to check (most likely cause: Kerberos/SSPI failure in SSRS logs)

When custom (FetchXML-based) Dynamics reports fail, the SSRS logs typically show Kerberos-related errors such as:

A call to SSPI failed

The target principal name is incorrect

Per the troubleshooting checklist in the relevant documentation, work through these items:

1. Verify SPN registration for the CRM AppPool account

Ensure the HTTP SPN is registered for the CRM AppPool account (the account the Dynamics IIS app pool runs under).

Confirm the SPNs are correctly registered for the target host/FQDN used.

2. Verify IIS configuration for UseAppPoolCredentials

On the CRM (IIS) side, confirm the IIS setting that controls credential usage is correct—specifically the UseAppPoolCredentials behavior.

3. Ensure Kerberos supports required encryption types for the AppPool account

In Active Directory:

Enable 128-bit AES and 256-bit AES encryption for the CRM AppPool account used by the app pool.

4. Verify SPN registration for the SSRS Report Server URL

Make sure SSRS has the right SPN for the Report Server URL host header/FQDN that Dynamics uses when calling SSRS.

Additional diagnostics to run (to confirm it’s the same root cause as TEST/DEV)

Because you mentioned the same solution works on TEST and Develop servers, you can compare differences between environments, but the key is to get the proof from logs/traces:

5. Turn on/collect CRM platform tracing during the failure

Run the failing custom report and collect CRM platform tracing to see where the request breaks.

6. Check SSRS logs at the exact failure time

Capture the specific SSRS log lines around the time the custom report is run (this is where SSPI/Kerberos errors show up).

7. Check Windows Event Viewer and (if available) network traces

Event Viewer + network traces can help validate that Kerberos authentication is failing (and why).

Thanks,

Lakshmi.