April 5, 2010 at 1:21 pm
also, perhaps there is something running as a local account (ie MACHINENAME\USER) or NT AUTHORITY\SYSTEM that is trying to log in...
If you have the client machine, you should be able to do a netstat -o to determine what process is initiating a connection to your sql server.
April 7, 2010 at 5:54 am
Nothing running under local account and no issues with RDP
April 7, 2010 at 6:03 am
You always see the same IP address in the error log, right?
If so, can you go to that machine and do a netstat -o... this will show you all connections from the client and the associated process id. You should be able to look through the results and find connections to your SQL Server from that client. You can then have a look at the task manager and sort by process id to see what process is connecting to your server.
Really curious to find out what this is.
April 7, 2010 at 6:17 am
I've faced this issue in the past. For me, manually registering the SPN resolved the issue.
Here is the syntax for the same.. This has to be run by a domain administrator on AD.
setspn -A MSSQLSvc/myhost.redmond.microsoft.com:1433 accountname
Refer:- http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx
April 7, 2010 at 6:25 am
Paul White NZ (4/4/2010)
There are answers to most connectivity problems on the SQL Server Protocol Team's blog:http://blogs.msdn.com/sql_protocols/archive/2005/09/28/474698.aspx
http://blogs.msdn.com/sql_protocols/archive/2005/12/22/506607.aspx
http://blogs.msdn.com/sql_protocols/archive/2005/10/29/486861.aspx
...etc.
From earlier. š
Not the same link exactly, but the same blog.
Might have saved some time by visiting it...?
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 7, 2010 at 6:29 am
Paul White NZ (4/7/2010)
Paul White NZ (4/4/2010)
Might have saved some time by visiting it...?
I should have :w00t:
April 7, 2010 at 6:34 am
April 7, 2010 at 10:43 am
NJ-DBA (4/5/2010)
correction- i think it was āRead servicePrincipalNameā and āWrite servicePrincipalNameā
Correct they are the permissions to assign in ADSIEDIT to the service account. You also need to trust the account for delegation in AD users and computers > account properties
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" š
April 7, 2010 at 10:52 am
Paul White NZ (4/7/2010)
Paul White NZ (4/4/2010)
There are answers to most connectivity problems on the SQL Server Protocol Team's blog:http://blogs.msdn.com/sql_protocols/archive/2005/09/28/474698.aspx
http://blogs.msdn.com/sql_protocols/archive/2005/12/22/506607.aspx
http://blogs.msdn.com/sql_protocols/archive/2005/10/29/486861.aspx
...etc.
From earlier. š
Not the same link exactly, but the same blog.
Might have saved some time by visiting it...?
Possibly.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 8, 2010 at 11:12 am
We have this issue almost every month or so on various server. It has turned out to be a DC issue in each case. Withe several hundred instances and numerous DC's it has been a pain to resolve!
April 8, 2010 at 11:17 am
chubbsm (4/8/2010)
We have this issue almost every month or so on various server. It has turned out to be a DC issue in each case. Withe several hundred instances and numerous DC's it has been a pain to resolve!
I would say reduce the number of DCs, unless they are out there at remote offices that have poor connectivity (which would also be another cause for this issue).
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 11 posts - 16 through 25 (of 25 total)
You must be logged in to reply to this topic. Login to reply