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:
MSOMSdkSvc/SCOM01
MSOMSdkSvc/SCOM01.opsmgr.net
MSOMSdkSvc/SCOM02
MSOMSdkSvc/SCOM02.opsmgr.net
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
The output:
Registered ServicePrincipalNames for CN=SCOM01,CN=Computers,DC=domain,DC=com:
MSOMHSvc/SCOM01
MSOMHSvc/SCOM01.opsmgr.net
WSMAN/SCOM01.opsmgr.net
WSMAN/SCOM01
TERMSRV/SCOM01
TERMSRV/SCOM01.opsmgr.net
RestrictedKrbHost/SCOM01
HOST/SCOM01
RestrictedKrbHost/SCOM01.opsmgr.net
HOST/SCOM01.opsmgr.net
*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:
MSOMSdkSvc/SCOM03
MSOMSdkSvc/SCOM03.opsmgr.net
MSOMSdkSvc/SCOM02
MSOMSdkSvc/SCOM02.opsmgr.net
MSOMSdkSvc/SCOM01
MSOMSdkSvc/SCOM01.opsmgr.net
and for each management server:
C:\Windows\system32>setspn -L SCOM01
Registered ServicePrincipalNames for CN=SCOM01,CN=Computers,DC=opsmgr,DC=net:
AdtServer/SCOM01
AdtServer/SCOM01.opsmgr.net
MSOMHSvc/SCOM01.opsmgr.net
MSOMHSvc/SCOM01
WSMAN/SCOM01.opsmgr.net
WSMAN/SCOM01
TERMSRV/SCOM01.opsmgr.net
TERMSRV/SCOM01
RestrictedKrbHost/SCOM01
HOST/SCOM01
RestrictedKrbHost/SCOM01.opsmgr.net
HOST/SCOM01.opsmgr.netC:\Windows\system32>setspn -L SCOM02
Registered ServicePrincipalNames for CN=SCOM02,CN=Computers,DC=opsmgr,DC=net:
WSMAN/SCOM02
WSMAN/SCOM02.opsmgr.net
MSOMHSvc/SCOM02.opsmgr.net
MSOMHSvc/SCOM02
TERMSRV/SCOM02.opsmgr.net
TERMSRV/SCOM02
RestrictedKrbHost/SCOM02
HOST/SCOM02
RestrictedKrbHost/SCOM02.opsmgr.net
HOST/SCOM02.opsmgr.netC:\Windows\system32>setspn -L SCOM03
Registered ServicePrincipalNames for CN=SCOM03,CN=Computers,DC=opsmgr,DC=net:
WSMAN/SCOM03.opsmgr.net
WSMAN/SCOM03
MSOMHSvc/SCOM03
MSOMHSvc/SCOM03.opsmgr.net
TERMSRV/SCOM03
TERMSRV/SCOM03.opsmgr.net
RestrictedKrbHost/SCOM03
HOST/SCOM03
RestrictedKrbHost/SCOM03.opsmgr.net
HOST/SCOM03.opsmgr.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.
The following “User Voice” has been raised on this issue. Please vote it up!
https://systemcenterom.uservoice.com/forums/293064-general-operations-manager-feedback/suggestions/37450222-invalid-data-access-service-spn-not-registered-e
Pingback:SCORCH: SCOM IP – “Failed to connect. Please verify your connection settings.” – Wendi Cai's Blog
if we have something like following
MSOMSdkSvc/SCOM01:5723
MSOMSdkSvc/SCOM01.opsmgr.net:5723
is it valid?
No, it is invalid. The SDK SPN’s should not have a port assigned, and the SDK service does not even use port 5723, it uses tcp 5724. No matter WHAT port it is using – we do not specify ports for the SDK SPN. That looks like someone tried to copy the way SQL SPN’s work with customized ports.
https://docs.microsoft.com/en-us/system-center/scom/plan-security-config-firewall?view=sc-om-2019
hello hope you can help, I have scom 2016 installed on server 2016 and I am running sql 2016, I also installed scom web server on win sver 2016 the scom mgmnt svr and the scom web servr are on the same domain. the web page for scom keeps giving error “This page isn’t working, https://fqdn.domain.com is currently unable to handle this request. HTTP ERROR 500″
this thread said it might be related to SPN (service principal name) not sure where that is located? or what to adjust, keep in mind I can flip things back when I rule it out.
here is that thread
https://social.technet.microsoft.com/Forums/systemcenter/en-US/91a51123-ddf1-4de6-a514-0e3267180b82/scom-2016-web-console-error-500-no-fixesworkarounds-are-working-for-me-help?forum=operationsmanagerdeployment
another thread folks flipped around the app pool on iis, I tried that although I did not think that was it, seeing that it works on some machines plus it is also setup with virtual directories.
here is that thread
https://social.technet.microsoft.com/Forums/systemcenter/en-US/91a51123-ddf1-4de6-a514-0e3267180b82/scom-2016-web-console-error-500-no-fixesworkarounds-are-working-for-me-help?forum=operationsmanagerdeployment
this thread is thinking its credentials. I bumped up the permish in the security group for users as well as my account. same thing.
https://social.technet.microsoft.com/Forums/systemcenter/en-US/705c75e9-f4b8-49b8-a3c8-efe0a43ec2d2/fresh-install-scom-2016-web-console-error-500?forum=operationsmanagergeneral
please help
Worthy of note here is also that from what we are seeing, SCOM tries to register the SPN for the machine account whenever the server is rebooted (or possibly when the SDK or Config service is restarted, which use the same account). It shouldn’t be trying to create them, and if so, it should use the service account. This may actually be the source of the alert.This still exists in SCOM 2019.
Yep – I have reported this to the product group every year for about 10 years. 🙂
One little question: do I need to add the SPNs for GW Servers as well? I’m don’t understand the mechanism in which the SPNs are used.
I’m still rather new to System Center and appreciate tips like this.
Thanks and regards,
Simon
No – this discussion is around SDK SPN’s – which only apply to management servers.
Hi Kevin,
How do we set SPN if the agents are multi-homed. Am getting 20057 events Failed to initialize security context for target MSOMHSvc/manamegent server name The error returned is 0x80090311(No authority could be contacted for authentication.). This error can apply to either the Kerberos or the SChannel package. Followed by 21016 events.
SPN is already set for SDK and management server of the parent domain and its communicating. We are getting this error in the child domain. Since we have trust between both domains, we are not using any certificates. There are many other servers which are configured in the same way and they are reporting healthy to both the SCOM environments. We have issue only with few servers
There is nothing to set. You either have reliable kerberos communications, or you do.
When you say “parent and child” are these in the same Forest, or different Forests? If in the same forest, Kerberos should work natively. Period.
If in different forests, then there is an issue with your Kerberos reliability across the trust, at least for some of the agents.
Hi Kevin,
2 questions about SPNs.
1. You said the issue remains for SCOM 2012, 2012 SP1, and 2012 R2. Does it remain also for SCOM 2016?
2. Is it possible to use MSA (gMSA are supported from SCOM 2019) account instead of using “normal” domain account for SDK for SCOM 2016 and then not creating SPNs?
Thanks
Witold
1. Yes – SCOM 2016 throws an invalid error about the SPN’s. This was first fixed in an update rollup for SCOM 2019.
2. MSA’s are not supported.
Hi Kevin,
With regards to gMSAs, I’m not quite sure what you mean by “MSAs are not supported”. Considering they’re supported as of 2019 UR1 is there anything that needs to be done with SPNs when moving to gMSAs? I’ve read the support docs:
https://docs.microsoft.com/en-us/system-center/scom/support-group-managed-service-accounts?view=sc-om-2019
and can’t seem to find a reference to SPNs there.
Or should we not move to gMSAs?
Thanks
G
MSA is not gMSA. MSA’s are not supported in SCOM. gMSA’s are a more recent specialization of a MSA that is specifically supported in SCOM 2019 UR1 and later.
Check out this doc for SPN’s and gMSA’s. https://monitoringguys.com/2020/12/14/implementing-gmsa-in-scom-2019-ur1/
Thanks Kevin. As always, super helpful and very responsive. Really appreciated.
hi kevin
i’m trying to register the SPN to the AD-service-account. but if i do so, i’ll get the output “duplicate SPN found, aborting operation”.
if i check setspn -L “myscomserver”, there are the following two entries:
– MSOMSdkSvc/”myscomserver.domain” (in my opinion, these is a bad entry?!)
– MSOMSdkSvc/”myscomserver” (in my opinion, these is a bad entry?!)
the spn-check for the domain account shows no entries.
and if i check “setspn -x”, there are NO duplicate SPNs show :-/
how can i get rid of these two machine-account entries? setspn -D with the two entries didnt not work.
Have a domain admin delete the bad SPN’s. Set the correct SPN’s on the domain account that runs the SDK/DAS.
Hi Kevin, Will Kerberos authentication work with SCOM in my scenario? I have a Gateway server in domain1 communicating with the Management server in domain0 (using certs because there is no trust relationship). There are agents running on a 3rd domain, domain2. The agent is set to use the Gateway server, there is a bi-directional forest trust between domain1 and domain2. I’m using certificates currently, but would like to switch to using Kerberos. Is this possible? What should the SPNs look like in this case? Thanks.
Hi Kevin,
Is the bug mentioned in your articled fixed SCOM2019 ? We are using domain accounts for the services, created the SPN entries but still getting “Data Access Service SPN Not Registered” during the service startup. I want to confirm if my SPNs are correct as when I try to connect some agents behind firewall in a different domain, they are reporting
”
The OpsMgr Connector could not connect to MSOMHSvc/xxx.domain.com because mutual authentication failed.
Verify the SPN is properly registered on the server and that, if the server is in a separate domain, there is a full-trust relationship between the two domains.
“.
We have full trust between the 2 domains.
Thank you.