If you’ve ever performed a distributed installation of Operations Manager then you’ve most likely spent some time stressing about duplicate, missing, or misconfigured SPN’s. But Blake, what’s an SPN? Wait, this isn’t TechNet! If you aren’t sure what an SPN is please check this out (Service Principle Names on TechNet).
Now that we’ve got that part out of the way, I’d like to fill you in on what my SPN experiences have been like recently. I’ll try not to get too deep, because SPN’s are full of fun and excitement and it just might be too much excitement for one day.
Recently Microsoft showed me a switch for the “setspn” command that I was – admittedly – ignorant of. SETSPN –X will query and list duplicate spn’s. I didn’t know that it was showing duplicates until I took the time to actually read the bottom line where it reads “X groups of duplicate SPN’s”
Don’t freak out if you run this in your environment and you see SPN’s for all of your MS’s listed as duplicates! (like I did!). I’ll explain why in a second. Just note that this simple command can mislead you into thinking that you’ve got duplicates, but it doesn’t take into account WHY you have duplicates.
Strategically, in a distributed OpsMgr environment, you should be using DOMAIN ACCOUNTS for your SDK/Config service. If so, this means that you must manually register the SPN’s for all of your MS’s if you want to ensure that there is an SPN “on standby” to handle the SDK service in the event that your RMSe goes down.
Think about that. If your management group is distributed and you’ve only got 1 SPN registered for the RMSe and it goes down, you would have to then go and register an SPN for the new RMSe (a secondary MS). Registering them prior to this happening is key, but keep that in mind just in case someone claims that you’ve got duplicate SPN’s registered. Make sense?
- RMSe – SPN registered and “in use”
- 2nd MS – SPN registered but not in use
- 3rd MS – SPN registered but not in use
- 4th MS – SPN registered but not in use
Those SPN’s that are registered but not in use could be misidentified by the SETSPN –X as duplicates. It’s because the SETSPN tool isn’t as smart as OpsMgr (see why below).
Sanity (relative sanity…)
So if you’ve ever been in an environment that actually has legitimate duplicate or misconfigured SPN’s, then you know that OpsMgr will alert about duplicate or misconfigured SPN’s. OpsMgr is smart enough to also not alert about the “duplicate” SPN’s for your “RMSe’s in waiting”. Too bad I didn’t realize that Friday when the wave of panic washed over me and I started removing “duplicate” SPN’s for my secondary MS’s! Good thing is, I can put them back in place without interfering with OpsMgr.
The moral of the story; setspn –x is a good way to try to identify potentially misconfigured or conflicting SPN’s, but it is what it is and must be used objectively and not 10 minutes before closing on a Friday.
SETSPN –X < OpsMgr!!!