October 19, 2021 at 2:15 pm
Dear Friends,
I setup SQL server on two boxes and setup AOAG (Read Scale). I enabled TCP/IP and assigned static ports to both. The instance can see and connect to each other , but when I connecting from my client I get the standard error for connection failure ("Instance-Specific or Network failure...") ..Thank you for the help.
Best Rgds
Arshad
October 19, 2021 at 3:46 pm
Can your client machine see the servers? Could be firewall issues (that would be one of my first guesses) or network related. I would try connecting by the full name (server.domain.com/instance, port) and see if you can connect. If you can't, it is probably firewall related. If you can, try without the port. If that fails, check that the SQL Browser service is running and try again. If it works, then try server/instance. If that fails, it is likely a DNS issue.
You could also try pinging the server (assuming the server replies to pings; this can be disabled) from the client.
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.
October 20, 2021 at 8:06 am
Hi Brian,
Yeah , my laptop can see the servers , can RDP ,and also get the ping response. TCP/IP is enabled too and the Browser service up too (The reason why the SSMS from inside the servers , connects well to each other). Another piece in the Story is that SSMS from my laptop can connect well to another instance on one of these servers. Wondering what can be wrong with this instance. Pls send across anything that you think is the cause.
Thanks...Arshad
October 20, 2021 at 2:19 pm
A lot of my advice still applies. I would try connecting by the FQDN name of the server as well as the port.
You ruled out DNS because you can RDP, but you haven't ruled out firewall. Each SQL instance needs to use a unique port. So just because you can connect to instance A on server A from SSMS doesn't mean that you can connect to instance B on server A.
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.
October 25, 2021 at 2:33 pm
Hi Brian,
This works on the SQL server default port though. So , clearly some ports issue at the firewall. I can now connect to both the instances from my laptop.
Thanks..Arshad
October 25, 2021 at 3:29 pm
As I said multiple times - Firewall. Just because port A is open in the firewall and you can connect to SQL instance B doesn't mean that port C is open to connect to instance D. Each SQL instance needs to listen on its own port. Each port can only have 1 application listening on it (with a few exceptions).
So if SQL instance A is listening on port 1334 and SQL instance B is listening on port 4567, you would need to have BOTH ports open in the firewall.
You have basically ruled out all options apart from firewall from what I can tell, so that would make me look at the firewall. As a temporary solution, you could try turning off the firewall and see if you can connect. If you can, then reconfigure the firewall to allow the port through as you have now proven it is the firewall. If you still can't, I'd reach out to the network infrastructure team to see if they have a hardware firewall in place.
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.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply