SSPI Handshake Failed error on SQL Server 2008
Running SQL Server 2008 on a Server 2008 R2 box. This server is a member of a domain, and it is not a domain server.
Ever since renaming the server (see below), we get an SSPI handshake error every minute in the SQL server log.
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: a universal address appears here]
The universal address is actually the IPv6 address that appears under the heading
Tunnel adapter 6TO4 Adapter when you do an ipconfig/all on the sql server itself.
We don't use IPv6 that I know of-- I've never configured it. If I disable IPv6 in the configuration window for the network card, the errors still appear.
The database and all user logins work fine. SQL Server Config Mgr shows all services to be up and running. This error started when we renamed the file server that this SQL server resides on.
To replace an older server, we created this server with a temporary name as a member of the domain. We brought the database over from the old SQL server. Tested it, worked fine. Renamed the old server while it was still in the domain. Then renamed this new SQL server to the old server's name. Made the appropriate changes in the DNS in the domain server.
Restarted the server and the errors began.
Looks like some local service is trying to login to the SQL server from the sql server itself and is now failing.
Any ideas?
Ever since renaming the server (see below), we get an SSPI handshake error every minute in the SQL server log.
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: a universal address appears here]
The universal address is actually the IPv6 address that appears under the heading
Tunnel adapter 6TO4 Adapter when you do an ipconfig/all on the sql server itself.
We don't use IPv6 that I know of-- I've never configured it. If I disable IPv6 in the configuration window for the network card, the errors still appear.
The database and all user logins work fine. SQL Server Config Mgr shows all services to be up and running. This error started when we renamed the file server that this SQL server resides on.
To replace an older server, we created this server with a temporary name as a member of the domain. We brought the database over from the old SQL server. Tested it, worked fine. Renamed the old server while it was still in the domain. Then renamed this new SQL server to the old server's name. Made the appropriate changes in the DNS in the domain server.
Restarted the server and the errors began.
Looks like some local service is trying to login to the SQL server from the sql server itself and is now failing.
Any ideas?
Is this server part of a mirror or cluster
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The server is not part of a mirror or cluster.
ASKER
DBA2DBA-- can you be more specific, please.
Note that there is no user name listed in the error message.
You say "please register an SPN for the service account." Which service account are you referring to, and how does one "register an SPN"?
Note that there is no user name listed in the error message.
You say "please register an SPN for the service account." Which service account are you referring to, and how does one "register an SPN"?
ASKER
Also, the link you provided describes problems with a DNS that are corrected by rebooting the DNS. We have a single DNS and this has been rebooted. This did not affect the errors.
ASKER
By shutting down each of the services one at a time, I've established that Reporting Services is generating the error. The user: domain_name\SQLExec is generating these IPv6 errors.
But the main SQL Server service, Analysis Services, and SQL Server Agent all use this user with no problem. And the fact that it shows the IPv6 Address in the errors is also puzzling.
But the main SQL Server service, Analysis Services, and SQL Server Agent all use this user with no problem. And the fact that it shows the IPv6 Address in the errors is also puzzling.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
To correct the SQL Server name in Report Server configuration, probably easiest to use the reporting services configuration program.
http://msdn.microsoft.com/en-us/library/ms159644%28v=SQL.100%29.aspx
http://msdn.microsoft.com/en-us/library/ms159644%28v=SQL.100%29.aspx
ASKER
The link provided by dba2dba might provide a solution in some circumstances, but when the problem derives from renaming the computer hosting SQL server, the two links from Microsoft in my later entry are supposed to correct the problem. Since this is a production server, I will confirm this during the next scheduled down-time. I didn't want to keep the question open for a week. If I still have issues after trying the MS solution, I'll submit a new question.