Diagnose Network Issues Like a Pro

Run real diagnostics and build a network troubleshooting runbook.

Introduction

30 Second Summary

"I can't connect to the internet" is the most common help desk ticket in every organization. When that call comes in, knowing exactly which commands to run and what the output means is the difference between a quick fix and a frustrating escalation.

In this project, you will run five core network diagnostic commands on your own Windows PC, interpret their output, and assemble a professional troubleshooting runbook you can reference on your first day at a Service Desk.

What You'll Build

A structured network troubleshooting runbook built from live diagnostics on your own Windows PC, using the same commands and workflow that professional Service Desk analysts follow every day.

By the end of this project, you'll have:

  • A documented network configuration snapshot of your PC showing your IP address, gateway, and DNS servers.
  • Hands-on experience with the 5 core diagnostic commands (ipconfig, ping, tracert, nslookup, netstat) that Service Desk analysts use daily.
  • A reusable troubleshooting runbook with a step-by-step diagnostic checklist and a common-pattern reference for network issues.
  • Secret Mission: Investigate and clear a DNS cache issue using advanced ipconfig switches.

Are there any prerequisites?

None. Every tool you need is already built into Windows. You just need a Windows PC with access to Command Prompt and Notepad.

Inspect Your Network Configuration

Before you can diagnose network problems for users, you need to know what a healthy configuration looks like on your own machine.

In this step, you will run the ipconfig command to inspect how your PC connects to the network and record the key values that define your connection in a Notepad document.

In this step, get ready to:
  • Run ipconfig and record your core network values.
  • Run ipconfig /all for the complete configuration details.
  • Check whether your IP address indicates a DHCP failure.
Open Command Prompt and run ipconfig

The ipconfig command displays your PC's current network configuration. It shows the three values that define how your computer connects: its address, its network boundaries, and its exit point to the internet.

  • Press the Windows key to open your search bar.
  • Type cmd and press Enter to open Command Prompt.

A black window appears with a blinking cursor. This is Command Prompt, the text-based tool where you will run all your diagnostic commands.

  • View your network configuration by running this command:
ipconfig

What does this command do?

The ipconfig command displays all current TCP/IP network configuration values and refreshes DHCP and DNS settings.

Without any parameters, it shows your IPv4 address, subnet mask, and default gateway for all adapters.

