System Center Operations Manager SDK service failed to register an SPN

<!--[if lt IE 9]>


Comments (15)
  1. Anonymous says:

    There’s a lot of confusion about SPN’s (service principal name) when it comes to OpsMgr.&#160; How are

  2. Kevin Holman says:

    Setting the SPN manually will not solve the event 26371.  The SDK account will still try and UPDATE the SPN on each start.  If you want to see the error go away – you must allow the SDK account the rights to update its own SPN.

  3. Anonymous says:

    After I upgrade to SCOM SP1, everytime I restart SDK service, I got the below alert: Alert: SDK SPN Not

  4. Anonymous says:

    Hi kevin,

    you have published this article a lot of time and today it was so helpfully for me. I had an issue with SCOM agent connection and SPN register. All SPN records was fine but on my customer network, there was another account with the same SPN records = big problem.

    I have detected this with your solution ldifde and solved my problem

    So I want to thank you so much for this article šŸ™‚

    have good day


  5. Kerry Gerhard says:

    I’m not domain admin: what to do?

    The suggested fix in the alert is not working for me.  Is this because I’m not domain admin?

    (from alert)

    ā€¢ Setspn.exe ā€“A MSOMSDK/<RMS FQDN> domainusername (this is the SDK service account name)

    ā€¢ Setspn.exe ā€“A MSOMSDK/<RMS NETBIOS> domainusername

    Note: If the RMS is clustered, you should use the virtual server name

  6. Hayden Trail says:

    I just had this issue with a customer and found that even though the account had access to update its own spn it was still producing the warning event.  The problem in this environment was that the service account did not have access to read the OU that it was in, once this was granted the warning was gone.  Hopefully this might help people.

  7. Tom Brady says:

    We receive the following AD Error on our DC: There are multiple accounts with name MSOMSdkSvc/RMS of type DS_SERVICE_PRINCIPAL_NAME.

    I have found the SPNs in our environment are for the RMS machine account:







    And for the SDKService account:



    So we have the same SPN set for the Service account and the machine account and it is throwing up an error indicating this.

    My question is it the best practice to set a Local System account for the health/sdk service on the RMS or a domain account.  If it is the BP for a domain account than I assume we should just ignore the AD error about duplicate SPNs?  I have seen many different views on whether account should be running the SDK/Health services and need a little clarification.

    Thank you for the great site!

  8. Trikke says:

    Can anyone provide an example on how the SPN’s should be registered for a clustered RMS?

    Do i need to register the nodes or the cluster or the application layer?

  9. sandhya says:

    i have a basic doubt as to where exactly i can sdk service in scom console?

  10. Karthick kesavan says:

    Kevin i don't have words to express your expertise man!!!! really you are rocking

  11. Syed Kashif says:


    I am not able to find ā€œRead servicePrincipalNameā€ and ā€œWrite servicePrincipalNameā€

    there is only read all permission and write all permission.

    any though on that

  12. Syed Kashif says:

    Found it kelvin thanks issue resolved.

  13. Daniel says:

    How can I overcome a scenario as described below.

    setup could not connect to the SDK to retrieve the necessary information to validate this account.

    My mssql server and management server are sitting on the same virtual machine in this case

  14. Birdal says:

    Hi Kevin,
    we see also Event ID 26371 on the first Management Server based on SCOM 2016.
    Unfortunately, your tip did not solve the problem. It is interesting that in the Security tab of SDK account, there is no “Read servicePrincipalNameā€ and ā€œWrite servicePrincipalNameā€ records although we did it.
    Best Reard

Comments are closed.

Skip to main content