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
Project scope
What was built and checked.
Project record: The collector, fault classifications, controlled Windows scenarios, reviewed outputs, and public excerpts shown here.
Interactive view
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.
The route and direct service test pass, but the hostname returns no record.
- 01AdapterLink and endpoint addressnormal
- 02RouteGateway and service pathnormal
- 03DNSHostname lookupfailed
- 04TCP 8443Direct service testnormal
The changed address removes the usable route, so DNS and direct TCP fail with it.
- 01AdapterLink and endpoint addresschanged
- 02RouteGateway and service pathfailed
- 03DNSHostname lookupfailed
- 04TCP 8443Direct service testfailed
A fresh session starts on the expected network and all four checks pass.
- 01AdapterLink and endpoint addressnormal
- 02RouteGateway and service pathnormal
- 03DNSHostname lookupnormal
- 04TCP 8443Direct service testnormal
Troubleshooting record
The same checks before and after the change.
- 01
Capture the adapter, address, route, DNS server, gateway response, name resolution, and direct TCP result without changing the endpoint.
- 02
Introduce one controlled fault outside the collector and repeat the same checks.
- 03
Correct only the known fault, then run the full collection again.
- 04
Start a fresh disposable session and confirm that the fault is absent before the final healthy check.
DNS example
Direct TCP stayed up while the name check failed.
Scroll to compare
Evidence from the lab
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 / DNSOnlyResolve-DnsName service.example.test
A 192.0.2.10
Test-NetConnection 192.0.2.10 -Port 8443
TcpTestSucceeded : True
Assessment : Pass / HealthyIPv4Address : 198.51.100.20
DefaultGateway : 198.51.100.1
Gateway check : Fail
TCP 8443 : False
Assessment : Fail / NetworkPathFull evidence archive2 additional artifacts+
DNS-only rollback pre-check : fault absent
Wrong-network rollback pre-check : fault absent
Final assessment : Pass / HealthySymptom : 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 recordResult and limits
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.
Claims and evidence
What the evidence supports.
The test covers one controlled DNS-server fault.
EvidenceE01E02The test covers one controlled static-address fault.
EvidenceE03E04