In one of my earlier posts, I had mentioned some of the methods to find out on which port SQL Server is listening on. telnet is the most commonly used commands to troubleshoot connectivity issues related to the port. But telnet has its own limitations.
PortQry is one of the not so well known but most useful utilities. As the name suggests this utility provides some useful information while troubleshooting connectivity issues. It has support for almost all the protocols (TCP, UDP, NETBIOS etc.).
Using this tool, connectivity issues for multiple servers can be troubleshooted from a central location. The -n parameter is the one which takes care of this. In the below example I am trying to find out which service is listening on the TCP port 1433, on my local machine. Hence the value of the -n parameter is local.
PortQry.exe -n local -p tcp -e 1433
The output of this command confirms that the SQL Server service is listening on port 1433.
Another unique parameter is -wpid. With this we can easily find out the port on which a given Windows Process listening on. From a SQL Server DBA perspective this parameter is useful when SQL Server is unable to bind to the configured port because some other process is already listening on that port. On my virtual machine, sqlservr.exe is using the PID 6760. The command to get the port details for PID 6760 would be
PortQry.exe -n local -wpid 6760
The output of this command shows that the Process ID 6760 is listening on TCP Port number 1433 and 1434.
I have explained only two parameters of this command. This KB article has the complete list of parameters of PortQry utility and their usage.