System Center Operations Manager SDK service failed to register an SPN

System Center Operations Manager SDK service failed to register an SPN



Have you seen this event in your RMS OpsMgr event logs?


Event Type:      Warning

Event Source:   OpsMgr SDK Service

Event Category:            None

Event ID:          26371

Date:                12/13/2007

Time:                2:58:24 PM

User:                N/A

Computer:         RMSCOMPUTER


The System Center Operations Manager SDK service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/rmscomputer and MSOMSdkSvc/ to the servicePrincipalName of DOMAIN\sdkaccount


This seems to appear in the RC1-SP1 build of OpsMgr.


Every time the SDK service starts, it tries to update the SPN’s on the AD account that the SDK service runs under.  It fails, because by default, a user cannot update its own SPNs.  Therefore we see this error logged.


If the SDK account is a domain admin – it does not fail – because a domain admin would have the necessary rights.  Obviously – we don’t want the SDK account being a domain admin…. That isn’t required nor is it a best practice.


Therefore – to resolve this error, we need to allow the SDK service account rights to update the SPN.  The easiest way, is to go to the user account object for the SDK account in AD – and grant SELF to have full control.


A better, more granular way – is to only grant SELF the right of modifying the SPN:


  • Run ADSIEdit as a domain admin.
  • Find the SDK domain account, right click, properties.
  • Select the Security tab, click Advanced.
  • Click Add.  Type “SELF” in the object box.  Click OK.
  • Select the Properties Tab.
  • Scroll down and check the “Allow” box for “Read servicePrincipalName” and “Write servicePrincipalName”
  • Click OK.  Click OK.  Click OK.
  • Restart your SDK service – if AD has replicated from where you made the change – all should be resolved.

To check SPN's:

The following command will show all the HealthService SPN's in the domain:

    Ldifde -f c:\ldifde.txt -t 3268 -d DC=DOMAIN,DC=COM -r "(serviceprincipalname=MSOMHSvc/*)" -l serviceprincipalname -p subtree

To view SPN's for a specific server: 

    "setspn -L servername"



Comments (15)

  1. Anonymous says:

    There’s a lot of confusion about SPN’s (service principal name) when it comes to OpsMgr.  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

Skip to main content