Essential Tools: Port Query

9 Jan 2012 5-minute read Al Eardley
On-Prem
ToolsSQL Server

One of the tools that I like to have on every server is Port Query. Port Query has been available as a free utility for many years.

The purpose of this tool is to query ports using either TCP or UDP protocols. Under the hood it uses a simple command line application that talks to different services listening on different ports.

As a DBA I use this tool on a regular basis to test that ports on a database server are listening, and more importantly, that they can be reached from application servers.

Install Port Query UI

Port Query is a collection of files and does not need to be installed, just unzipped.

Once the file is downloaded double click it to run the self extractor. Once the licence terms have been accepted, select a folder to extract the files to and click ‘Unzip’.

That’s all there is to it.

Port Query Interface

In the folder where the files were unzipped, double click ‘portqueryui.exe’

This opens the interface.

There are not many options:

Enter Destination IP or FQDN: As the label suggests – you enter the name of the server that you want to query.

Query Type: The two options here are where the power of this tool is.

Manual Query

Starting with a manual query type. The machine I am currently on has some database instances running, but, oh dear, I do not know which ports they are on. I can find out by enabling the SQL Browser service which I do know runs on port 1434.

I can then enter 1434 as the port and select ‘BOTH’ for the protocol:

When I click ‘Query’, port 1434 will be queried using both TCP and UDP protocols and the result will be displayed in the ‘Query Result’ pane.

The full results read:

\=============================================

Starting portqry.exe -n 127.0.0.1 -e 1434 -p BOTH …

Querying target system called:

127.0.0.1

Attempting to resolve IP address to a name…

IP address resolved to Lightning

querying…

TCP port 1434 (ms-sql-m service): NOT LISTENING

UDP port 1434 (ms-sql-m service): LISTENING or FILTERED

Sending SQL Server query to UDP port 1434…

Server’s response:

ServerName LIGHTNING

InstanceName SQL2008

IsClustered No

Version 10.50.1600.1

tcp 56960

ServerName LIGHTNING

InstanceName DBA

IsClustered No

Version 10.50.1600.1

tcp 60801

ServerName LIGHTNING

InstanceName SQLEXPRESS

IsClustered No

Version 10.0.4000.0

\==== End of SQL Server query response ====

UDP port 1434 is LISTENING

portqry.exe -n 127.0.0.1 -e 1434 -p BOTH exits with return code 0×00000000.

From this information, it is clear that port 1434 is listening and responding. It also provides information that can be used to diagnose any communication issues that may occur with any of the database instances on the server.

Negative Result

If I now turn off the SQL Browser service and re-run the same query the results are very different:

\=============================================

Starting portqry.exe -n 127.0.0.1 -e 1434 -p BOTH …

Querying target system called:

127.0.0.1

Attempting to resolve IP address to a name…

IP address resolved to Lightning

querying…

TCP port 1434 (ms-sql-m service): NOT LISTENING

UDP port 1434 (ms-sql-m service): LISTENING or FILTERED

Sending SQL Server query to UDP port 1434…

UDP port 1434 (ms-sql-m service): FILTERED

portqry.exe -n 127.0.0.1 -e 1434 -p BOTH exits with return code 0×00000002.

The results indicate that port 1434 is open but there is no service listening or there is a firewall in the way.

Predefined Query

The alternate to a manual query is a pre-defined query.

These checks combine different ports and different types of service check. They are defined in an XML file called ‘Config.xml’ that is in the folder where all of the files where unpacked.

The structure of the file is very straight forward, although some of the ports and the services that are checked are not fully up to date with latest releases.

  <Service Name="SQL Service">
    <Port Name="Browser" Value="1434" Protocol="UDP"/>
    <Port Name="Default" Value="1433" Protocol="TCP"/>
    <Port Name="ms-sql-s service" Value="1450" Protocol="TCP"/>
  </Service>
  <Service Name="WEB Service">
    <Port Name="HTTP" Value="80" Protocol="TCP"/>
    <Port Name="FTP" Value="20-21" Protocol="TCP"/>
    <Port Name="SMTP" Value="25" Protocol="TCP"/>
    <Port Name="POP3" Value="110" Protocol="TCP"/>
    <Port Name="Telnet" Value="23" Protocol="TCP"/>
  </Service>

The sample of code above defines the checks that are carried out for SQL Server and for a web server, based on the assumption that those are the services that are expected to be available.

The benefit of this config file is that for a given environment, a set of checks can be configured if the ports and protocols are known, e.g. For the server the I am working with I can check the ports that SQL Server is using:

  <Service Name="Local SQL Server">
    <Port Name="Browser" Value="1434" Protocol="UDP"/>
    <Port Name="Instance - SQL2008" Value="56960" Protocol="TCP"/>
    <Port Name="Instance - DBA" Value="60801" Protocol="TCP"/>
  </Service>

I can then find ‘Local SQL Server’ in the list of pre-defined queries:

And running this will provide specific information related to my server:

\=============================================

Starting portqry.exe -n 127.0.0.1 -e 1434 -p UDP …

Querying target system called:

127.0.0.1

Attempting to resolve IP address to a name…

IP address resolved to Lightning

querying…

UDP port 1434 (ms-sql-m service): LISTENING or FILTERED

Sending SQL Server query to UDP port 1434…

Server’s response:

ServerName LIGHTNING

InstanceName SQL2008

IsClustered No

Version 10.50.1600.1

tcp 56960

ServerName LIGHTNING

InstanceName DBA

IsClustered No

Version 10.50.1600.1

tcp 60801

ServerName LIGHTNING

InstanceName SQLEXPRESS

IsClustered No

Version 10.0.4000.0

\==== End of SQL Server query response ====

UDP port 1434 is LISTENING

portqry.exe -n 127.0.0.1 -e 1434 -p UDP exits with return code 0×00000000.

\=============================================

Starting portqry.exe -n 127.0.0.1 -e 56960 -p TCP …

Querying target system called:

127.0.0.1

Attempting to resolve IP address to a name…

IP address resolved to Lightning

querying…

TCP port 56960 (unknown service): LISTENING

portqry.exe -n 127.0.0.1 -e 56960 -p TCP exits with return code 0×00000000.

\=============================================

Starting portqry.exe -n 127.0.0.1 -e 60801 -p TCP …

Querying target system called:

127.0.0.1

Attempting to resolve IP address to a name…

IP address resolved to Lightning

querying…

TCP port 60801 (unknown service): LISTENING

portqry.exe -n 127.0.0.1 -e 60801 -p TCP exits with return code 0×00000000.

Summary

This is a useful tool that can be configured for different server applications to check that the server application is listening and responding on the correct ports. I have used this tool to successfully diagnose issues connecting to SQL Server, SharePoint, FAST Search Server, SMTP Servers and Web Servers.

Comment on this post: