Event ID 11 "There are multiple accounts with name MSSQLSvc/..."

  • 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?

  • Since nobody has replied I am going to try removing the SPNs from the domain based service account and see what happens.

  • Deleting the SPNs from the service account results in no access using windows authentication.

    Again - anyone got any suggestions?

  • Looks like I'm going to answer my own question:

    The answer is to delete the SPNs from the machines

  • How did you do that? I am having the same issue, it showed up in my backup exec out of the blue.

  • You'll need the setspn utility. You can get it here:

    SETSPN download on MS's site

    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.

  • 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

  • "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 😀

  • 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


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply