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
The System Center Data Access service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/SCOM03 and MSOMSdkSvc/SCOM03.opsmgr.net to the servicePrincipalName of CN=SCOM03,CN=Computers,DC=opsmgr,DC=net
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.
HOWEVER – the above alert is in error, and is a bug. It is telling me that I need the SPN’s on the COMPUTER account of a management server, which is NOT correct. When I use a domain account for my SDK/DAS service – I need the SPN to be placed on the domain account that runs the service.
The issue remains for SCOM 2012, 2012 SP1, and 2012 R2.
To see your SPN’s… open a command prompt and verify your SPN for you domain SDK account:
C:\>setspn -L DOMAIN\sdkdomainuseraccount
The output should be something like:
Registered ServicePrincipalNames for CN=sdkdomainuseraccount,OU=Service Accounts,OU=Accounts,OU=US,DC=domain,DC=com:
You might not have ANY SPN’s here by default. That’s ok, they need to be added.
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. What we SHOULD NOT see here is any SPN’s for the MSOMSdkSvc on the management server computer accounts (if we are using a domain account for the SDK/DAS service)
C:\>setspn -L SCOM01
Registered ServicePrincipalNames for CN=SCOM01,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.
Now, how do we add the SPN’s in the right place? First you will a domain admin to do this, or be granted rights to be able to write the SPN’s to an object.
In my case, for a new environment, I don’t have any SPN’s set on my domain account which is running my DAS. Therefore I will see to set these. In Windows Server 2008R2 – the command is SETSPN –A. In WS2012, it changed to SETPSPN –S which checks for duplicates before it allows you to create them.
I have three management servers: SCOM01, SCOM02, and SCOM03. Therefore I will need to create/add 6 SPN’s:
setspn -S MSOMSdkSvc/SCOM01.opsmgr.net OPSMGR\omdas
setspn -S MSOMSdkSvc/SCOM01 OPSMGR\omdas
setspn -S MSOMSdkSvc/SCOM02.opsmgr.net OPSMGR\omdas
setspn -S MSOMSdkSvc/SCOM02 OPSMGR\omdas
setspn -S MSOMSdkSvc/SCOM03.opsmgr.net OPSMGR\omdas
setspn -S MSOMSdkSvc/SCOM03 OPSMGR\omdas
Now when I query my SPN for my domain account which runs my SDK/DAS service on all my management servers:
setspn -L OPSMGR\omdas
Registered ServicePrincipalNames for CN=omdas,OU=SCOM,OU=US,DC=opsmgr,DC=net:
and for each management server:
C:\Windows\system32>setspn -L SCOM01
Registered ServicePrincipalNames for CN=SCOM01,CN=Computers,DC=opsmgr,DC=net:
C:\Windows\system32>setspn -L SCOM02
Registered ServicePrincipalNames for CN=SCOM02,CN=Computers,DC=opsmgr,DC=net:
C:\Windows\system32>setspn -L SCOM03
Registered ServicePrincipalNames for CN=SCOM03,CN=Computers,DC=opsmgr,DC=net:
Now they are correct, and no duplicates exist. Again – the example above is for when you are suing a domain account for your SDK/DAS services on your management servers, which is typical.