April 24, 2015 at 9:13 am
We have a linked server set up. It will connect with no problem, but it seems that we periodically are winding up with the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
If left alone for a period of time (maybe 20 minutes to an hour) it will then start working again.
We can reproduce the issue by leaving a window in SQL Management studio open overnight. Every morning without fail the same script will stop running and get that error. if we close the window and reopen it later, it starts working again.
Is there some kind of timeout setting or other connection setting that might causing issues?
April 24, 2015 at 5:40 pm
Check the linked server to see if there's a timeout setting. However, this to me sounds like a networking issue. Is there other stuff running at the same time that still works fine? It almost sounds like an AD problem.
April 29, 2015 at 11:04 am
The Timeout for the linked server is set to 0
Once it fails for me, the related SQL job will also fail if it is run. Given 20 minutes or so, it will start working again.
October 10, 2016 at 11:31 am
Did you check if the account with which the Linked server is set up is not locking out periodically for some reason causing you this error? The problem getting resolved after sometime suggests that it gets unlocked after sometime because of the AD settings.
October 10, 2016 at 12:27 pm
That's what we suspect, but have not been able to confirm it, or track down why
October 11, 2016 at 6:25 am
Seemita Das (10/10/2016)
Did you check if the account with which the Linked server is set up is not locking out periodically for some reason causing you this error? The problem getting resolved after sometime suggests that it gets unlocked after sometime because of the AD settings.
I would tend to have someone look into network activity.
I doubt that a Service Account is getting locked out.
They are usually restricted to logon to only the machine they are used on.
If there is delay from the DC or over the network you can get this.
I recall setting 3 registry keys on all machines in the network.
MaxPacketSize was one, but there was one to force Kerberos to use TCP/IP, not roll over to UDP.
Wish I could remember the 3rd one, but I retired a few years ago, so I haven't done this since.
TCP/IP is a acknowledged delivery, where UDP is not.
October 11, 2016 at 11:09 am
If there is delay from the DC or over the network you can get this.
I recall setting 3 registry keys on all machines in the network.
MaxPacketSize was one, but there was one to force Kerberos to use TCP/IP, not roll over to UDP.
Wish I could remember the 3rd one, but I retired a few years ago, so I haven't done this since.
TCP/IP is a acknowledged delivery, where UDP is not.
Maybe the third was disabling TCP Chimney Offloading? I've seen that cause odd network issues.
Sue
October 11, 2016 at 12:52 pm
It looks like the MaxPacketSize is fixed and Kerberos should always use TCP.
But I'd check to verify the key just in case.
Turn on logging for a machine and see if when it fails you get anything.
Be sure to reboot after changing the key and setting up the test.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply