When troubleshooting a network problem, it’s important to follow the proper troubleshooting methodology before trying to fix something.

Methodology

First, identify clearly what the issue is. Be aware that users may not use terminology in the proper way – “we have no internet connection” doesn’t necessarily mean there’s an internet outage: this could also be caused by DNS failures, or DHCP scope exhaustion, and more – all of which would look like an internet outage. “I can’t start up my computer” would sound like a power/hardware issue, but if by that they mean that they can’t remote into a remote server that is very different from what they said. Therefore, it’s best to SEE what the issue precisely is, either by remoting into the PC or having the user read all errors off and walk through what they’re doing. It can also be important to verify if it’s just one user or all users/devices at a location.

Next, establish the probable theory of what’s wrong. If you can Ping an external IP but can’t Ping a domain name, it’s probably a DNS issue. If the device is getting an APIPA address (169.254.*.*), confirm that the network connection is good. Then check if the DHCP scope is exhausted – there just might not be any IP addresses left to lease to the device. If a user can’t log onto the PC because the domain isn’t available, check the network flow from the PC to the domain controller.

As an aside, I think it’s important to have a good mental map of the entire network flow. Give thought to the user’s inputs, and then consider the flow of data from start to finish and test each step. For a user who’s logged into a remote session and printing via port forwarding to a local printer, if the print is failing, you can immediately rule out an ISP outage – the user is still in the remote session. So consider the flow: Windows Print Spooler to the remote firewall, over the internet (either public or IPSec tunnel), to the local firewall, over the local network infrastructure, to the physical printer. Check if you can ping it locally. Can you send a test page locally? If so, then the issue is between the remote server and the local firewall. If you can’t, the issue is on the local network. Try a known-good cable and/or port. Confirm the printer is on.  The mental model of the packet flow is crucial to troubleshooting this.

(yes this is a common issue with our Tier-1 staff).

Finally, after resolving what seems to be the problem, test that it’s resolved. Aside from pings/etc., the best way is to actually confirm that the initial problem is now working. If so, you’re done. If not, you’ll then need to continue gathering information.

DOCUMENTATION!

Finally, perhaps the most crucial part – document your findings! In the simplest cases (a cord went bad, a connection was unplugged, the printer was offline), simply add a note to check that for the next user. That way something obvious won’t be repeatedly missed because someone thought it was TOO obvious – it’s important to remember that end users can be utterly confused by things that we take for granted within the industry – insider knowledge can lead to overlooking common issues AND create frustrated clients who may feel insulted or belittled or talked-down to. Adding a note to confirm those easy things – possibly even with a comment to the user of, “You may have already checked this, but can you confirm if…” can go a long way.

On the other hand, occasionally the problem is caused by something we’ve done wrong on our end in configuration – perhaps we set a DHCP reservation wrong (or forgot one), or we just have a fundamentally bad network design. In those cases, it’s important to document that as well so that, moving forward, the problems can be mitigated before they arise – and perhaps work can be done to clean up the technical debt of this potential problem lurking at other locations.

In my next post, I’ll give details on some specific common issues & how to resolve and test them.

(Yes, this entire post is written from hard-won experience…)