"The app says it can't connect to the server" is a classic help desk ticket. The tempting fix is to reinstall the app. Before you do that, spend one minute finding out whether the problem is the network path or the app itself. On Windows, PowerShell has a built-in command for exactly this: Test-NetConnection.
What Test-NetConnection does
Test-NetConnection (alias tnc) checks whether your computer can reach another computer. With the -Port parameter, it tries to open a TCP connection to a specific port, which is what the app actually needs. A regular ping only tells you the host answers ICMP, and many servers block ping even when the app works fine.
Step 1: Find the server name and port
Check the app's settings, the vendor docs, or your internal KB for the server name and port. Common ones:
- 443 for HTTPS web apps and APIs
- 445 for Windows file shares (SMB)
- 3389 for Remote Desktop
- 1433 for Microsoft SQL Server (default instance)
Step 2: Run the test
Open PowerShell (no admin rights needed) and run:
Test-NetConnection appserver01 -Port 443
Replace appserver01 with the real server name and 443 with the app's port.
Step 3: Read the result
Name resolution fails. If you see a warning that name resolution failed, the computer can't turn the name into an IP address. That's a DNS problem. Check it with:
Resolve-DnsName appserver01
If the user is remote, confirm they're connected to the VPN, since internal names often only resolve on the company network.
TcpTestSucceeded : True. The port is reachable from this computer. The network path is fine, so focus on the app: the user's login, the app version, its config, or the service on the server side.
TcpTestSucceeded : False. The name resolved but the connection didn't open. Something on the path is blocking it, or the service isn't listening. Check whether the VPN is connected, whether other users have the same issue, and whether the service on the server is running. This is the result to escalate to the network or server team.
For a bit more detail on where the traffic goes, add -InformationLevel Detailed:
Test-NetConnection appserver01 -Port 443 -InformationLevel Detailed
Step 4: Document it
Put the command, the server, the port, and the result in the ticket. "TcpTestSucceeded False to appserver01:443 from user's laptop on VPN" is something the next team can act on right away.
Takeaway
Before you reinstall an app that "can't connect," test the path. One command tells you whether it's DNS, the network, or the app, and it keeps you from fixing the wrong thing.
Top comments (1)
One qualification to “the network path is fine”:
TcpTestSucceeded: Trueconfirms TCP connection establishment to the reported address/port at that moment. It does not test the HTTPS/TLS exchange, an application request, or the app’s proxy path. Microsoft describes those TCP and routing diagnostics separately. I would recordRemoteAddress,InterfaceAliasand the test time, then compare with the actual failing application request. That keeps this useful first test from ruling out intermittent or later-stage network failures too early.AI-assisted reply; I work on Lisar Connect.