April 20, 2010 at 12:16 pm
I'm seeing this event in my domain system event logs:
EventID : 11
There are multiple accounts with name MSSQLSvc/server1.domain.com:1433 of type DS_SERVICE_PRINCIPAL_NAME.
EventID : 11
There are multiple accounts with name MSSQLSvc/server2.domain.com:1433 of type DS_SERVICE_PRINCIPAL_NAME.
EventID : 11
There are multiple accounts with name MSSQLSvc/server3.domain.com:1433 of type DS_SERVICE_PRINCIPAL_NAME.
I've tracked down the duplicates but I'm not sure how to resolve the issue.
We use a domain account to run the SQL services on three different machines. The domain service account has SPNs for each of the SQL boxes like so:
MSSQLSvc/server1.domain.com:1433
MSSQLSvc/server2.domain.com:1433
MSSQLSvc/server3.domain.com:1433
Do I:
a] do nothing
b] delete the SPN from each of the server objects
c] delete the SPNs from the service account object
d] some combination of b and c
e] __________?
I'm leery of doing "b" and I'm not sure of the impact of "c". Everything I have found searching talks of two domain machines but not the situation of machine+serviceaccount. Any suggestions?
April 26, 2010 at 2:22 pm
Since nobody has replied I am going to try removing the SPNs from the domain based service account and see what happens.
April 27, 2010 at 11:30 am
Deleting the SPNs from the service account results in no access using windows authentication.
Again - anyone got any suggestions?
May 4, 2010 at 11:04 am
Looks like I'm going to answer my own question:
The answer is to delete the SPNs from the machines
May 11, 2010 at 7:07 am
How did you do that? I am having the same issue, it showed up in my backup exec out of the blue.
May 11, 2010 at 7:29 am
You'll need the setspn utility. You can get it here:
I've run it from XPSP3 and Server 2003. You just need an account with sufficient rights to do admin work on the domain.
Once you've got that you can run it against the server's SPNs.
To list the SPNs currently assigned to the server:
setspn -L server1.domain.com
A typical delete command would be like this:
setspn -D MSSQLSvc/server1.domain.com:1433 server1.domain.com
If you need to remove the SPNs from an account (the opposite of what I needed) you have to run ADSI edit to get to that information.
February 19, 2013 at 2:36 pm
merodach;
Kudos to you, you grand-super-DBA you. Wish I had some imaginary internet points to give you right now. Why? Well, for not only posting the details of your your problem but following through with the answer after no one responded.
This morning, one of our Systems techs sent me an EventID 11 Event Log entry identical to the one you've described. I've worked SQL Server KERBEROS issues in the past and one thing that they all have in common is that in no way, other than luck, will one find the cause and solution for one a KERBEROS issue in a single day of research.
Now, thanks to you and your OCD-tendencies, I get to pop back with an intelligent analysis and easy solution the same day the issue was raised. Total win-win for me. You rock, you rock star. Thanks!
And as to the OCD statement, it was said in a tone of complete respect. See, it takes one DBA with OCD to know one, eh? Bet you a dollar that you've done one or more of the following: pushed for standardized server names, spent hours writing SQL Server maintenance related TSQL scripts that are SQL Server version independent, campaigned to have your programmers use three part naming in their code, fought for standardized database names across all dev, test and prod instances. Any of that sound familiar? :-).
Thanks!
Tripp Southern
February 20, 2013 at 10:24 am
"Bet you a dollar that you've done one or more of the following: pushed for standardized server names, spent hours writing SQL Server maintenance related TSQL scripts that are SQL Server version independent, campaigned to have your programmers use three part naming in their code, fought for standardized database names across all dev, test and prod instances."
Server name standards - Oh yeah, been there done that for years. The rest? I appreciate the compliment but I'm afraid I'm not a DBA, just a guy who got hooked into fixing problems when the former so-called "DBA"s got stuck, which was far too often. Thankfully we have a real DBA at work now and my headaches have been greatly reduced.
My biggest push lately has been to get the programmers to use CNAMEs instead of FQDNs, or much worse NETBIOS names - makes things SO MUCH EASIER when a SQL server goes 'poof' and joins the dead kit pile.
BTW - I don't suffer from OCD, I suffer from CDO. It's just like OCD but the letters are in the right order 😀
February 20, 2013 at 11:48 am
merodach (2/20/2013)
BTW - I don't suffer from OCD, I suffer from CDO. It's just like OCD but the letters are in the right order 😀
i love that line! thanks for the chuckle!
Lowell
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply