Gary VirkIT Specialist
← All work

01 IT support · PowerShell · Windows 11

Windows endpoint connectivity triage

A PowerShell diagnostic that distinguishes a DNS failure from a wider connectivity problem, then records the result for handoff.

Issue
A user says the network is down. Is the endpoint missing a usable path, or can it still reach the service directly while DNS fails?
Decisive evidence
During the DNS test, the service still answered on TCP 8443 by IP, while the hostname returned no record.E01
Result
Direct TCP still works while name resolution fails, narrowing the fault to DNS.
Boundary
This is a controlled Windows lab.Full limit
Completion
Complete within stated scope
Execution
Controlled Windows 11 ARM64 run
Review
Checklist-based technical review
Evidence
Selected evidence on this page
  • Windows 11 ARM64
  • PowerShell 7
  • Pester
  • UTM

What was built and checked.

Project record: The collector, fault classifications, controlled Windows scenarios, reviewed outputs, and public excerpts shown here.

Compare a DNS failure with a broken network path.

Switch between the two inserted faults and the retest. The highlighted checkpoint shows why the next action changes.

Choose a view

The route and direct service test pass, but the hostname returns no record.

  1. 01
    AdapterLink and endpoint address
  2. 02
    RouteGateway and service path
  3. 03
    DNSHostname lookup
  4. 04
    TCP 8443Direct service test

The same checks before and after the change.

  1. 01

    Capture the adapter, address, route, DNS server, gateway response, name resolution, and direct TCP result without changing the endpoint.

  2. 02

    Introduce one controlled fault outside the collector and repeat the same checks.

  3. 03

    Correct only the known fault, then run the full collection again.

  4. 04

    Start a fresh disposable session and confirm that the fault is absent before the final healthy check.

Direct TCP stayed up while the name check failed.

Scroll to compare

CheckFaultRetest
Adapter and IPAvailableAvailable
Direct service TCPAvailableAvailable
DNS nameNo answerA record returned
AssessmentDNSOnlyHealthy

The checks used to reach the conclusion.

Selected outputs from the lab. Sensitive and unnecessary details are omitted.

Test-NetConnection 192.0.2.10 -Port 8443
TcpTestSucceeded : True

Resolve-DnsName service.example.test
[no answer]

Assessment : Fail / DNSOnly
E01 · Captured lab outputDNS faultThe service port was reachable by IP while the lab hostname returned no answer. That separated DNS from the underlying TCP path.
Resolve-DnsName service.example.test
A  192.0.2.10

Test-NetConnection 192.0.2.10 -Port 8443
TcpTestSucceeded : True

Assessment : Pass / Healthy
E02 · Captured lab outputDNS correction and retestAfter the DNS server was restored, the same hostname returned the expected documentation address and the full assessment returned Healthy.
IPv4Address   : 198.51.100.20
DefaultGateway : 198.51.100.1
Gateway check  : Fail
TCP 8443       : False
Assessment     : Fail / NetworkPath
E03 · Captured lab outputWrong static networkThe endpoint moved to a different documentation subnet. Gateway, DNS, and direct TCP checks then failed together.
Full evidence archive2 additional artifacts
DNS-only rollback pre-check       : fault absent
Wrong-network rollback pre-check   : fault absent
Final assessment                   : Pass / Healthy
E04 · Captured lab outputFresh-session rollbackA new disposable session started without either inserted fault and returned a healthy assessment.
Symptom       : Service unavailable by name
Checks        : Adapter, IP, route, DNS, direct TCP
Finding       : TCP available; DNS lookup failed
Correction    : Restored reviewed DNS server
Retest        : Name and direct TCP checks passed
Scope         : Synthetic home-lab record
E05 · Explanatory aidSynthetic support recordThis concise handoff is based on the controlled lab. It is not an employer or customer ticket.

What changed, and what this lab does not prove.

Result

The DNS-only scenario kept direct TCP available while name resolution failed. The wrong-static-network scenario changed the address and route together and removed the usable path. Each correction produced a separate healthy retest.

Limit

This is a controlled Windows lab. It does not claim production execution, automatic remediation, or a native adapter-down recovery.

What the evidence supports.

During the DNS test, the service still answered on TCP 8443 by IP, while the hostname returned no record.

The test covers one controlled DNS-server fault.

EvidenceE01E02
With the test adapter on the wrong subnet, gateway, DNS, and direct TCP checks failed together.

The test covers one controlled static-address fault.

EvidenceE03E04