A best practice is to install CRM using service accounts. Most administrators will do the same for SQL Server. Many of the warnings about SPN’s during the install are igorned users. Many DBA’s will change the SQL service accounts after installation which will also cause issues.
CRM 2011 offers a new service called the Sandbox processing service. Failure to set the special SPN for this service while trying to run custom reports created with the report wizard will result in RS failure message.
Let’s make sure your CRM Server it setup in AD to allow delegation on the second tab.
Next, check the SPN for the CRM server so that it has HTTP using the following command:
setspn -L ( crm service account)
Look for http/servername and http/servername.FQDN you will need both.
To set them if missing:
setspn -A http/crmservername domainname\crmservice account
setspn -A http/crmservername.fqdn.com domainname\crmservice account
To view use the setspn -L with the service account name to see http has been set. (See screenshot below)
Now, on to the secret spn for the sandbox service..
setpsn -A MSCRMSandboxService domainname\crmsandbox service account
Once that has been completed on the CRM server, now head over to the SQL Server and check the service accounts for SQL. Let’s assume they are running under a SQL Service Account. IF the SQL service accounts were specified during the original install, the SPNs were created automatically. If not…
setspn -L domainname\sql service account to see the spns.
Again, you should see the 2 entries one with FQDN for MSSQLSvc. If not,
setspn -A MSSQLSvc/ domainname\sql service account
setspn – A MSSQLSvc/ servername.FQDN.com:1433 domainname\sql service account
to review, setspn -L domainname\sql service account should now show the correct SPN’s. You must have domain priviledges to set the SPN’s and if you have multiple AD machines it will take time to replicate the changes across.