0

I've got the errors during my lift of CRM 2013 to CRM 2015 saying that MSCRMSandboxService and MSCRMAsyncService were troublesome.

There was a problem setting the service principal name (SPN) for service MSCRMSandboxService with user account sandy@subby.domain.toppy. The reason was: Checking domain DC=subby,DC=domain,DC=toppy.

There's another blog on the subject and the person discussing it explains that they just clicked ignore during the installation. So did I. However, as opposed to him, I haven't run anything afterwards but, rather, just let it be for now.

My question is twosome.

  1. What can be done to ensure that such an error doesn't even appear during the installation?
  2. What are the issues that will/might occur in the future if not running SETSPN afterwards?

A portion of the stack trace is shown below.

Microsoft.Crm.Setup.Server.Core.ServicePrincipalNameManager .SetServicePrincipalName(String serviceClassName, String machineName,String serviceAccountName, Boolean isWebService) at Microsoft.Crm.Setup.Server.Core.SetServicePrincipalNameAction.Do(IDictionary parameters) at Microsoft.Crm.Setup.Shared.CrmAction.ExecuteAction(CrmAction action, IDictionary parameters, Boolean undo)

Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438

1 Answers1

0

to reply the point 2, most of the time you will not notice any weird behavior until you try to configure ssrs, IFD, or the outlook client. The spns are really a problem as soon as you configure something that is different from a plugin/workflow or js. In my opinion is better to waste 1 or 2 hours now instead of going crazy in the future. My main issues with missing spn were showing while configuring IFD. ADFS doesn't like at all when something is missing. More then sandbox and Async tho was the application pool and the deployment admin users that were creating trouble.

Mauro De Biasio
  • 1,146
  • 6
  • 16