Home/Toolchest

PowerShell server connectivity quick check

A read-only connectivity triage script that separates DNS, ping, RDP, WinRM, and application-port failures before escalation.

Good For

  • server outage triage
  • VPN path checks
  • RDP failures
  • WinRM reachability
  • application port testing

How to Use It

  1. Record the affected client network, VPN state, target hostname, and expected service ports before testing.
  2. Resolve each target name and compare the returned address with the expected internal address or load balancer endpoint.
  3. If DNS fails but the target works by IP, keep the problem in the DNS, suffix, split-tunnel, or conditional-forwarder lane.
  4. If DNS works but ping fails, compare firewall policy, ICMP filtering, and gateway reachability before treating the server as down.
  5. If ping works but a service port fails, focus on the listener, host firewall, service state, or network ACL for that port.
  6. Export or copy the object output into ticket notes so escalation has evidence instead of a generic unreachable report.

Execution Modes

  • local
  • remote-host-list

Inputs and Outputs

Inputs

  • target hostnames
  • CSV or TXT host list
  • expected service ports
  • known-good comparison host
  • client network path

Outputs

  • verbose-console
  • csv
  • future-html-report

Command Starter

Example pattern only. Adjust for your environment before running.

$Targets = @("server01.contoso.com")
$Ports = @(3389, 5985, 443)
foreach ($Target in $Targets) { $dns = Resolve-DnsName $Target -ErrorAction SilentlyContinue; $ping = Test-Connection $Target -Count 2 -Quiet; foreach ($Port in $Ports) { $tcp = Test-NetConnection $Target -Port $Port -InformationLevel Quiet; [pscustomobject]@{ Target = $Target; ResolvedAddress = ($dns.IPAddress -join ", "); Ping = $ping; Port = $Port; TcpOpen = $tcp } } }

Validation

  • Each target has a documented DNS result, ping result, and TCP result for every tested port.
  • The suspected failure domain is narrowed to name resolution, network path, service listener, firewall, or application layer.
  • A known-good target on the same path produces expected successful results for comparison.

Reporting

  • paste the result objects into the ticket timeline
  • export repeated checks to CSV when multiple servers or sites are involved
  • promote recurring incidents into an HTML connectivity report pack with pass/fail grouping

Safety Notes

  • This check only tests reachability and does not open firewall ports or restart services.
  • Avoid large port lists against production systems; test only the expected service ports for the incident.