February 3, 2005 at 9:26 am
Hi all,
Our production DBA noted that we are getting the following intermittent warning's in the application event log:
Event Type:
WarningEvent Source:
MSSQL$xxxxxxxxEvent Category:
(8)Event ID: 19011
Date: 03/02/2005
Time: 05:56:52
User: N/AC
omputer: xxxxxxxx
Description:SuperSocket info: (SpnRegister) : Error 8344.
We aren't seeing any ntoiceable error's at these event's. Searching the web, I found the following:
quote:
This just means that the service account you are running SQL under does not have permissions to register an SPN in Active Directory. It is nothing to be concerned about. If you require an SPN for linked server account delegation then you can add one manually using setspn or ADSIEdit.--
HTH
Jasper Smith (SQL Server MVP)
What I've found in BOL sees to related to querying AD from SQL:
"OLE DB Provider for Microsoft Directory Services"
"For Kerberos authentication, delegation, and mutual authentication to work, the MSSQLServerOLAPService service must run under one of the following types of accounts: "
"To use delegation, all servers that you are connecting to must be running Microsoft® Windows® 2000, with Kerberos support enabled, and you must be using Microsoft Active Directory™, the directory service for Windows 2000. The following options in Active Directory must be specified as follows in order for delegation to work: "
Now, at a guess, this relates to that last hit, since we are running in a cluster, while we are not running analysis services (that I know of ... but hey, I'm the dev dba ), and are not querying the AD services (again, that I know of).
So - is this something to be concered about, should I tell them to regsiter the SPN for sql, using the setspn utility?
Ta
*##* *##* *##* *##*
Chaos, Disorder and Panic ... my work is done here!
February 3, 2005 at 10:10 am
Unless you see a negative impact I do believe you can ignore this message. Not sure if there is anywhere you can just turn off thou.
February 3, 2005 at 1:18 pm
I would use setspn to resolve the problem, it's one less thing that you have to concern yourself with from that point on (and the fix only takes a matter of a few seconds).
February 4, 2005 at 12:41 am
Thanks for the responses.
Does anyone have any idea why it might be happening, though? I kinda HATE having things I can't explain, happening on server's I have a hand in... (even if it is second-hand, as in this case).
CiaO
February 4, 2005 at 5:53 am
Basically, as the SQL service account that you are using is not a domain admin and does not have sufficient priveledge to register itself correctly in active directory. Using the setspn tool registers it for you.
February 4, 2005 at 6:09 am
Thanks Nicholas!
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply