Windows Server 2025 / How to Troubleshoot IP, DNS, and DHCP Problems
Troubleshoot networking by separating IP configuration, routing, name resolution, and the actual service. Record the client’s current settings, compare with a known working case, and change only one relevant item before repeating the same test.
Define the failure and recent changes
Identify whether all clients fail, only one fails, names fail but addresses work, or one service fails. Record recent restarts, virtual switch changes, and DHCP option edits. Changing DNS and the firewall together hides which change mattered.
| Symptom | Initial direction |
|---|---|
| Both name and IP fail | Separate connectivity, addressing, service, and firewall checks |
| Only names fail | Resolver, record, suffix, and cache |
| One client has the wrong address | Manual settings, leases, and competing DHCP |
| Local subnet works, external access fails | Gateway, routing, NAT, and egress policy |
IP-based access can have different certificate or Kerberos requirements from named access. A diagnostic test is not necessarily a suitable permanent connection method.
Read the client’s actual configuration
ipconfig /all Get-NetIPConfiguration Get-NetAdapter Get-NetRoute -AddressFamily IPv4
Run at CLIENT1’s console. Record mask, DNS, DHCP server, and suffix as well as the IP. The lab expects a .100–.150 lease and DNS .10. A routerless isolated network can communicate within its subnet without a gateway.
A 169.254 address suggests lease acquisition failure without proving a broken DHCP server. Check switch, adapter state, and automatic client settings first. See DHCP client troubleshooting for relevant logs.
Separate reachability from service access
ping 172.24.50.10 Test-NetConnection -ComputerName 172.24.50.20 -Port 445
Ping tests ICMP replies; a blocked reply does not establish that every service is down. TCP 445 tests the SMB path only after FS1 provides that service, and does not verify share permissions.
For same-subnet failures, inspect VM power, switch, duplicate IPs, and masks. For external-only failure, inspect the actual gateway and NAT. Before testing another port, confirm a corresponding service is meant to listen.
Query a specific resolver and compare defaults
Resolve-DnsName 'fs1.lab.example.test' -Type A -Server 172.24.50.10 nslookup fs1.lab.example.test 172.24.50.10 Resolve-DnsName 'fs1.lab.example.test' -Type A
The first queries explicitly use DC1; the last uses the client’s configured resolution path. Direct success with default failure points toward client settings, policies, or cache. FQDN success with short-name failure suggests suffix handling.
Distinguish nonexistent-name responses from timeouts. Use client DNS checks alongside server-side zone and forwarding checks. Clear-DnsClientCache affects the local client; Clear-DnsServerCache affects the server. Neither repairs an incorrect authoritative record.
Check DHCP and repeat the original test
On the server, inspect service, active scope, available addresses, binding, and domain authorization. Clients across subnets may need a relay; do not add one unnecessarily to a single-switch lab.
Get-Service DHCPServer Get-DhcpServerv4Scope Get-DhcpServerv4ScopeStatistics -ScopeId 172.24.50.0 Get-DhcpServerv4Lease -ScopeId 172.24.50.0
Renew leases from the console. Record an original value, change one setting, and repeat the same failed name, IP, or port test while checking that normal functions remain intact. If unsuccessful, reverse only that change and retain the command, target, time, and error. Broad firewall disabling, indiscriminate cache clearing, and scope recreation make diagnosis and recovery harder.
