How to Use the Test-NetConnection PowerShell Cmdlet to Troubleshoot Network Ports in Windows

The Problem with Ping and Telnet

When troubleshooting network connectivity in Windows, most administrators instinctively reach for the ping command. However, ping only tests whether a server is online using ICMP traffic. It cannot tell you if a specific service (like a web server on port 443, or a SQL database on port 1433) is actually listening and unblocked by the firewall.

Historically, IT professionals used the Telnet client to test specific ports, but Microsoft disabled Telnet by default in modern versions of Windows due to severe security vulnerabilities. This leaves many administrators frustrated when trying to determine if a firewall is blocking their traffic.

The modern, built-in solution is the PowerShell Test-NetConnection cmdlet. It completely replaces the need for Telnet and provides incredibly detailed diagnostic information without requiring any third-party software.

Step 1: The Basic Connectivity Test

To use the cmdlet, open Windows PowerShell as an Administrator. You can start with a basic connectivity test (which functions exactly like an enhanced ping). Simply type:

Test-NetConnection -ComputerName 8.8.8.8

The output will show your source IP address, the network interface you are using, and whether the ping successfully reached the destination.

Step 2: Testing a Specific TCP Port

The true power of Test-NetConnection (often abbreviated via its alias, tnc) is testing specific TCP ports. If you are trying to Remote Desktop into a server but the connection is failing, you need to know if port 3389 is open. Run the following command:

Test-NetConnection -ComputerName Server-DC01 -Port 3389

When you press Enter, PowerShell will attempt to establish a three-way TCP handshake with the remote server on that exact port.

Step 3: Analyzing the Results

Unlike traditional command-line tools that spit out raw text, PowerShell returns a clean object. You will see several fields, but the most critical one is TcpTestSucceeded.

• If TcpTestSucceeded : True, the network path is completely clear. The remote server is online, the service is listening on that port, and no firewalls (Windows Defender or physical hardware firewalls) are blocking the traffic.
• If TcpTestSucceeded : False, the connection failed. This guarantees that either the service on the remote server is crashed/stopped, or a firewall is actively dropping your packets.

Step 4: Performing an Advanced Traceroute

If your basic connectivity is failing, you need to find exactly where the packets are dying. Test-NetConnection can also perform an advanced traceroute to map every router hop between your computer and the destination:

Test-NetConnection -ComputerName google.com -TraceRoute

This command combines DNS resolution, ICMP pinging, and route tracing into one single, powerful diagnostic output. It is the absolute best tool for troubleshooting Windows network dropouts.