Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

System Center Operations Manager SDK service failed to register an SPN

System Center Operations Manager SDK service failed to register an SPN

  • Comments 13
  • Likes

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

Description:

The System Center Operations Manager SDK service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/rmscomputer and MSOMSdkSvc/rmscomputer.domain.com 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
  • After I upgrade to SCOM SP1, everytime I restart SDK service, I got the below alert: Alert: SDK SPN Not

  • 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> domain\username (this is the SDK service account name)

    • Setspn.exe –A MSOMSDK/<RMS NETBIOS> domain\username

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

  • 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.

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

  • 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.

  • 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:

    MSOMSdkSvc/rms.domain.com

    MSOMSdkSvc/rms

    MSOMHSvc/rms.domain.com

    MSOMHSvc/rms

    HOST/rms.domain.com

    HOST/rms

    And for the SDKService account:

    MSOMSdkSvc/rms.domain.com

    MSOMSdkSvc/rms

    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!

  • 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?

  • hope this will help you Trikke

    blogs.technet.com/.../opsmgr-2007-rms-cluster-node-registers-the-health-service-spn-with-the-physical-node-s-computer-account.aspx

  • 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

    raynald

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

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

  • Kelvin

    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

  • Found it kelvin thanks issue resolved.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs