July 24, 2023 at 2:26 pm
This is one of the mysterious things that clearly something changed, and n0body knows what.
We have our monitoring software installed on a SQL 2019 server. Last week, it stopped connecting to two servers, SQL 2016 and SQL 2014 versions.
Both are named instances.
The connections were set up as ServerName\InstanceName, and this has been in place for 2 years.
Now, in order for the monitoring as well as connecting using SSMS, we need to enter the port in the connections. ServerName\InstanceName,1433 in order to connect.
I've looked at the setting on all of these servers, SQL browser is running and the network setting are correct. There is little access to the two failing servers, 4 of us in my group are the only folks who have access to these.
The network and security folks have looked at everything on their end and have reported nothing.
At this point it's only a PITA, but what we want to prevent is someone in security from "reviewing issues" and making additional changes that break even more things.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
July 24, 2023 at 3:56 pm
check if UDP 1434 is open - not sure if that was included in 'checking if the network settings are correct.'
Also confirm if the correct network profile is active. If it is a domain machine, it should always be type 'domain.' If it is workgroup, it should be 'private.' If it is on the wrong profile, typically restarting the network location awareness service will allow it to rediscover the correct profile if your DNS and time is good.
If the firewall is disabled, turn it back on then configure the ports. I would never advise it to be turned off under any circumstance, at most I would open on all UDP, TCP ports and for icmp, but if you are going to turn it off, configure all the rules that are required while it is turned on, before turning it off.
July 24, 2023 at 3:57 pm
oh and use something like portqryv2.exe from the monitoring SQL server to check if it is actually listening
July 24, 2023 at 5:03 pm
check if UDP 1434 is open - not sure if that was included in 'checking if the network settings are correct.'
Also confirm if the correct network profile is active. If it is a domain machine, it should always be type 'domain.' If it is workgroup, it should be 'private.' If it is on the wrong profile, typically restarting the network location awareness service will allow it to rediscover the correct profile if your DNS and time is good.
If the firewall is disabled, turn it back on then configure the ports. I would never advise it to be turned off under any circumstance, at most I would open on all UDP, TCP ports and for icmp, but if you are going to turn it off, configure all the rules that are required while it is turned on, before turning it off.
1434, as well as a many other ports, are open for these servers. That was one of the first things we looked at. We THINK we know what was changed by the security team, but getting them to admit that they made a mistake is virtually impossible
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
July 24, 2023 at 5:17 pm
Is there some sort of host based nips/firewall installed other than defender?
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply