SCCM failes to login at SQL database

Posted by on Jan 31, 2011 in SC Configuration Manager, SQL Server | 2 comments

Sometimes it happened to me, that our Microsoft System Center Configuration Manager 2007 R2 (sccmsrv01) failed to login at our dedicated MS SQL 2005 2 nodes cluster (cluster: sqlclu, node 1: sqlclu01 and node 2: sqlclu02). Everything you could find in the sql logs was:

Error: 18456, Severity: 14, State: 11.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. [CLIENT: 192.168.1.10]

Since I knew that SCCM wouldn’t try to logon anonymously at the dedicated sql server but with its machine account the error seemed to be related on kerberos and service principal names (SPN).
I checked this with adsi editor – I don’t like the setspn utility, in adsi I can see and edit everything I need on my own – et voila, an entry was missing.
There are several sites at the moment explaining how to set spns and how to check if they were set correctly, e.g. http://technet.microsoft.com/en-us/library/bb735885.aspx
But I like to be sure that everything works correctly. So now I have set the following spns for the service account, my sql instances work with. To edit those entries, open adsi editor, navigate to the user account your sql service runs with and edit the servicePrincipalName as follows:

MSSQLSvc/sqlclu01
MSSQLSvc/sqlclu01:1433
MSSQLSvc/sqlclu01.domain.tld
MSSQLSvc/sqlclu01.domain.tld:1433
MSSQLSvc/sqlclu02
MSSQLSvc/sqlclu02:1433
MSSQLSvc/sqlclu02.domain.tld
MSSQLSvc/sqlclu02.domain.tld:1433
MSSQLSvc/sqlclu
MSSQLSvc/sqlclu:1433
MSSQLSvc/sqlclu.domain.tld
MSSQLSvc/sqlclu.domain.tld:1433

I know, I know. That’s a lot of stuff. But since you will not experience any disadvantages of having ‘one or two’ more entries in you spn, you can be sure that this will work!

2 Comments

  1. Hello!

    I am experiencing this issue.

    I have SPN entries only in my Virtual Name Server SQL CLuster.

    I added these entries to my 2 nodes cluster, but i have the same problem.

    Is necessary restart the sql service ?

  2. Simply move your SQL instance from one cluster node to the other and back. This should work then…

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha: * Time limit is exhausted. Please reload CAPTCHA.