Choose the nearest symptom. The result gives evidence-led checks before any repair.
Safe firstWindows laptop · One device
Separate address, gateway, DNS and internet
For this scope: Compare with one known-good device in the same location. Record whether the fault follows the device or the user before making a change.
Record the laptop model, connection and exact error. Use an approved support account and compare with a known-good laptop.
If the active DHCP adapter has a 169.254 address, investigate address assignment.
Compare gateway reachability with a working device; a ping timeout can also mean ICMP is blocked.
If an IP responds but the corresponding name fails, investigate name resolution.
If everyone is affected, stop repairing the laptop and escalate the shared service.
Record the scope before changing anything. Ask whether the fault is wired, wireless or both; when it began; whether it is constant; and what changed shortly before it started.
One device
Check its connection, background synchronisation, patch lead and whether the problem follows it to another known-good location.
One room
Think access point, local cable path or switch port. Compare with a known-good device and record visible status—not a guessed repair.
One building
Think shared switch or uplink. Record rooms, sockets, times and the last change for the team or provider that owns the network.
Everyone
Check approved service-status sources, DNS and upstream dependencies. Use the incident route; do not experiment on the live core.
Could another service be filling the link?
CCTV, backups, virtual machines, mass updates, cloud synchronisation and hundreds of devices joining after assembly can all create a real slowdown without a failed component.
When should I stop?
VLAN changes, switch configuration, loop-protection settings and uplink capacity belong to the authorised network owner. If the site deteriorates rapidly, preserve the time and visible evidence, identify what changed, and escalate immediately. Do not unplug cables at random.
Worked guide · Windows school networks
Connected to Wi-Fi, but the lesson will not load.
Use a known-good comparison to separate a device fault from a shared service failure. These checks gather evidence; they do not change the network.
Updated 10 September 2026 · A practical expansion of book section 4.6
Ask two useful questions: “Does the same task work on another device here?” and “Does it work in another room?” Compare the same approved service at approximately the same time. A working homepage does not prove that the school’s learning platform, sign-in provider or assessment service is healthy.
Record wired or wireless, room, start time and the last known working lesson. If a class is waiting, agree a practical teaching workaround while the network owner investigates. A widespread interruption needs an incident owner and an update time.
2. Collect four pieces of evidence
On a Windows workstation, open Command Prompt and run the commands below. Replace <default-gateway> with the address shown for the active connection. Replace <school-service-hostname> with the hostname of an approved service, without https:// or a page path.
Read-only checks and their limits
Check
What to record
What it means
ipconfig /all
Active adapter, IPv4 address, DHCP, gateway and DNS servers
A 169.254.x.x address on a DHCP-configured adapter points towards failure to obtain an IPv4 lease. Check the active adapter, not a disconnected VPN or virtual adapter.
ping <default-gateway>
Replies or timeout; compare a working device
A reply supports local IP reachability. A timeout alone does not prove a broken gateway: ICMP may be blocked.
nslookup <school-service-hostname>
Resolver used, returned address or exact error
A failed lookup is a DNS lead. A successful lookup still does not prove that HTTPS, filtering or sign-in works.
Open the same approved service
Exact browser error and time
Compare the application result with network evidence. Keep certificate, proxy and authentication failures distinct.
3. Worked example: one room cannot reach the learning platform
Illustrative case, not a report from a customer. At 09:10, three wireless laptops in one room receive 169.254 addresses. A wired computer in that room works, and wireless devices elsewhere have normal leases. The evidence narrows the investigation to that room’s wireless path and address assignment; it does not establish that the access point itself has failed.
The technician records the affected devices, room, time and adapter details, then asks the network owner to examine the access point’s client information, the intended VLAN and DHCP path. The teaching workaround is agreed separately. A factory reset of all three laptops would discard time without testing the shared dependency.
After an authorised correction, check that a previously affected device receives the intended address, resolves the service and completes the teacher’s original task. Confirm a second affected device, record what changed and ask whether the classroom is working again.
4. Hand over an incident card
Impact: people, rooms and the teaching or business task affected.
Timeline: first failure, last known success and recent relevant changes.
Comparison: same task on a working device or connection.
Evidence: active adapter, address, gateway, DNS result and exact service error.
Actions: what was checked, what changed, by whom, and the result.
Next step: named owner, temporary workaround and time of the next update.
Keep internal addresses, device names and user information in the school’s approved ticket system. Share a redacted summary in public discussions.
