• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 444
  • Last Modified:

Event ID 11 in the System log of domain controllers

I am getting the error
There are multiple accounts with name MSSQLSvc/mcwp-s01.local:1433 of type DS_SERVICE_PRINCIPAL_NAME on a Widows 2003 server running SQL.
I have found the 2 accounts..please see results from using method 1 ldp support tool from article kb 321044.
***Searching...
ldap_search_s(ld, "DC=mcwp,DC=local", 2, "(serviceprincipalname=MSSQLSvc/mcwp-s01.mcwp.local:1433)", attrList,  0, &msg)
Result <0>: (null)
Matched DNs:
Getting 2 entries:
>> Dn: CN=MCWP-S01,OU=Domain Controllers,DC=mcwp,DC=local
      5> objectClass: top; person; organizationalPerson; user; computer;
      1> cn: MCWP-S01;
      1> distinguishedName: CN=MCWP-S01,OU=Domain Controllers,DC=mcwp,DC=local;
      1> name: MCWP-S01;
      1> canonicalName: mcwp.local/Domain Controllers/MCWP-S01;
>> Dn: CN=SQLMAN,OU=Service Accounts,OU=MCWP,DC=mcwp,DC=local
      4> objectClass: top; person; organizationalPerson; user;
      1> cn: SQLMAN;
      1> distinguishedName: CN=SQLMAN,OU=Service Accounts,OU=MCWP,DC=mcwp,DC=local;
      1> name: SQLMAN;
      1> canonicalName: mcwp.local/MCWP/Service Accounts/SQLMAN;

I am confused on what step to take next because in the article kb321044 it says to either delete the computer account from domain or disjoin and rejoin to the domain. The problem is one of these is a service account and is not a computer account.  Any ideas on what i should do to fix this error?
0
mcwllc
Asked:
mcwllc
  • 5
  • 3
  • 2
1 Solution
 
Henrik JohanssonSystems engineerCommented:
Use setspn command line tool to remove the SPN from the account that shall not be used.

C:\>setspn -D MSSQLSvc/mcwp-s01.mcwp.local:1433 MCSWP-S01
0
 
dan_blagutCommented:
Hello

To us that problems appeared because of a restoration of SQL servers from ghost. You can delete the reccords from AD, but you can delete the wrong reccord. So we chosed to leave with that error and to warned by a yelow card to the SQL team.

Dan
0
 
Henrik JohanssonSystems engineerCommented:
Check in services manager what user the SQL service is logging on as.
Is it running as a local user or the "local system"/"network service" accounts? If so, the SPN shall be kept on the computer account. If running with a domain user as service account, the SPN shall be kept on the domain user account.

The suggestion from the KB to delete/rejoin the computer is overkill when it's enough to use setspn command line tool as posted in http:#31007904.

http://support.microsoft.com/kb/321044 also mentions ADSIEdit. To do that, open the adsiedit.mmc and navigate to the object that shall be modified. Open up the properties dialog for the object and scroll down to the line with the property name to modify it.
It's a little bit quicker to use the setspn.exe command line tool, and propably also safer as the command only modifies the necessary property instead of giving access to all properties of all objects.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
mcwllcAuthor Commented:
I notice that the services related to SQL are using a mixture of the two depending on the service.
Agent uses Local System...Analysis Services is using SQLMAN....I will just switch them all to the same account and go from there. I am guessing there shouldn't be any issues with doing that. Thanks for the help...makes sense what you have suggested.
0
 
mcwllcAuthor Commented:
I have switched all servces to use the local system ...so now i am wanting to delete the SQLMAN account. If i just delete the account in Active Directory users and computers will this fix the issue? Or should i still use the setspn command? If so how should the setspn command look since i'm deleting the SQLMAN account. I appreciate the help...just being extra cautious so i don't break anything. Thanks again for the help.
0
 
mcwllcAuthor Commented:
I am wanting to finish this today...sorry for taking so long!
0
 
mcwllcAuthor Commented:
one more thing...i disabled the sqlman account thinking that would fix the issue ..but the error still exists in the error logs ..so now i am taking the next step.
0
 
dan_blagutCommented:
Hello

I don't think that is an account problems, instead it is a double service record problem in AD. To fix that you need to delete one DS_SERVICE_PRINCIPAL_NAME  from AD using ADSedit.
The procedure was already presented by henjoh09.

Dan
0
 
mcwllcAuthor Commented:
that makes sense i just wanted to be sure though...if i break something on the sql server...serious issues would occur!
0
 
Henrik JohanssonSystems engineerCommented:
The logging is normal when changing to use another service account if not deleting the SPN from the old service account.
Deleting the additional SPN from the account that isn't used as service account shouldn't harm the system. Check with services.msc what user account is beeing used as service account and remove the SPN from the other account.
As I posted above, I would prefer to use setspn.exe command line tool instead of using ADSIedit. setspn.exe command line tool can be used to both add and delete SPNs, so you can always add it back if you delete the wrong one.
C:\>setspn -D MSSQLSvc/mcwp-s01.mcwp.local:1433 MCSWP-S01

Open in new window

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

  • 5
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now