Windows Server Network and DNS Troubleshooting with PowerShell

When an application cannot reach a server, split the problem into smaller questions. Does the name resolve to the expected address? Can the client establish a TCP connection to the service? Does the application then complete its own protocol and authentication?

Run the tests from an affected client or server, not only from a machine where the application already works. The commands below inspect configuration or perform bounded queries; they do not reset the network stack or change firewall rules.

Record the current adapter and DNS configuration

Get-NetIPConfiguration
Get-DnsClientServerAddress
route print

Identify the interface used for the destination, its address and gateway, and the configured DNS servers. Note VPN adapters, multiple network interfaces and any recent changes. On a domain-joined server, do not replace the configured domain DNS servers with a public resolver as a generic fix; internal names and domain-service discovery need the appropriate DNS infrastructure.

Test name resolution separately

Replace the example hostname with the affected service. Use the actual intended resolver address for the second query; 192.0.2.53 below is a documentation placeholder.

Resolve-DnsName -Name 'app.example.com' -Type A -DnsOnly
Resolve-DnsName -Name 'app.example.com' -Type A -Server '192.0.2.53' -DnsOnly

Compare returned addresses and errors. Repeat with -Type AAAA when IPv6 is relevant. A timeout differs from a response saying the name does not exist. Microsoft's Resolve-DnsName documentation explains selecting the record type and resolver.

Inspect the client cache with Get-DnsClientCache before clearing it. Flushing a cache may remove stale data locally, but it does not repair an incorrect authoritative record or an unreachable DNS server.

Test the port the application actually uses

Test-NetConnection -ComputerName 'app.example.com' -Port 443 -InformationLevel Detailed

Replace port 443 if the service uses another port. Review the resolved destination, source interface and TcpTestSucceeded. A successful TCP connection does not validate TLS certificates, HTTP responses or user permissions. This test is for TCP, not proof that a UDP service works. See Test-NetConnection for its diagnostic modes.

If the hostname test fails because it resolves incorrectly, testing the expected IP can help isolate the transport path. That does not make browsing an HTTPS site by IP an equivalent application test, since hostname-based routing and certificate checks still matter.

Check the listener and the path

On the destination server, inspect the expected TCP listener:

Get-NetTCPConnection -State Listen |
    Select-Object LocalAddress, LocalPort, OwningProcess

Confirm that the application listens on the expected address and port. If it does, investigate the client route, network controls and the relevant Windows Firewall policy. ICMP ping can be blocked while the application port works, so a failed ping is not a complete connectivity diagnosis.

Preserve remote access while fixing the cause

Changing an address, disabling an adapter or resetting the stack can disconnect your administrative session. Arrange console access and a reversal plan before such a change. Keep the firewall enabled and adjust only the rule required by the authorised service and source network.

Record the failed query or port test, make the targeted correction, then repeat the same test from the same affected client. Finish by exercising the actual application: resolving a name and opening a socket are intermediate checks, not the whole user operation.