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 netbios name>:1433
servicePrincipalName: MSSQLSvc/<database fqdn>:1433

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.

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.

In this example, we’ll create a dashboard that show health of all critical disks for Application X.

Create group

Create dashboard by adding SLO’s

Scope to group

Create SLO’s

Disk Space SLO

Disk Queue Length SLO

Disk Seconds Per Transfer SLO

Results

1. Ensure the destination volume is formatting to 64k allocation unit size for best performance.
To partition a drive: http://technet.microsoft.com/en-us/library/cc722475.aspx

2. If the Health Service State directory will not be located at the root of the new volume, create the destination folder that will host it.
Note: The Health Service State folder will be automatically created when the services are restarted, so it is not necessary to create this folder.

3. Stop all SCOM services (Health Service, Config Service and SDK Service).

4. Open REGEDIT and navigate to HKLM\System\CurrentControlSet\Services\HealthService\Parameters

5. Modify the State Directory string value with the path to the new location of the Health Service State directory.
Example: H:\Health Service State

6. Close the Registry Editor.

7. Start all SCOM services (Health Service, Config Service and SDK Service).

8. Open the new location that hosts the Health Service State folder and verify the contents have been created successfully.

9. Open the Operations Manager event log to verify there are no errors from source; Health Service, Health Service Modules, Health Service ESE Store.

· In my case, I had a clean install of Windows 2008 Enterprise. I installed the prereq’s, including POSH, and ran the installation wizard to install a new management server role. You’ll need:

o MSAA and SDK credentials

o SDK account is local administrator

o Current user is local administrator, member of SCOM Admins, and has SA on databases

· On the new MS, copy the ManagementServerConfigTool.exe tool from the SupportTools folder of the installation media to the SCOM program files directory.

· Backup the operational database.

· Note: it is not necessary to stop the SCOM services on the original RMS. This is all handled by the promotion process. Online doc states we need to stop the services if RMS is clustered, but I do not have a clustered RMS in my test environment.

· Open an administrative command prompt and navigate to the SCOM program files directory and run the secure storage backup executable to restore the encryption key:
SecureStorageBackup.exe Restore EncryptionKeyFile

· While still in the administrative command prompt, run the following command to promote to RMS role:
ManagementServerConfigTool.exe PromoteRMS
Note: there are additional options to add to the command if you plan to decommission the original RMS (/DeleteExistingRMS)

· If you plan to decommission or repurpose the original RMS hardware, skip this step. If you plan to use the original RMS as a MS, then start an administrative command prompt on the original RMS and run the following:
ManagementServerConfigTool.exe UpdateDemotedRMS
Note: this step was not required during my exercise.
Then delete the Health Service State directory and restart the Health Service. Ensure the SDK and Config services are configured as disabled.

· Logon to the Report Server role and navigate to the “…Reporting Services\ReportServer” directory, and open the rsreportserver.config file in notepad. Locate the two instances of <ServerName>ServerName</ServerName>, and update these to the new RMS computer name.

· While still logged onto the Report Server role, open registry editor and locate the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Operations Manager\3.0\Reporting
Update the DefaultSDKServiceMachine value to the name of the new RMS.

Steps that were outlined in the online documentation (http://technet.microsoft.com/en-us/library/cc540401.aspx) that I did not need to do.

· Set the broker service to 1 after the promotion, but I didn’t have to do anything here because the broker service was still enabled.

· Update the web console server Web.Config file. I didn’t have one to update in my lab, so no output to share on that step.

· Currently, the online documentation states to update the data warehouse security (user mapping) for the SDK account. This is incorrect and will be updated probably by the time you read this. It should be prefixed with a clause that we need to update the SDK user mappings only if you are running the SDK service under the context of Local System (which is an uncommon configuration). Additioinally, it’s the OperationsManager database that needs to be updated, not the OperationsManagerDW database.

· Run UpdateDemotedRMS on the original RMS.

Connecting to console

Agent connections

I happened to have all my agents configured to report to the RMS prior to the promotion process just to see how the failover process would be handled. Looks like all agent automatically failed over to the promoted RMS with no problems.

Alerts during the move

After the move I took a look at any alerts that were raised during the move. There were two alerts raised and closed. But no other alerts raised during the move. I suspect the HS HB failure from the MS was a side-effect of it losing the parent HS relationship with the MG. This was resolved, though, after running the ManagementServerConfigTool on the secondary MS.

Management Server health

Everything looks great, with one exception. According to the online documentation, I am led to believe that the original RMS should no longer be in service, but it is apparently still serving as a MS role (MG1-RMS).

Just for fun, I decided to run the ManagementServerConfigTool UpdateDemotedRMS command on the original RMS, and the output states that this is already marked as a secondary management server.

So it seems that if you want to repurpose or decommission the original RMS, you may need to uninstall the SCOM MS role before wiping the machine, otherwise it will not be removed as a parent health service.

I went ahead and uninstalled the SCOM program files from the original RMS and turned off the computer. Now it shows as a grey MS.

I deleted the original RMS from the administration space, and it’s gone.

After performing these steps to manually remove the old RMS, I took another look at the command line options for promoting to a RMS and noticed there is a /DeleteExistingRMS:<true|false> switch. When running PromoteRMS this option defaults to false. If I would have explicitly specified true for this option, the promotion process would have also removed the original RMS.

After removing the original RMS, I received two alerts. One for HS HB failure, which I’d expect. But another referring to AD Integration problems.

What this means is I need to add the new RMS computer account to the Operations Manager container in AD in order for the AD Int rules to work again.

If we take a look at the effective permissions on the Operations Manager container for the original RMS, we see it has List contents, Read all properties, Delete subtree and Read permissions.

On this object and all descendant objects.

I deleted the original RMS computer account and added the new RMS computer account, mirroring these permissions on the Operations Manager container.

Note: this is only on the MG container within the Operations Manager container that corresponds to the MG where you’ve performed the RMS promotion. If you have multiple MG’s using AD Int, do not update those containers.

After restarting the Health Service on the RMS, the AD Integration rule succeeded. I verified this by deleting all AD Integration rules for one of the MS’s, and these objects were removed from the Operations Manager container within a couple minutes.

SPN cleanup

I had manually added the SPN’s for the SDK account in my lab, so I needed to make sure the SPN’s that reference the original RMS were removed. I opened ADSIEdit.msc on a DC, navigated to the SDK account and removed the highlighted SPN’s.

I think that about does it. The RMS role has been moved, the original RMS has been decommissioned, additional cleanup tasks were completed and the MG is functioning. Somewhat of a rough ride, but this was a good exercise.

If SCOM is a mission critical application at your company, I suggest going through this exercise on a regular basis. I remember in previous systems engineer roles having to go through these types of DR procedures about once every year. It always sidetracked whatever project I was working on, but every year we improved recovery time.