12 Replies Latest reply on Mar 7, 2011 4:07 AM by GarethHassall

    SQL TCP Port Monitor

    dburgett

      When we are assigning the SQL Server 2005 template to monitor our nodes with SQL, the tests keep failing on the same part.  It is the TCP Port Monitoring portion (the very last one).  The error we get is the following: "no connection could be made because the target machine actively refused it."  We have checked on the servers and TCP/IP is enabled to port 1433 which is the port this monitor is looking for.  Has anyone else had this issue?  Is the TCP Port Monitor really necessary for our SQL servers?  Any help would be greatly appreciated.

        • Re: SQL TCP Port Monitor
          ShamChauthani

          Could it be a firewall blocking access to that port?

          • Re: SQL TCP Port Monitor
            lchance

            is this on Windows 2008 Server?

            it ate our lunch for a long time with port issues until...

            you might look into this area (suggested to me by another Thwack citizen):

            Take a look at Control Panel --> Network and Sharing Center and verify your network type. Depending of your network type, the firewall of Windows 2008 will apply one rule or another... Look at the relationship between your network type and the profile of your 2008 firewall inbound rules...

            We had to be explicit with the SNMP port 161 - maybe you gotta do the same with SQL port.

            good luck!

            • Re: SQL TCP Port Monitor
              philbibby@f2s.com

              Guys,

              Did you get anywhere with this issue?  I've just started adding our vast SQL estate to APM, and out of the first 6 servers only 1 one server is responding to the port monitor - and they're all supposedly built exactly the same!?!?

              We having the problem with SQL2005 and 2008.......

              Any help would be good!

              Phil

                • Re: SQL TCP Port Monitor
                  GarethHassall

                  Hi Team.
                  Has there been any movement on this? I've been having this issue with a number of 2008 R2 SQL servers.

                  A network scan (from my monitoring server) shows that the ports are open.

                  Orion says otherwise. . .

                  Thanks,
                  Gareth.

                    • Re: SQL TCP Port Monitor

                      Gareth--

                      Did you try lchance's suggestion, if applicable?

                      If that doesn't work, open a support ticket. If you don't mind, post back here both the case number and they results you get.

                      Thanks,

                      M

                        • Re: SQL TCP Port Monitor
                          GarethHassall

                          Hi Marie.

                          I have opened case # 226395.
                          So far I have:

                          • Verified that there are no router/firewall blocks between the monitoring and the SQL server.
                          • Verified that there is no block on the Windows server firewall.
                          • Verified within SQL that the TCP/IP connection is enabled.
                          • Restarted the SNMP service. (Unlikely to be the cause but I did it anyway.)
                          • Rebuilt the WMI repository & restarted the WMI service. (Unlikely to be the cause but I did it anyway.)
                          • Verified via a network scan using LanSpy that the port is available.

                          Thanks,
                          Gareth.

                            • Re: SQL TCP Port Monitor
                              GarethHassall

                              Hi All.
                              It appears that last week and this, an external vendor has been working on our servers and changing ports and instance names without informing us. This accounts for the spotty connection to 1433 yesterday and it’s complete failure today. . .as they changed everything to another port.
                              Cheers,
                              Gareth.