Hey all,
I'm struggling with an odd problem on my new SQL cluster and wondered what I am missing. Briefly, I have deployed a 2 node cluster with two instances, one default and one named, on separate cluster network names. NB: As this is a new deployment we are using SQL 2019, although even though it's very new, I don't think the version a factor.
I have servers SQL01 & SQL02, running Server 2019 Core.
Virtual network names SQLCL01 & SQLCL02
SQLCL01 has a default instance on it
SQLCL02 has a named instance called Instance2
I can connect to the default instance all day long no problems, but the named instance is giving me some jip. From the SQL server connect dialog, I can browse from a remote computer and see the instance in the list. If I connect from our old SQL 2014 server (Management Studio 12), it connects immediately no problems whatsoever.
When I try to connect from a new server I have spun up (on the same subnet), or my desktop machine (different subnet) with the latest Management Studio (18 or 17) on it will not connect unless I specify the port number. This happens regardless of using dynamic ports or setting the port to 1433 for the named instance.
Things I have tried / ruled out
The Server firewalls have been disabled during testing
There are no firewalls or ACLs blocking ports between SSMS & the cluster
I have forced the port to 1433 for the named instance and also used dynamic ports with the same results
DNS is resolving to the right place
Verified that the SQL browser service is running
Verified port 1433 TCP (or the dynamic port) & 1434 UDP is open with Nmmap
I can still only connect when specifying the port. I don't want to do this because I want to keep the setup of any client apps as standard as possible so as not to confuse the helpdesk. What is really doing my nut is that SQL 2014 / SSMS 12 is going straight in, no messing.
Does anyone have any clues for me? I am tearing the remainder of my hair out!
Cheers,
Mark
I'm struggling with an odd problem on my new SQL cluster and wondered what I am missing. Briefly, I have deployed a 2 node cluster with two instances, one default and one named, on separate cluster network names. NB: As this is a new deployment we are using SQL 2019, although even though it's very new, I don't think the version a factor.
I have servers SQL01 & SQL02, running Server 2019 Core.
Virtual network names SQLCL01 & SQLCL02
SQLCL01 has a default instance on it
SQLCL02 has a named instance called Instance2
I can connect to the default instance all day long no problems, but the named instance is giving me some jip. From the SQL server connect dialog, I can browse from a remote computer and see the instance in the list. If I connect from our old SQL 2014 server (Management Studio 12), it connects immediately no problems whatsoever.
When I try to connect from a new server I have spun up (on the same subnet), or my desktop machine (different subnet) with the latest Management Studio (18 or 17) on it will not connect unless I specify the port number. This happens regardless of using dynamic ports or setting the port to 1433 for the named instance.
Things I have tried / ruled out
The Server firewalls have been disabled during testing
There are no firewalls or ACLs blocking ports between SSMS & the cluster
I have forced the port to 1433 for the named instance and also used dynamic ports with the same results
DNS is resolving to the right place
Verified that the SQL browser service is running
Verified port 1433 TCP (or the dynamic port) & 1434 UDP is open with Nmmap
I can still only connect when specifying the port. I don't want to do this because I want to keep the setup of any client apps as standard as possible so as not to confuse the helpdesk. What is really doing my nut is that SQL 2014 / SSMS 12 is going straight in, no messing.
Does anyone have any clues for me? I am tearing the remainder of my hair out!
Cheers,
Mark