OpsMgr 2012: What should the SPN’s look like?


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

The output:

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.

Comments (36)

  1. Kevin Holman says:

    Hi Leau –

    You didn’t spot that because I just added it. I realized my article must not be complete enough because there remains confusion, so I added more context to clarify it. :-)

    You should remove SDK SPN’s from the computer accounts because they are wrong, and should be on the domain account running the DAS service. You should NOT ever have duplicate SPN’s, the AD people will get angry about that. As to if you need them? These are used for Kerberos authentication for the SDK. However, in most cases they aren’t necessary as console authentications will fall back to NTLM. They become more critical when you do things like place a web console server on a non-management server, or ever need to set up constrained delegation for multiple-hop Kerberos authentications…. such as when using windows auth to the web console when it isn’t running on a local management server.

  2. Faizan Dastoor says:

    Hi Kevin,

    Please correct me if I am mistaken the concept, do we still need to register SPNs for a SCOM environment which has 1 MS?

  3. Anonymous says:

    Yes – from what I can tell – the event/alert is a bug, and is incorrect.  The SPN's are the same as they were in OpsMgr 2007 – the SDK SPN for the DAS account should be attached to the domain user account, not the Computer account in the domain.  The only difference between OpsMgr 2007 and OM12 is that there will be multiple SDK SPN's on the domain user account that runs the SDK service, one for each management server since all run the SDK service.

  4. Anonymous says:

    Thanks Kevin!


  5. Kevin Holman says:

    @LeaUK –
    That is a the worst thing you could do. The alert in SCOM is a bug and wrong. When you use a domain account for the SDK/DAS account, the SPN’s should be written to the domain account and not the computer account. When you made the service account a domain admin, it now had rights to write the SPN, which it wrote to the computer account…. and should not have done so.

  6. EminM says:

    very very very good info, thanks Kevin

  7. Anonymous says:

    @Tom Slik –

    The article states what the SPN’s should be. The Computer accounts should only have healthservice SPN. The domainsdk account should have the SDK SPN, when you use a domain account for the SDK services. No exceptions, and no duplicate SPN’s are allowed.

  8. Anonymous says:

    You should DELETE it from the Computer object, and ADD it to the account that runs the DAS service. The only time the SPN should exist on the computer object, is if you are using Local System as your SDK/DAS account.

  9. Anonymous says:

    The alert is in error and should be disabled.

  10. Anonymous says:

    No – there is no service outage caused by writing a SPN. It is a simple attribute of an AD object.

  11. Jonathan says:

    Can you confirm this is correct for OM12?  We are still seeing the errors in the Operations Manager log and alerts generated in OM12 regarding SPN's.  Apparently the SDK wants us to add the SPN to each MS computer, rather than the SDK domain account…

  12. Matt Parrant says:

    We setup our SPN's correctly registering the MSOMSdkSvc/<mgmtSvr> SPN's to the SDK service account and removing from the Ops Manager Server computer accounts. However everytime we restart a managment server or just restart the SDK service a duplicate MSOMSdkSvc/mgmtSvr gets registered against the ops manager server account.

  13. DJ says:


    I have new setup of SCOM 2012

    sdk service is running under a user account

    when i go to ADSIEDIT and check spn's under the user account it does not show any spn registered for MSOMSDKSVC

    i see the spn registered for MSOMSDKSVC under the management server computer account

    i have not edited the spn's manually

    is this alright? i do not see any errors in event log whenever the services are restarted…kindly validate

  14. Anil says:

    I have a small confusion. Is SPN registration to done at SCOM management server or domain controller?

  15. Sadako says:

    Anil – SPN's are registered in AD, so i doesn't matter where you do it from, so long as the account you're using has Domain Admin privileges. The SPN for the MSOMHSvc entry should point to your management server. (e.g.  MSOMHSvc/ManagementServerName)

  16. Dan says:

    Surprised this was not fixed in 2012 R2…

  17. lance lyons says:

    does setspn -L work

    I cant see it as an option.  

  18. Jim Beam says:

    I dont understand why you couldn’t just put the correct spn commands that I need to add my domain account spns, That would have been much easier since anytime I use the domain account setspn -L (domainuseraccount) I get no spns. I will look elsewhere for this info.

  19. LeaUK says:

    setspm -L fails for our 2012 servers also. When I ran setspn -l SPN MSOMHSvc where missing. I simply elevated

    On boot SCOM console complained that the svc account/SPNs are not configured. To resolve I simply temporarily raised the svcDAS account up to Domain Admin, rebooted both MS machines, removed Domain Admin privileges and checked for the presence of MSOMHSvc using
    setspn -l both had been created correctly and no more errors in console at boot.

  20. LeaUK says:

    Hi Kevin, thanks for the reply. What are the consequences – do I need to remove these incorrect SPNs? Or can they be left without impact? I’m not sure why but I didn’t spot your advice from: ‘Now, how do we add the SPN’s in the right place?….’ and your following guidance :-(

    I assume I still need to follow this to configure the SPNs and link them to the domain account?

    I’ve also spotted why setspn -l kept failing for me, I copied/pasted the command from above and the format of the minus/dash (-) symbol must get changed. Typing the command in manually resolved!

    I appreciate your help and your Blog has been absolutely essential in assisting with our deployment. Thank you.

  21. LeaUK says:

    Hi Kevin

    To assist others perhaps the line: ‘HOWEVER – the above alert is in error, and is a bug.’ could stand out somehow so others do not gloss over it in the same way I did :-)

    Thanks for adding this recent additional info with step by step guidance on setting SPNs, this is brilliant – I wondered how I ‘missed’ this…

    As I now can’t create the correct SPNs (duplicate warnings are presented) I suspect one last helpful post would be a guide in removing the offending SPNs – as no matter what combination of Setspn.exe -D I use it fails :-( I shall post back when I discover the correct syntax.

    Edit – found it: (using your POC example domain)

    setspn.exe -d MSOMSdkSvc/SCOM01 opsmngrSCOM01
    setspn.exe -d MSOMSdkSvc/SCOM01.opsmngr.net opsmngrSCOM01

    Thanks again

  22. Mike H says:

    A customer has 3 management servers, SCOM01 SCOM02 and SCOM03. You create the 6 SPN’s for the 3 servers. You then run SETSPN -X and it comes back with duplicate SPN’s for the MOMDAS account. This would show up on an AD Audit. Is this expected behavior?

  23. Anonymous says:

    Pingback from SCOM 2012: error "Data Access Service SPN Not Registered" | Fair Technologies

  24. Lee says:

    Hi Kevin,

    I am troubleshooting a gateway server connectivity problem, the gateway server shows as not monitored under the management servers, when the monitoring service is restarted on the gateway server event ids 20057 21001 and 20071 are showing in the operations
    manager event log. I ran through these steps to verify the the single managment server and everything checked out ok, the gateway server is in a seperate non-trusted domain what should I see for the spn configuration on the gateway server?

  25. JohnH says:

    Hi Kevin

    I have SCOM 2102 r2 and did not get this error with UR3. Since upgrading to UR4 I am now seeing this "bug"

    Please can you if this bug still exist?



  26. SCOM-Guy says:

    When changing these SPN’s is there a service outage associated when writing them to the domain account? We have an environment where they were written to the computer account and now want to follow this procedure to write them to the domain account.


  27. ChallangeLogic says:

    Hi All

    I don’t get it. When I run: setspn -L RITSCMEOMDAS

    The output is:-

    Registered ServicePrincipalNames for CN=OMDAS,OU=Service Accounts,OU=CME,DC=RITSCME,DC=local:

    So when I run: setspn -S MSOMSdkSvc/RITSCME-SCOM-01 RITSCMEOMDAS

    The output is:-

    Checking domain DC=RITSCME,DC=local

    Duplicate SPN found, aborting operation!

    So the SPN is set on my SCOM Computer AD Object name – but not on my Domain Data Access (OMDAS) account. Is this correct or should the SPN be on BOTH the computer AND account objects?

  28. Tom Slik says:

    Can and should an override be placed computer SPN accounts, it is my understanding that once this is done, no issues with SPN will be alerted. However once the user account has permission for SPN registration it should be an issue.

  29. Tom Sink says:

    Yes, SPN permissions are set for the scomsvc service account, that is fine. The issue is the alerts are being triggered as you explained due to the computer account not having SPN rights. The question is – Do we override the alert? Thanks

  30. rob1974 says:

    A bit related to this. Why would you not use local system for SDK/Config? I can’t seem to find why i need to run the SDK with another user then local system. I think i remember it’s best practice to do when SQL isn’t installed on the same server as the
    management server (which is basically always). But the official documentation clearly state it can be a domain account or local system and don’t make any distinction in how the mg setup is.
    https://technet.microsoft.com/en-us/library/hh212808.aspx. You mention in the quickstart guide to use a domain account as well. Could you clarify this a bit more?

  31. Banji says:

    thank you.it worked for me.I have two SCOM servers so I Added four SPN’ and walaaa the management console loaded succesfully.

  32. LTHPETER says:

    Hi Kevin!

    We have things set up as you describe and have no known issues, but we have been getting warning 6037 from LSA in System Event log for years, which I think is related to this configuration but I don´t know if it´s a problem or how to fix it. The warning shows
    up on a regular basis in every management server and I can´t see an exact time pattern but there is usually between 70 – 150 minutes between them.

    They read:

    " The program Microsoft.Mom.Sdk.ServiceHost.exe, with the assigned process ID 1816, could not authenticate locally by using the target name MSOMSdkSvc/MGMTSRV1.. The target name used is not valid. A target name should refer to one of the local computer names,
    for example, the DNS host name.

    Try a different target name. "

    Where "MGMTSRV1" is the server were the event is logged, so on MGMTSRV2 the same warnings are logged but with that servers name in the description instead.
    Seems to me that something needs this SPN that we should not have?


  33. Avijit Bhardwaj says:

    Hi Kevin,
    Could you please suggest a solution for below issue. I am not able to connect to MS while installing reporter server. Though I have configured SPN for data access account as per your blog.

    Thanks in advance

  34. Kailasnath says:

    Hi Kevin

    Please advise how to deal with duplicate SPNs. (SCOM 2012 R2 on Windows 2012 R2, single management server and single management group).

    1. Kevin Holman says:

      If you have supplicate SPN’s – simply delete the wrong ones.

  35. On my system I noticed that the management server has the form MOMSdkSvc/SVPW-SC-OMMS1 and the account has the form MSOMSdkSvc/SVPW-SC-OMMS1, not the additional ‘S’ in the account SPN. Whats up with that? Everything has been working normally this way for years.