Test-NetConnection: Test Remote Ports and Connectivity in PowerShell

The client's server responds to ping, but the application won't open. Is port 443 actually allowed through the firewall? Instead of installing telnet — which Microsoft removed from Windows by default — or relying on ping that only tests ICMP, PowerShell offers a cmdlet that does all of this at once: Test-NetConnection. One command replaces ping, telnet, and traceroute, and delivers the output as an object you can filter and automate.

What Is Test-NetConnection?

Test-NetConnection is part of the NetTCPIP module, available by default on Windows 8.1/Server 2012 R2 and later. It tests four things in a single run:

• DNS resolution of the hostname
• ICMP reachability (equivalent to ping)
• TCP connectivity on a specific port (equivalent to the old telnet host port)
• Network route to the destination (-TraceRoute)

The output is a PowerShell object — not plain text — meaning you can filter by property, compare results, and integrate into monitoring scripts without parsing strings.

Basic Syntax

Test-NetConnection -ComputerName "host-or-ip" -Port 443

The most commonly used parameters:

• -ComputerName: destination hostname or IP
• -Port: TCP port to test
• -CommonTCPPort: shortcut for well-known ports — accepts HTTP, HTTPS, RDP, SMB, WINRM
• -TraceRoute: enables route tracing
• -InformationLevel: Detailed (full output) or Quiet (returns only True/False — ideal for scripts)

How to Test If a Port Is Open on a Remote Server

How can I tell if a TCP port is open on a remote server?

Run Test-NetConnection -ComputerName "server" -Port 443 in PowerShell. If TcpTestSucceeded returns True, the port is reachable. If it returns False, either the port is closed or a firewall is blocking traffic.

Practical example testing HTTPS on a web server:

Test-NetConnection -ComputerName "myserver.company.com" -Port 443

Typical output:

ComputerName           : myserver.company.com
RemoteAddress          : 10.0.0.50
RemotePort             : 443
InterfaceAlias         : Ethernet
SourceAddress          : 10.0.0.10
TcpTestSucceeded       : True

The key field for quick diagnosis is TcpTestSucceeded. One thing to keep in mind: a firewall that responds with RST will return False immediately; one that silently drops packets (DROP rather than REJECT) will stall until timeout before returning False.

Practical Examples by Use Case

Test RDP access (port 3389)

Before trying to connect via Remote Desktop, confirm the service is responding on the right port. If you want to go further and block brute-force on RDP, see how to protect RDP from brute-force attacks.

Test-NetConnection -ComputerName "192.168.1.100" -CommonTCPPort RDP

Test SMB (port 445) before mapping a network drive

Test-NetConnection -ComputerName "fileserver" -CommonTCPPort SMB

Check if the HTTP service is up

Test-NetConnection -ComputerName "intranet.company.com" -CommonTCPPort HTTP

Quiet Mode for Scripts and Monitoring

The -InformationLevel Quiet parameter makes the cmdlet return True or False directly, without the formatted output. Perfect for conditionals in scripts:

if (Test-NetConnection -ComputerName "api.company.com" -Port 8080 -InformationLevel Quiet) {
    Write-Output "Service available"
} else {
    Write-Output "WARNING: port 8080 unreachable"
    # Send alert, log to file, etc.
}

Combine it with an array of hosts for a quick availability scanner:

$hosts = @("web01", "web02", "api01", "db01")
foreach ($h in $hosts) {
    $status = if (Test-NetConnection -ComputerName $h -Port 443 -InformationLevel Quiet) { "OK" } else { "FAILED" }
    Write-Output "$h : $status"
}

This is far cleaner than parsing ping or netstat output. If you also want to inspect what is listening locally, the complementary cmdlet is Get-NetTCPConnection, which lists all open connections and ports on the local machine.

Trace Route in PowerShell

The -TraceRoute parameter shows each hop between your machine and the destination, equivalent to the classic tracert — but with object output:

Test-NetConnection -ComputerName "8.8.8.8" -TraceRoute

The output includes the TraceRoute field with a list of intermediate IPs. If a hop is slow or appears as *, that's where traffic is stalling. Useful for identifying network bottlenecks or confirming that routing takes the expected path.

Checking a Windows Service Before Testing the Port

Sometimes a port is closed simply because the service isn't running. Combine the port test with a local service check to get to the root cause faster. Get-Service handles that part:

# Check if W3SVC (IIS) is running before testing port 80
if ((Get-Service -Name W3SVC).Status -ne "Running") {
    Write-Warning "IIS is stopped — start the service before testing"
} else {
    Test-NetConnection -ComputerName "localhost" -Port 80
}

Security Considerations

Test-NetConnection is also useful for auditing network segmentation: test from a user VLAN whether administrative ports (such as RDP/3389 or WinRM/5985) on servers are reachable when they shouldn't be. If TcpTestSucceeded: True on a combination that violates your firewall policy, you have a misconfigured rule to fix — and you found it without leaving the command line.

If you're just getting started with PowerShell and want to understand the fundamentals before diving into networking cmdlets, the PowerShell for beginners post covers the necessary groundwork.

Conclusion

Test-NetConnection is one of the most practical cmdlets in any Windows sysadmin's toolkit: it tests ping, TCP port, and route in a single command, returns filterable objects, and works with nothing to install. If you suspect a connectivity issue between systems, this should be the first tool you reach for — before checking the firewall, before calling your provider, before anything else.

If you want to dig deeper into network diagnostics via PowerShell, it's worth exploring Get-NetTCPConnection to map open connections on the local machine.