Canot connect to Prod1

  • Tried using SQL authentication but getting below error.

    A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (Provider : TCP Provider, error: 9 - The specified network name is no longer available) Microsoft SQL server, Error: 64)

    • This topic was modified 1 month, 1 week ago by  ramana3327.
    • This topic was modified 1 month, 1 week ago by  ramana3327.
  • What is the error detail from the sql error log

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • I may be mistaken but I am pretty sure that the error "The specified network name is no longer available" means that your computer lost access to the server for some reason. It COULD be your wifi dropped out, could be that your firewall blocked the connection, could be someone unplugged your network cable in the middle of the handshake. But basically, looks (to me anyways) to be a network issue between your machine and the server.

    But as Perry Whittle indicated, reviewing the logs will give you more to go on. Check the SQL error logs but also check the windows logs as it could be a sign of a failing NIC. Google gives a few suggestions too. One they say it could be is database corruption - detected corruption and booted your connection to try to reduce the corruption until an admin can get in and check it. Does DBCC CHECKDB bring back anything bad? Also, not likely the culprit since you are using SQL authentication, but are your SPN's set up correctly? Also, is this happening for everyone or just you?

    For checking the SQL Log and Windows log and running DBCC commands, RDP into the server hosting the SQL instance and do your investigation. If you can't RDP in, find someone who can and have them do the investigation.

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

  • You can see if SPNs are generated automatically from the sql error log

    if not generated automatically would warrant further inspection to see if they have been manually created

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • The way things are set up in my environment, IT doesn't let me auto-generate my SPN's. I can't even make the SPN's. I need to put in a support request to get my IT department to make them. I send the commands over, and they run them for me. Don't trust me with making the SPN's, but trust me to send them non-malicious code.

    BUT I get it - if the SPN's break anything, IT is on the hook for it and they need to narrow down what happened. The fewer people who can make (and break) SPN's means the less likely they are to break.

    I agree with you 100% though Perry - without reviewing the logs, the error is impossible to know for certain what is wrong. SQL logs and Windows/Linux logs as either one could have a hint as to the problem and help troubleshooting.

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

  • There are 2 permissions that need to be applied to service accounts when running under a low privilege domain account

    • writeserviceprincipalname
    • readserviceprincipalname

    some AD admins don’t like to grant these some do, also the delegation should be carefully constrained which is more important.

    Using gmsa’s offers more security and seamless account usage

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply