SCOM R2 Alert: ‘SQL Server cannot authenticate using Kerberos because the Service Principal Name (SPN) is missing, misplaced, or duplicated.’

---

08-01-2012 Update:
Jonathan Almquist has posted an excellent posting about the technical details of this faulty monitor. To be found here. 

07-04-2012 Update:
Even though the resolution mentioned in this posting (first posted on the 3rd of April 2012) worked for my test environment, it turns out this Alert is a bug as well. Tabish Ansari already pointed it to me, but back then I didn’t share his opinion about this Alert, being a bug.

Case is this Monitor ‘Service Principal Name Configuration Status’ is targeted against SQL Server 2012 DB Engines. However, this Monitor runs against SQL 2008 DB Engine class as well. On the TechNet Forums this issue is explained by SME-45: ‘…it looks for the right SPNs but is unable to detect that a SQL-Server which runs as NT AUTHORITY\NETWORKSERVICE is the right one for SPN FQDN.So it sees 2 different names and complains. When SQL runs as Domain Account this logic runs perfect but for Local System and Networkservice the Script just makes no sense…’

Therefore it’s best to disable this Monitor for now since this Monitor raises false-positives.

Thanks to Tabish Ansari and the TechNet Forums.

---

Bumped into this issue in my test environment which I am building for the new series of blog postings about migrating from SCOM R2 CU#5 to OM12. The SQL server threw this Warning Alert in the SCOM R2 Console: ‘SQL Server cannot authenticate using Kerberos because the Service Principal Name (SPN) is missing, misplaced, or duplicated.’:

Resolution
So the SPN for the SQL server was missing. Time for some action! However, the command as stated in the same Alert under the tab Product Knowledge wasn’t going to work:

In my days being a system engineer I have fought a battle or two with SPNs and those syntaxes were a bit longer. Time to search for the correct syntax.

Soon I found it on this website, all about configuring SPNs for SQL Server Site Database Servers:

In my case it translated to:
setspn -A MSSQLSvc/SCOM-DB01.scom2om12.local:1433 scom2om12\scomsql

I ran this line from an elevated cmd-prompt on the SQL server with an account with domain admin permissions. I ran for a minute and then I got the message all was fine. And indeed, the Alert doesn’t come back anymore.

Case closed.