Lately, I was playing with Systems Center Operations Manager (SCOM) 2007 R2 (OpsMgr). I have used MOC environment as a playground, which means that I’ve installed SCOM database on the SQL machine and SCOM RMS on the separate machine myself. Not a big deal to click through with “Next” through the setup.
Now, the things went completelly wrong. Even though initially the console seemed to be working, after some time it just stopped – froze, couldn’t reconnect. I checked the event log and it was full of messages “Cannot generate SSPI context” from various sources including System Center Data Access. What was interesting that restart of the service[s] often resolved problem for certain period of time, but then again – shit was hitting the fan. Of course, one can realize – it just can’t be that plain install could go that wrong, so I’ve started my little investigation.
The error message “Cannot generate SSPI context” immediatelly bings to KB811889. It is comprehensive article that … well, maybe because I was once a manager, I cannot read and then understand if the meaningful content is more than paragraph 
Anyway, I had to check all the things, because the issue was obviously related to Kerberos and Authentication.
I allowed the SQL service account (I’ve created one in AD) to automatically register SQL SPN (see the KB article on how to do that). After, I verified it, and indeed there was a registration of MSSQLSvc/SQL.OMLab.com:1433 SPN associated with the account. To verify that just lauch ADSI editor, find the account and see if there is a servicePrincipalName attribute on that account. After the SQL SPN registration was there, some of the errors were gone (e.g. Console would connect normally), however – not all of them.
When I tried to create Channel for the notifications – it just plainly refused to that with the same “SSPI context” issue. And that one was “stable”. Now two sentences in the KB got my special attention: “For example, the invalid SPNs that the client-side SQL Server driver can form as resolved fully qualified DNS are: MSSQLSvc/SQLSERVER1:1433, …”, “If the SSPI interface does not find the SPN, Kerberos authentication is not performed”.
Just to check if the “invalid” SPN could be the source of the problem, I went to ADSI Editor, opened properties for the SQL Service account and added MSSQLSvc/SQL:1433 SPN to the servicePrincipalName attribute, restart SQL Server. And indeed, after that I could create channel. Interestingly though, the “SSPI context” error messages with random stack traces were still appearing in the event log.
Why – is the question here. I turned back to the beginning: installation. I’ve checked install logs for the name of the SQL Server that I’ve provided. Well, I wrote simply “SQL” there. Not good for Kerberos though. Quick check on “HKLMSoftwareMicrosoftMicrosoft Operations Manager3.0Setup” for the DatabaseServerName value – it was “SQL”. This is again bad for Kerberos, so I’ve changed the value to SQL.OMLab.com (FQDN) and restarted the OpsMgr RMS server.
Verdict: “Cannot generate SSPI context” – gone. I like nice and blue event log and I didn’t had to use tools from sysinternals 