SPN’s (Service Principal Names) settings are very similar in OpsMgr 2012 as they were in OpsMgr 2007. However, since the SDK (Data Access) service runs on ALL management servers now… the SPN’s for the SDK (DAS) account will be different now.
If you deploy OpsMgr using a standard domain user account for the SDK service, you might see alerts like the following:
Data Access Service SPN Not Registered
Alert Description: The System Center Operations Manager SDK service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/OMMS1 and MSOMSdkSvc/OMMS1.opsmgr.net to the servicePrincipalName of OPSMGR\omdas
This is caused by the fact that when the SDK service (System Center Data Access Service) starts up, it tried to ensure/update the SPN on the account that the SDK service is running under. By default in a domain, a standard user account does not have the right to update its own SPN. A domain admin should create the SPN in this case.
To see if it worked… open a command prompt and verify your SPN for you domain SDK account:
C:\>setspn –L DOMAIN\sdkdomainuseraccount
The output will be:
Registered ServicePrincipalNames for CN=sdkdomainuseraccount,OU=Service Accounts,OU=Accounts,OU=US,DC=domain,DC=com:
Notice how this has changed from OpsMgr 2007: The SDK domain account SPN now has SDK SPN’s for ALL management servers, instead of just the RMS.
The HealthService SPN’s have not changed for Management server computer accounts, and this is handled automatically and should not require any modification:
C:\>setspn -l omms1
Registered ServicePrincipalNames for CN=OMMS1,CN=Computers,DC=domain,DC=com:
*Note – In SCOM 2012 – you might notice that every time your management server service is restarted, or rebooted, that we log an event (and create an alert) that the SPN’s are incorrect. This event/alert is in error, it is complaining the the SDK SPN is missing from the management server COMPTUER account, which should ONLY be the case if you were using local system for the SDK service. Ignore this event and alert.