Share via

Operations Manager 2007 SPN's

  • Article

There's a lot of confusion about SPN's (service principal name) when it comes to OpsMgr.  How are SPN's registered?  When are SPN's registered?  Why aren't SPN's registering?

The purpose of this post is to give a snapshot of all the SPN's that should be in your environment so you know you've get them all right.  Here's a birds-eye view.

Attention: Please read the last couple paragraphs in this post and my other post about SDK SPN Not Registered to gain a full understanding of the SDK SPN.

Just to clarify the list of SPN’s below:

* The SDK SPN is registered on the SDK service account in Active Directory.  It references the RMS.
* The Health Service SPN is registered on the management server computer objects in Active Directory.  It references its own computer object.

Note: SDK SPN’s do not have any operational impact on SCOM. The only SPN that operationally effects SCOM is the MSOMHSvc. In a clustered RMS configuration, the MSOMHSvc SPN needs to be set on the RMS Virtual Cluster object in Active Directory ONLY (and the MS computer objects, of course).

Root Management Server (non-clustered)

servicePrincipalName: MSOMSdkSvc/<RMS fqdn>
servicePrincipalName: MSOMSdkSvc/<RMS netbios name>
servicePrincipalName: MSOMHSvc/<RMS fqdn>
servicePrincipalName: MSOMHSvc/<RMS netbios name>

Root Management Server (clustered)

servicePrincipalName: MSOMSdkSvc/<RMS virtual fqdn>
servicePrincipalName: MSOMSdkSvc/<RMS virtual netbios name>
servicePrincipalName: MSOMHSvc/<RMS virtual fqdn>
servicePrincipalName: MSOMHSvc/<RMS virtual netbios name>

*Read additional information at bottom of article about clustered RMS SDK SPN

Management Server(s)

servicePrincipalName: MSOMHSvc/<MS fqdn>
servicePrincipalName: MSOMHSvc/<MS netbios name>

Management Server with ACS

servicePrincipalName: AdtServer/<MS fqdn>
servicePrincipalName: AdtServer/<MS netbios name>
servicePrincipalName: MSOMHSvc/<MS fqdn>
servicePrincipalName: MSOMHSvc/<MS netbios name>

Database Servers (including ACS DB)

servicePrincipalName: MSSQLSvc/<database fqdn>:1433
servicePrincipalName: MSSQLSvc/<database fqdn>

 

Registering SPN's with SETSPN

Non-Clustered RMS (SDK only)

SETSPN –A MSOMSdkSvc/<RMS netbios name> <your domain>\<sdk domain account>
SETSPN –A MSOMSdkSvc/<RMS fqdn> <your domain>\<sdk domain account>

Clustered RMS (SDK and Health Service)

SETSPN –A MSOMSdkSvc/<RMS virtual netbios name> <your domain>\<sdk domain account>
SETSPN –A MSOMSdkSvc/<RMS virtual fqdn> <your domain>\<sdk domain account>

SETSPN –A MSOMHSvc/<RMS virtual netbios name> <RMS virtual netbios name>
SETSPN –A MSOMHSvc/<RMS virtual fqdn> <RMS virtual netbios name>

Verifying SPN's with SETSPN

SDK:   SETSPN -L <your domain>\<sdk domain account>

HealthService: SETSPN -L <servername>  (run this for each MS)

SQL Service:   SETSPN -L <your domain>\<sql service account>

Verify SPN's with LDIFDE

SDK and HealthServices:   Ldifde -f c:\ldifde.txt -t 3268 -d DC=domain,DC=COM -r "(serviceprincipalname=MSOM*)" -l serviceprincipalname -p subtree

SQL Service:   Ldifde -f c:\ldifde.txt -t 3268 -d DC=domain,DC=COM -r "(serviceprincipalname=MSSQLSvc*)" -l serviceprincipalname -p subtree

Note:  You'll most likely find multiple SPN's for SQL Service.  Just be sure there's one for each of your OpsMgr DB role servers.  If SQL runs under Local System, it will automatically register its SPN's each time the service starts.

 

Question A little more interesting information about clustered RMS SDK SPN

The SDK SPN is relative to the active node.  Because of this, it is best to register the SDK SPN to the cluster network name, since this will always be associated to the active node.  Because the SPN is relative to the active node, if we do register only the physical node SPN’s and not the cluster network name, we would need to connect to the active physical node in the console.  Obviously, this is not very conducive and can be guess work.

With that said, we really don't even need both Netbios and FQDN registered for the SPN.  We could live with one or the other.  What happens is, when we launch the console and enter the RMS name, this is the name that is used to establish the session with the SDK service.  If we always supply only a Netbios name, we don't even need the FQDN registered SPN (and vise-versa).  But, again, it makes sense to create both netbios and FQDN SPN’s, especially in multi-domain environments.

Here’s another neat fact that you may not be aware of.  We could create an alias in DNS, pointing it to the RMS clustered network name and both physical nodes.  We can then register that alias as the SDK SPN and use that in our console connection settings.  Now it doesn’t matter if we use the cluster network name, either of the physical nodes, or either netbios or FQDN.

Comments

  • Anonymous
    January 01, 2003
    Today I needed to check the SPN’s for my OM2012 environment and (again) I used some other blogs to confirm

  • Anonymous
    January 01, 2003
    PingBack from http://ianblythmanagement.wordpress.com/2008/08/13/set-spn-warning/

  • Anonymous
    January 01, 2003
    Today I needed to check the SPN’s for my OM2012 environment and (again) I used some other blogs to confirm

  • Anonymous
    January 01, 2003
    Attention: Please also read my other post about Operations Manager 2007 SPN’s to gain a full understanding

  • Anonymous
    January 01, 2003
    Curtiss - SPN is now registered to all MS's. Kevin posted an update on this here: blogs.technet.com/.../opsmgr-2012-what-should-the-spn-s-look-like.aspx

  • Anonymous
    October 18, 2012
    Hi, Great article! But aren't SPNs for SQL Server Reporting Services missing here? for HTTP servicePrincipalName: http/<RS fqdn> servicePrincipalName: http/<RS netbios name> for SSL (HTTPS) servicePrincipalName: https/<RS fqdn> servicePrincipalName: https/<RS netbios name> to set them: setspn –A http/<RS fqdn>/SSRSServiceAccountName setspn –A http/<RS netbios name>/SSRSServiceAccountName and for HTTPS: setspn –A https/<RS fqdn>/SSRSServiceAccountName setspn –A https/<RS netbios name>/SSRSServiceAccountName

  • Anonymous
    February 11, 2013
    any update on this for scom 2012? there is no RMS anymore so how do i register the spn for the sdk account. these two aren't working for me: SETSPN –A MSOMSdkSvc/<RMS netbios name> <your domain><sdk domain account> SETSPN –A MSOMSdkSvc/<RMS fqdn> <your domain><sdk domain account>