You should see output with a section labeled something like Wireless LAN adapter Wi-Fi or Ethernet adapter Ethernet depending on your connection type.

  • Find these three values in the output under your active adapter:
  • IPv4 Address (your PC's unique address on the network, e.g. 192.168.1.105).
  • Subnet Mask (defines which addresses are on your local network, e.g. 255.255.255.0).
  • Default Gateway (your router's address, the exit point to the internet, e.g. 192.168.1.1).

What do these values mean?

Your IPv4 Address is like your PC's home address on the network. No other device on your local network shares this number.

The Subnet Mask tells your PC which other devices are neighbours (on the same network) versus strangers (on a different network that requires a router to reach).

The Default Gateway is your router. Any traffic heading to the internet passes through this device first.

  • Press the Windows key to open your search bar.
  • Type Notepad and press Enter to open it.
  • At the top of the blank document, type the heading My Network Configuration followed by a line of dashes for separation.
  • Record your three values on separate lines, labeling each one clearly: IPv4 Address, Subnet Mask, and Default Gateway.

Which adapter section do I look at?

If you see multiple adapter sections, look for the one with a real IPv4 address (like 192.168.x.x or 10.x.x.x). Ignore sections that show Media disconnected since those adapters are not active.

Not seeing any IPv4 address?

Make sure your Wi-Fi is connected or your Ethernet cable is plugged in. If you see only IPv6 addresses (long strings with colons), your network adapter may not be receiving an IPv4 address from your router.

Try disconnecting and reconnecting your Wi-Fi, then run ipconfig again.

Help me figure out why ipconfig is not showing an IPv4 address.

View full configuration with ipconfig /all

The basic ipconfig output only shows the essentials. The /all flag reveals the full picture, including which DNS servers your PC uses, whether your address was assigned automatically, and your adapter's hardware address.

  • View the complete network configuration by running this command:
ipconfig /all

What does ipconfig /all show?

The /all flag displays the full TCP/IP configuration for all adapters, including physical interfaces like your Wi-Fi card and logical interfaces like VPN connections.

This extended output includes your DNS Servers (which translate website names to IP addresses), your DHCP Server (which assigned your IP address), and your Physical Address (your adapter's unique hardware identifier, also called a MAC address).

You should see a much longer output now. Scroll through it and find the same adapter section you identified earlier.

  • Locate and record these additional values in your Notepad document:
  • DNS Servers (one or more IP addresses, e.g. 8.8.8.8).
  • DHCP Server (the IP of the server that assigned your address).
  • Physical Address (your MAC address, formatted like 00-0D-3A-E5-1C-C0).
  • Find the line that says DHCP Enabled and record whether it shows Yes or No.

Why does DHCP Enabled matter?

If DHCP Enabled says Yes, your IP was assigned automatically by a DHCP server (usually your router). This is the most common setup for home and office networks.

If it says No, someone manually configured a static IP on this machine. This is useful to know when troubleshooting because it changes which fixes apply.

Cannot find DNS Servers or DHCP Server?

Make sure you are looking at the correct adapter section (the one with your IPv4 address from earlier). Some adapters like Bluetooth or virtual adapters may not show these fields.

Scroll slowly through the output. The DNS Servers field sometimes appears with multiple addresses on separate lines indented below it.

Help me find the DNS and DHCP values in my ipconfig /all output.

Check for APIPA indicator

There is one more thing to check in your configuration. If your PC failed to get an address from DHCP, Windows automatically assigns itself an address in the 169.254.x.x range. This is called APIPA (Automatic Private IP Addressing).

  • Look at the IPv4 Address you recorded earlier.
  • Check whether it starts with 169.254.
  • In your Notepad document, add a line labeled APIPA Check and record either Normal (if your address does NOT start with 169.254) or 169.254.x.x detected (if it does).

What is APIPA?

When a Windows PC cannot reach a DHCP server, it assigns itself an address in the 169.254.0.0/16 range. This is a self-assigned fallback that only allows communication with other devices on the same physical network segment.

Recognizing this pattern immediately tells a Service Desk analyst that the problem is a DHCP failure, not a cable issue or DNS problem. It is a common interview question too.

Seeing a 169.254 address?

This means your PC could not reach a DHCP server. Check that your router is powered on and that your connection (Wi-Fi or Ethernet) is active.

You can still continue this project. Record the finding and know that this is exactly the kind of issue a Service Desk analyst would investigate.

Help me understand why my PC has a 169.254 address.

✔️ Awesome, I've got everything!

Great. Double check that your Notepad document has all seven fields filled in, then save it.

ⓧ I'd like to double check the full code

Your Notepad document should have this structure (with your own values filled in):

My Network Configuration
------------------------
IPv4 Address: [[IPV4_ADDRESS="your IPv4 address from ipconfig"]]
Subnet Mask: [[SUBNET_MASK="your subnet mask from ipconfig"]]
Default Gateway: [[DEFAULT_GATEWAY="your default gateway from ipconfig"]]
DNS Servers: [[DNS_SERVERS="your DNS server addresses from ipconfig /all"]]
DHCP Server: [[DHCP_SERVER="your DHCP server address from ipconfig /all"]]
Physical Address (MAC): [[MAC_ADDRESS="your physical address from ipconfig /all"]]
DHCP Enabled: [[DHCP_STATUS="Yes or No"]]
APIPA Check: [[APIPA_RESULT="Normal or 169.254.x.x detected"]]
  • Save your Notepad file by pressing Ctrl+S.
  • In the Save As dialog, navigate to your Desktop.
  • Name the file Network-Troubleshooting-Runbook.txt and click Save.

You now have a documented baseline of your network configuration. Next up, you will use ping to test connectivity at each layer and pinpoint exactly where a problem would live.

Test Connectivity Layer by Layer

You now have a snapshot of your network configuration recorded in your runbook. The next question is whether that configuration is actually working.

In this step, you will use the ping command to test connectivity at three different layers: local network, internet by IP, and internet by hostname. This layered approach lets you pinpoint exactly where a connection breaks down.

In this step, get ready to:
  • Ping your default gateway to test local network connectivity.
  • Ping an external IP and hostname to test internet and DNS resolution.
  • Document your results in a structured format that isolates failure layers.
Ping your default gateway

The first connectivity test checks whether your PC can talk to your local router. Your default gateway is the door between your local network and the internet.

If this ping fails, nothing beyond your local network will work either.

  • In your Command Prompt, ping your default gateway by running this command (replace the IP with the Default Gateway you recorded in Step 1):
ping [[GATEWAY_IP="your Default Gateway IP, e.g. 192.168.1.1"]]

You should see four lines that each start with Reply from followed by a time in milliseconds. For a local gateway, the time is typically under 5ms.

What does the output tell you?

Each Reply from... line confirms your PC successfully sent a packet to your router and received a response. The time= value is the round-trip time in milliseconds.

If you see Request timed out. instead, the packet never came back. This points to a local network issue like a disconnected cable or a misconfigured router.

  • Note whether you received replies or timeouts, and write down the round-trip time from one of the reply lines.

Not getting replies from your gateway?

Make sure you typed the exact IP address from your Default Gateway value in Step 1. A single digit off will ping the wrong device.

If your gateway IP is correct and you still see timeouts, check that your Wi-Fi is connected or your Ethernet cable is plugged in. Some routers also block ICMP requests by default.

help me troubleshoot why my ping to the default gateway is timing out

Ping an external IP and a hostname

Now test whether your traffic can get past your router and reach the internet. You will run two separate pings that, when compared, reveal whether a failure is a network problem or a DNS problem.

  • Test internet connectivity by pinging Google's public DNS server:
ping 8.8.8.8

You should see four reply lines, similar to your gateway ping. The round-trip time will be higher (typically 10-50ms) since the packet is traveling across the internet.

  • Now test DNS resolution by pinging a hostname:
ping www.google.com

If this succeeds, you should see replies from an IP address that your PC resolved from the hostname www.google.com.

How does this isolate DNS issues?

If ping 8.8.8.8 succeeds but ping www.google.com fails, your internet connection is fine. The problem is that your PC cannot translate hostnames into IP addresses. That is a DNS issue, not a connectivity issue.

If both pings fail, the problem is upstream. Your traffic is not reaching the internet at all, which means the issue is between your router and your ISP.

  • Note whether each ping returned replies or timed out, and record the round-trip times.

Both external pings timing out?

If your gateway ping succeeded but both external pings fail, your router may not be forwarding traffic to the internet. Try restarting your router or checking if your ISP is experiencing an outage.

Some corporate or school networks block outbound pings. If you are on a managed network, try pinging 1.1.1.1 (Cloudflare DNS) as an alternative.

help me figure out why external pings fail when my gateway ping works

Document your connectivity test results

Now that you have results from all three pings, add a structured section to your runbook. This three-layer test format is exactly how Service Desk analysts isolate where a problem lives.

  • Switch back to your Notepad file.
  • Below your "My Network Configuration" section, add the following (filling in your own results from each ping test):
Connectivity Test Results
-------------------------
Gateway ping (ping [[GATEWAY_IP="your Default Gateway IP, e.g. 192.168.1.1"]]): [[GATEWAY_RESULT="Replies or Request timed out"]] - RTT: [[GATEWAY_RTT="round-trip time, e.g. 2ms"]]  
Internet by IP (ping 8.8.8.8): [[IP_RESULT="Replies or Request timed out"]] - RTT: [[IP_RTT="round-trip time, e.g. 25ms"]]
Internet by hostname (ping www.google.com): [[HOSTNAME_RESULT="Replies or Request timed out"]] - RTT: [[HOSTNAME_RTT="round-trip time, e.g. 30ms"]]
Can I reach my gateway? [[GATEWAY_ANSWER="Yes or No"]]
Can I reach the internet by IP? [[IP_ANSWER="Yes or No"]]
Can I reach the internet by hostname? [[HOSTNAME_ANSWER="Yes or No"]]

Why document Yes/No answers separately?

The three Yes/No questions at the bottom create a quick-reference diagnostic pattern. When you get a connectivity ticket on the Service Desk, you can run these three pings and immediately narrow the problem to one of three layers.

  • Gateway No = local network or cable issue.
  • Gateway Yes, IP No = router or ISP issue.
  • Gateway Yes, IP Yes, Hostname No = DNS issue.
  • Save your file in Notepad by pressing Ctrl+S.

✔️ Awesome, I've got everything!

Great. Double check you have saved your file with Ctrl+S.

ⓧ I'd like to double check the full file

Your full Network-Troubleshooting-Runbook.txt file should now look like this (with your own values filled in):

My Network Configuration
------------------------
IPv4 Address: [[IPV4="your IPv4 address"]]
Subnet Mask: [[SUBNET="your subnet mask"]]
Default Gateway: [[GATEWAY_IP="your Default Gateway IP, e.g. 192.168.1.1"]]
DNS Servers: [[DNS_SERVERS="your DNS server addresses"]]
DHCP Server: [[DHCP_SERVER="your DHCP server address"]]
Physical Address (MAC): [[MAC_ADDRESS="your MAC address"]]
DHCP Enabled: [[DHCP_ENABLED="Yes or No"]]
APIPA Check: [[APIPA_STATUS="Normal or 169.254.x.x detected"]]

Connectivity Test Results
-------------------------
Gateway ping (ping [[GATEWAY_IP="your Default Gateway IP, e.g. 192.168.1.1"]]): [[GATEWAY_RESULT="Replies or Request timed out"]] - RTT: [[GATEWAY_RTT="round-trip time, e.g. 2ms"]]
Internet by IP (ping 8.8.8.8): [[IP_RESULT="Replies or Request timed out"]] - RTT: [[IP_RTT="round-trip time, e.g. 25ms"]]
Internet by hostname (ping www.google.com): [[HOSTNAME_RESULT="Replies or Request timed out"]] - RTT: [[HOSTNAME_RTT="round-trip time, e.g. 30ms"]]
Can I reach my gateway? [[GATEWAY_ANSWER="Yes or No"]]
Can I reach the internet by IP? [[IP_ANSWER="Yes or No"]]
Can I reach the internet by hostname? [[HOSTNAME_ANSWER="Yes or No"]]

You now have a documented method for isolating connectivity failures layer by layer. Next up, you will trace the exact path your traffic takes across the internet and verify that DNS is resolving correctly.

Trace Your Traffic Path and Verify DNS

In the previous step, you used ping to test connectivity at three layers: local gateway, internet by IP, and internet by hostname.

Now you know whether your connection works, but you don't know where a problem lives when things go wrong.

In this step, you will trace the exact path your traffic takes across the internet and verify that your DNS server is resolving hostnames correctly.

In this step, get ready to:
  • Trace your traffic path to microsoft.com and identify each hop along the route.
  • Query your DNS server directly to verify hostname resolution.
  • Document your route trace and DNS findings in your runbook.
Trace your route to microsoft.com

When your traffic travels to a website, it passes through multiple routers along the way.

The tracert command reveals each of these routers (called "hops") so you can pinpoint exactly where a delay or failure occurs.

  • In your Command Prompt, trace the route to microsoft.com by running this command:
tracert www.microsoft.com

What does this command do?

tracert sends packets with incrementally increasing Time To Live (TTL) values to discover each router between your PC and the destination.

Each numbered line in the output is one hop. The first hop is your local gateway. The maximum number of hops is 30 by default.

This command takes a while

tracert can take 30 to 60 seconds to complete because it waits for a response from each hop. Let it finish before moving on.

Once the command finishes, you will see a numbered list of hops, each showing three round-trip time measurements and an IP address or hostname.

  • Look at hop 1. This should be your default gateway (the IP you recorded in Step 1).
  • Scan down the list and note any hops where the round-trip times jump significantly higher.
  • Look for lines showing asterisks (*) instead of times.
  • Note the final hop number to get your total hop count.

What do asterisks (*) mean?

Some routers do not return Time Exceeded messages for packets with expired TTL values and are invisible to the tracert command. In this case, a row of asterisks (*) is displayed for that hop.

This is normal. It does not necessarily mean the hop is broken. It just means that particular router chose not to respond.

Tracert seems stuck or is taking forever?

If you see several consecutive rows of asterisks and the command appears frozen, it may be waiting for responses that will never come. Press Ctrl+C to cancel and use whatever output you already have.

Some corporate or school firewalls block ICMP packets, which prevents tracert from completing. If you hit this, record what you got and move on.

Help me understand why my tracert command is not completing

Query DNS directly with nslookup

The nslookup command queries your DNS server directly to resolve a hostname into an IP address.

This is useful because nslookup does not use your PC's DNS cache. It goes straight to the DNS server, giving you a fresh answer every time.

  • Query your DNS server for google.com by running this command:
nslookup www.google.com

What should I see?

The output has two sections. At the top, "Server" and "Address" show which DNS server answered your query. This should match the DNS server you recorded in Step 1.

Below that, "Name" and "Addresses" show the IP address(es) that the hostname resolves to. This is the actual server IP your browser would connect to.

  • Now query DNS for microsoft.com by running:
nslookup www.microsoft.com
  • Note the DNS server name and IP from the top of each output.
  • Note the IP address(es) returned for each hostname.

Why is this useful on a Service Desk?

If a user reports "I can't reach the website" and your ping to an IP works but nslookup fails, the problem is DNS configuration, not network connectivity.

This distinction changes your troubleshooting path completely. A DNS problem means checking DNS server settings, not replacing network cables.

Seeing 'DNS request timed out'?

This means your configured DNS server did not respond. Check that you have internet connectivity by running ping 8.8.8.8 first. If that works, your DNS server may be temporarily unavailable.

Help me troubleshoot why nslookup is timing out

Document your route trace and DNS results

This information is what you would paste into a support ticket when escalating a network issue to a senior engineer.

  • Switch back to your Notepad file.
  • Below your "Connectivity Test Results" section, add a new section heading by typing:
Route Trace and DNS
-------------------
  • Under that heading, document your tracert results using this format:
tracert www.microsoft.com:
  Total hops: [number]
  First hop (gateway): [IP]
  Notable latency or asterisks: [observations]
  • Replace each bracketed placeholder with the actual values from your Command Prompt output.
  • Now document both nslookup results using this format:
nslookup www.google.com:
  DNS Server answered: [server name and IP]
  IP returned: [IP address]
nslookup www.microsoft.com:
  DNS Server answered: [server name and IP]
  IP returned: [IP address]
  • Replace each bracketed placeholder with the values from your nslookup output.
  • Save your file by pressing Ctrl+S.

✔️ Awesome, I've got everything!

Great. Double check you have saved your file with all three sections: "My Network Configuration", "Connectivity Test Results", and "Route Trace and DNS".

ⓧ I'd like to double check the full file

Your Notepad file should now look like this (with your own values filled in):

My Network Configuration
------------------------
IPv4 Address: [recorded value]
Subnet Mask: [recorded value]
Default Gateway: [recorded value]
DNS Servers: [recorded value]
DHCP Server: [recorded value]
Physical Address (MAC): [recorded value]
DHCP Enabled: [Yes/No]
APIPА Check: [Normal / 169.254.x.x detected]

Connectivity Test Results
-------------------------
Gateway ping (ping [gateway IP]): [Replies / Request timed out] - RTT: [ms]
Internet by IP (ping 8.8.8.8): [Replies / Request timed out] - RTT: [ms]
Internet by hostname (ping www.google.com): [Replies / Request timed out] - RTT: [ms]
Can I reach my gateway? [Yes/No]
Can I reach the internet by IP? [Yes/No]
Can I reach the internet by hostname? [Yes/No]

Route Trace and DNS
-------------------
tracert www.microsoft.com:
  Total hops: [number]
  First hop (gateway): [IP]
  Notable latency or asterisks: [observations]
nslookup www.google.com:
  DNS Server answered: [server name and IP]
  IP returned: [IP address]
nslookup www.microsoft.com:
  DNS Server answered: [server name and IP]
  IP returned: [IP address]

You now know how to trace exactly where traffic goes and verify that DNS is doing its job. Next up, you will audit the active connections on your PC to see which applications are talking to the network right now.

Audit Active Connections on Your PC

You now have a clear picture of your network path and DNS resolution from the previous step.

When a user reports "my app can't connect to the server," the first question is whether the connection is even being attempted. In this step, you will use netstat to see every active network connection on your PC and match connections to the applications that own them.

In this step, get ready to:
  • View all active connections and listening ports with netstat.
  • Match a network connection to a running application using PIDs.
  • Document your findings in the Active Connections Audit section of your runbook.
View all active connections and listening ports

Your PC is constantly maintaining network connections in the background. The netstat command displays active TCP connections, ports on which the computer is listening, and UDP activity.

  • In your Command Prompt, view all connections and listening ports by running this command:
netstat -a

You should see a table with four columns: Proto, Local Address, Foreign Address, and State.

What do the State values mean?

ESTABLISHED means your PC has an active, ongoing connection to another computer. This is what you see when your browser is communicating with a web server.

LISTENING means a service on your PC is waiting for incoming connections. This is like a phone on the hook, ready to receive a call.

  • Scroll through the output and count how many entries show ESTABLISHED in the State column.
  • Note this number. You will record it in your runbook shortly.

Output scrolled by too fast?

If you have many connections and cannot scroll back far enough, try scrolling up in Command Prompt by holding Shift and using the scroll wheel on your mouse.

help me see all my netstat output without losing lines

Match a connection to its application using PIDs

Knowing a connection exists is useful, but knowing which application owns it is where real troubleshooting power comes from. Adding the -o flag to netstat displays the process ID (PID) for each connection.

  • View connections with numeric addresses and process IDs by running this command:
netstat -n -o

What do the -n and -o flags do?

  • -n displays addresses and port numbers as raw numbers instead of resolving them to hostnames. This makes the output faster and easier to read.
  • -o adds a PID column. The PID is a unique number that identifies which running program owns that connection.
  • Find one row with the state ESTABLISHED and note the number in the PID column on the far right.
  • Open Task Manager by pressing Ctrl+Shift+Esc.
  • Click the Details tab at the top of Task Manager.
  • Look for the PID number you noted from the netstat output in the PID column.
  • Read the Name column on the same row to identify which application owns that connection.

You should now see an application name (like chrome.exe, msedge.exe, or Teams.exe) matched to the network connection.

Why is this useful on a Service Desk?

When a user says "Outlook won't connect to the server," you can run netstat -n -o and check whether Outlook's process has an ESTABLISHED connection or no connection at all.

No connection means a network or firewall issue. An ESTABLISHED connection to the wrong port means misconfiguration. This skill turns a vague report into a specific diagnosis.

Can't find the PID in Task Manager?

Make sure you are on the Details tab, not the Processes tab. The Details tab always shows PIDs by default.

If the PID disappeared, the connection may have closed between running netstat and checking Task Manager. Run netstat -n -o again and pick a fresh ESTABLISHED row.

help me match a PID from netstat to a process in Task Manager

Document your active connections audit

Now that you have explored your connections and matched one to an application, it is time to record everything in your runbook.

  • Switch back to your Network-Troubleshooting-Runbook.txt file in Notepad.
  • Below your "Route Trace and DNS" section, add the following new section with your own values filled in:
Active Connections Audit
------------------------
Total ESTABLISHED connections: [number]
Identified application from PID lookup: [app name] (PID: [number])
Common ports observed: [list, e.g. 443 = HTTPS, 80 = HTTP, 53 = DNS]
State definitions:
  ESTABLISHED = active connection in progress
  LISTENING = service waiting for incoming connections

What are common ports to look for?

  • 443 = HTTPS (secure web traffic). This is the most common port you will see.
  • 80 = HTTP (unencrypted web traffic).
  • 53 = DNS (name resolution queries).

Check your netstat output for these port numbers in the Local Address or Foreign Address columns (they appear after the colon, like 192.168.1.5:443).

  • Replace each bracketed placeholder with the real values from your netstat output and Task Manager lookup.
  • Save your file by pressing Ctrl+S.

✔️ Awesome, I've got everything!

Great. Double check that you have saved your file and that the Active Connections Audit section has all five lines filled in.

ⓧ I'd like to double check the full file

Here is what your full runbook file should look like by now. Your actual values will differ, but the structure should match:

My Network Configuration
------------------------
IPv4 Address: [recorded value]
Subnet Mask: [recorded value]
Default Gateway: [recorded value]
DNS Servers: [recorded value]
DHCP Server: [recorded value]
Physical Address (MAC): [recorded value]
DHCP Enabled: [Yes/No]
APIPА Check: [Normal / 169.254.x.x detected]

Connectivity Test Results
-------------------------
Gateway ping (ping [gateway IP]): [Replies / Request timed out] - RTT: [ms]
Internet by IP (ping 8.8.8.8): [Replies / Request timed out] - RTT: [ms]
Internet by hostname (ping www.google.com): [Replies / Request timed out] - RTT: [ms]
Can I reach my gateway? [Yes/No]
Can I reach the internet by IP? [Yes/No]
Can I reach the internet by hostname? [Yes/No]

Route Trace and DNS
-------------------
tracert www.microsoft.com:
  Total hops: [number]
  First hop (gateway): [IP]
  Notable latency or asterisks: [observations]
nslookup www.google.com:
  DNS Server answered: [server name and IP]
  IP returned: [IP address]
nslookup www.microsoft.com:
  DNS Server answered: [server name and IP]
  IP returned: [IP address]

Active Connections Audit
------------------------
Total ESTABLISHED connections: [number]
Identified application from PID lookup: [app name] (PID: [number])
Common ports observed: [list, e.g. 443 = HTTPS, 80 = HTTP, 53 = DNS]
State definitions:
  ESTABLISHED = active connection in progress
  LISTENING = service waiting for incoming connections

You now have visibility into what your PC is doing on the network at any given moment. Next up, you will pull everything together into a professional troubleshooting runbook you can reference on Day 1 of your Service Desk role.

Assemble Your Troubleshooting Runbook

You now have a Notepad file full of real diagnostic data from your own PC. You know your IP configuration, connectivity results, route trace, and active connections.

In this step, you will transform those raw findings into a professional troubleshooting runbook. This is the structured reference document that Service Desk analysts keep in their knowledge base so they can diagnose common ticket types quickly and consistently.

In this step, get ready to:
  • Write a 7-step diagnostic checklist that captures the structured workflow you performed.
  • Document common network problem patterns and what each one means.
  • Save your completed runbook file for Day 1 reference.
Create your diagnostic checklist

A diagnostic checklist captures the exact sequence of commands you run when a user reports a connectivity issue. It prevents you from skipping steps or jumping ahead when a ticket is stressful.

  • Switch back to your Network-Troubleshooting-Runbook.txt file in Notepad.
  • Place your cursor at the very top of the file (press Ctrl+Home to jump to the beginning).
  • Press Enter several times to push your existing content down, then move your cursor back to line 1.
  • Type the following diagnostic checklist at the top of the file:
Service Desk Network Troubleshooting Runbook
============================================
Diagnostic Checklist:
1. Check IP configuration with ipconfig /all
2. Ping gateway to test local connectivity
3. Ping external IP (8.8.8.8) to test internet
4. Ping hostname (www.google.com) to test DNS
5. Run tracert if slow/intermittent
6. Run nslookup if DNS suspected
7. Run netstat if application-specific

Why this order matters

This checklist follows an inside-out approach. You start at your own PC (step 1), test the local network (step 2), then expand outward to the internet (steps 3-4), and finally investigate specific paths or applications (steps 5-7).

By working from the inside out, you isolate the exact layer where a problem lives. If step 2 fails, you know the issue is local and you never need to reach steps 3-7.

Document common network problem patterns

Knowing which commands to run is only half the skill. The other half is recognizing what the output means. These four patterns cover the most common network issues that land on a Service Desk queue.

  • Directly below your diagnostic checklist (leave one blank line), type the following section:
Common Findings and What They Mean
-----------------------------------
a. 169.254.x.x address = DHCP failure (PC could not get an IP from the router)
b. Gateway ping fails = local network or cable issue
c. IP ping works but hostname ping fails = DNS problem
d. Tracert shows timeouts at hop 1 = router issue

What do these patterns mean?

  • Pattern (a): A 169.254.x.x address means the PC tried to get an IP from DHCP and failed. This is called APIPA. It usually means a cable is unplugged or the router is down.
  • Pattern (b): If ping to the default gateway fails, the PC cannot reach the router at all. Check physical connections first.
  • Pattern (c): If pinging an IP works but pinging a hostname fails, the network path is fine. The problem is DNS resolution specifically.
  • Pattern (d): If tracert shows asterisks at hop 1, your local router is not responding. This is different from timeouts deeper in the path, which indicate issues beyond your network.
Save your completed runbook

Your file now has everything a Service Desk analyst needs: a structured workflow at the top and a quick-reference pattern guide below it, followed by your real diagnostic data as a worked example.

  • Press Ctrl+S to save your file.
  • Scroll through the entire file to confirm your new sections appear at the top, above your existing "My Network Configuration" section.

You should see the "Service Desk Network Troubleshooting Runbook" heading and diagnostic checklist at the very top, followed by "Common Findings and What They Mean," and then all of your recorded data from the previous steps below.

What is a runbook?

Professional Service Desk teams maintain runbooks in their knowledge base for every common issue type. When a new ticket arrives, the analyst pulls up the matching runbook and follows it step by step.

This consistency is what separates a reactive "try random things" approach from a structured diagnostic methodology. Your file is now a real runbook you can bring to your first day.

File not saving?

If Notepad shows an error when saving, make sure you are not trying to save to a restricted location like C:\Windows. Save to your Desktop or Documents folder instead.

If your new sections appear at the bottom instead of the top, use Ctrl+A to select all text, cut it, then paste it back in the correct order with the runbook heading first.

Need more help? Help me fix my Notepad file order

✔️ Awesome, I've got everything!

Great. Double check that you have saved your file and that the diagnostic checklist appears at the very top.

ⓧ I'd like to double check the full code

Here is what your complete Network-Troubleshooting-Runbook.txt file should look like from top to bottom. Your recorded values will differ from the placeholders shown here.

Service Desk Network Troubleshooting Runbook
============================================
Diagnostic Checklist:
1. Check IP configuration with ipconfig /all
2. Ping gateway to test local connectivity
3. Ping external IP (8.8.8.8) to test internet
4. Ping hostname (www.google.com) to test DNS
5. Run tracert if slow/intermittent
6. Run nslookup if DNS suspected
7. Run netstat if application-specific

Common Findings and What They Mean
-----------------------------------
a. 169.254.x.x address = DHCP failure (PC could not get an IP from the router)
b. Gateway ping fails = local network or cable issue
c. IP ping works but hostname ping fails = DNS problem
d. Tracert shows timeouts at hop 1 = router issue

My Network Configuration
------------------------
IPv4 Address: [recorded value]
Subnet Mask: [recorded value]
Default Gateway: [recorded value]
DNS Servers: [recorded value]
DHCP Server: [recorded value]
Physical Address (MAC): [recorded value]
DHCP Enabled: [Yes/No]
APIPA Check: [Normal / 169.254.x.x detected]

Connectivity Test Results
-------------------------
Gateway ping (ping [gateway IP]): [Replies / Request timed out] - RTT: [ms]
Internet by IP (ping 8.8.8.8): [Replies / Request timed out] - RTT: [ms]
Internet by hostname (ping www.google.com): [Replies / Request timed out] - RTT: [ms]
Can I reach my gateway? [Yes/No]
Can I reach the internet by IP? [Yes/No]
Can I reach the internet by hostname? [Yes/No]

Route Trace and DNS
-------------------
tracert www.microsoft.com:
  Total hops: [number]
  First hop (gateway): [IP]
  Notable latency or asterisks: [observations]
nslookup www.google.com:
  DNS Server answered: [server name and IP]
  IP returned: [IP address]
nslookup www.microsoft.com:
  DNS Server answered: [server name and IP]
  IP returned: [IP address]

Active Connections Audit
------------------------
Total ESTABLISHED connections: [number]
Identified application from PID lookup: [app name] (PID: [number])
Common ports observed: [list]
State definitions:
  ESTABLISHED = active connection in progress
  LISTENING = service waiting for incoming connections

Secret mission

Investigate and Clear a DNS Cache Issue

When a website moves to a new server, your PC might still try to reach the old address. In this mission, you will investigate your DNS resolver cache, clear stale entries, and observe how fresh lookups repopulate it. This is a real-world fix Service Desk analysts use when a user says a site works for everyone else but not for them.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

This project runs entirely locally using built-in Windows tools, so there are no ongoing costs and nothing that needs to be shut down.

Resources you used:

  • One local text file: Network-Troubleshooting-Runbook.txt saved on your PC.

Keep everything running

No action needed. Choose this if you want your runbook available for reference on your first day at a Service Desk job.

  • Your Network-Troubleshooting-Runbook.txt file stays wherever you saved it.
  • No cloud resources, subscriptions, or background processes were created during this project.
  • The diagnostic commands you ran (ipconfig, ping, tracert, nslookup, netstat) are built into Windows and were read-only. They made no permanent changes to your system.

Pause - I'll come back to this later

There is nothing to pause. Your runbook is a static text file with no running processes or active connections.

  • Close Command Prompt if it is still open.
  • Close Notepad if it is still open.
  • Your Network-Troubleshooting-Runbook.txt file will be right where you left it when you come back.

Delete - I don't want to use this again

Remove the runbook file you created during this project.

  • Open File Explorer and navigate to the folder where you saved Network-Troubleshooting-Runbook.txt.
  • Right-click the file and select Delete.
  • Empty your Recycle Bin if you want the file fully removed.
  • No tools were installed during this project. All commands used (ipconfig, ping, tracert, nslookup, netstat) are built into Windows and cannot be removed.

Nice Work!

Nice Work!

You just diagnosed your own network using the same five commands that Service Desk analysts rely on every single day. Even better, you built a professional troubleshooting runbook you can reference on your first day at work.

Here's what you accomplished:

  • Ran the 5 core diagnostic commands (ipconfig, ping, tracert, nslookup, netstat) to inspect your network configuration and test connectivity at every layer.
  • Isolated failures using a structured layer-by-layer methodology that distinguishes local network issues from internet issues from DNS problems.
  • Assembled a professional troubleshooting runbook with a diagnostic checklist and common-pattern reference ready for your first Service Desk role.
  • Secret Mission: Investigated and cleared a DNS cache issue using ipconfig /displaydns and ipconfig /flushdns.

Ready to quiz yourself?