June 1, 2011 at 3:08 pm
Your problem is very simple I think. When trying to connect with the name\instance it is expecting to be able get the port from the SQL Browser service, it you reference the clustered machine by ip,port it should connect.
CEWII
June 1, 2011 at 3:23 pm
The sqlcmd being used is it the same from both area's ? What is the difference between the 2 machines you are testing from ? Ie are they both internal in the same domain no restrictions in place to get to your clustered instance of SQL server ?
You will not get any errors in the SQL log if it is not getting to the instance to try and connect. Is there any errors in the event viewer for the time of the connection attempt.
MCT
MCITP Database Admin 2008
MCITP Database Admin 2008
MCITP Database Dev 2008
www.jnrit.com.au/Blog.aspx
June 1, 2011 at 3:47 pm
hey,
Elliott,
simple would be good! So at the moment its using dynamic ports so it would be something like sqlcmd -S 192.168.7.250:6575 (What ever port it says in SSCM under TCP Dynamic port correct??)
Shall try it tomorrow
Warwick
Certainly hope so! i even sent them a screen shoot of the command prompt to try and take out any mistakes...
They are connecting via a vpn tunnel, They used to be able connect to the old cluster via SSMS, now when they try to connect to the new cluster we get these errors 🙁
I cant see any errors in anything on the server side (SQL logs, windows app, system etc). I could ask them to look on there machines?
-- Note i forgot: they can Ping the IP Address. of the instance (192.168.7.250)
Thanks again for all the help both of you! it really is appreciated!
June 1, 2011 at 5:50 pm
From what I can gather they could connect to the old server (standalone) which was configured to 1433 ? Now that you have moved to the cluster and the port number is configured to be dynamic. Elliot said he does not like changing the port configuration, and that is ok. The problem I see with staying with the dynamic is when an instance fails over for whatever reason to another node, your instance restarts. This may or may not go and get another port number (dynamic allocation as it is currently set) depending if the existing port is available or not to re-pick up. This could mean that there is the likelyhood that the client may have to change the connection if they get an error. That is why I have suggested that you set it to a static port.
Just asking the question but is your SQLBrowser service running ? (you may have checked this before and if i missed that my appologies). Also a long shot as you have stated you can get to it from your workstation but if you can confirm for us that the instances are configured to allow remote connections.
MCT
MCITP Database Admin 2008
MCITP Database Admin 2008
MCITP Database Dev 2008
www.jnrit.com.au/Blog.aspx
June 1, 2011 at 8:05 pm
It tends to stick to the port once it starts using one, so a failover would not likely change that. Possible, but not very likely.
Also I saw that you were using http://www.xxx.yyy.zzz:pppp, it should be http://www.xxx.yyy.zzz,pppp
CEWII
June 2, 2011 at 5:52 am
well good news!
they have connected via sqlcmd -S ip,port !
joy...
I can work my way though the process of getting them back to clustername\instance. I will also play around Aliases and static ports!
Thanks to you both! It was really appreciated!
S
June 2, 2011 at 7:43 am
Great news, glad to hear it..
CEWII
June 2, 2011 at 2:38 pm
Excellent.
MCT
MCITP Database Admin 2008
MCITP Database Admin 2008
MCITP Database Dev 2008
www.jnrit.com.au/Blog.aspx
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply