'm having an interesting problem. I've just installed SQL Server
2012 Developer Edition alongside an existing installation of SQL Server
2008 R2 Developer Edition. The original 2008 R2 edition is the default
instance, and the new installation is a named instance called \DEV.
So far, so good. To enable remote connections, I had to enable named pipes and TCP/IP for the new instance, plus change the login account for SQL Browser to Local System. I also explicitly opened UDP 1434 on the local firewall.
So, new connections will now take 20sec + to establish a connection to the new instance, but will connect to the old instance (2008 R2) almost immediately. In SQLCMD, I have to override the connection timeout with -l30. In SSMS, the initial connection fails out but subsequent reconnections happen immediately. Connecting with other clients, such as RedGate Backup Pro, shows the same issue - I need to amend the connection timeout to 30 seconds as a minimum. Halving the network packet size from 4096 to 2048 helps too.
I've checked SQL Browser, file details show version is 11.x.x.x. Checked with network team, should be no impediment to TCP/UDP traffic with external firewalls etc (besides, connection from a client in the same subnet has same issue).
Does anyone have any ideas, please? It's infuriating. Thanks in advance
ANSWER.
So far, so good. To enable remote connections, I had to enable named pipes and TCP/IP for the new instance, plus change the login account for SQL Browser to Local System. I also explicitly opened UDP 1434 on the local firewall.
So, new connections will now take 20sec + to establish a connection to the new instance, but will connect to the old instance (2008 R2) almost immediately. In SQLCMD, I have to override the connection timeout with -l30. In SSMS, the initial connection fails out but subsequent reconnections happen immediately. Connecting with other clients, such as RedGate Backup Pro, shows the same issue - I need to amend the connection timeout to 30 seconds as a minimum. Halving the network packet size from 4096 to 2048 helps too.
I've checked SQL Browser, file details show version is 11.x.x.x. Checked with network team, should be no impediment to TCP/UDP traffic with external firewalls etc (besides, connection from a client in the same subnet has same issue).
Does anyone have any ideas, please? It's infuriating. Thanks in advance
ANSWER.
f
you connect to the new instance specifying the port number, i.e.
servername,2323 does it connect instantly or does it still take a while?
That should help determine if it is the client finding out the port
number from the browser service causing the slowness or the instance
itself. – steoleary 15 hours ago
|
|
Amendment
to above, checked connectivity from a server sharing the same IP range,
no architecture between them, and connection nearly instant. In
response to steoleary - I have connected via the dynamic port from that
neighbouring server, instant connection, but from anywhere else I can't
connect. Suspect this is because the firewall isn't allowing traffic to
the dynamic port.
I also now suspect that because this problem only manifests when there's
a firewall in the way, the UDP port filtering on the firewall is
somehow to blame.
|
Subscribe to email feed
