Troubleshoot a Windows Network Incident

Diagnose a Windows network issue and document an evidence-based support ticket.

Introduction

30 Second Summary

One unreachable destination can make an entire Wi-Fi connection look broken. Good support work gathers evidence before anyone changes a setting.

In this project, you will diagnose a simulated help desk incident on Microsoft Windows. You will turn Command Prompt evidence about local connectivity and DNS name resolution into a complete ticket in Notepad.

What You'll Build

You will reopen a polished support ticket that shows exactly why one destination failed and whether the wider network needs escalation.

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

A repeatable troubleshooting record that starts with the user's report and follows the evidence through to a diagnosis.
A visible comparison of network tests that distinguishes healthy local connectivity from a name-resolution failure.
A plain-language resolution or escalation message that explains the next action without unsupported claims.
Secret Mission: Add an annotated route trace that shows how traffic crosses multiple network hops.

Are there any prerequisites?

You need a Windows PC with Command Prompt plus Notepad. No previous IT experience or internet connection is required because the project includes an escalation path.

Before We Start

This first checkpoint defines the work sample you are about to create. It connects your troubleshooting process to the skills expected in an entry-level IT role.

Set Up the Incident Workspace

A credible help desk ticket begins with the exact environment where the incident occurred. That record gives every later diagnostic result a reliable frame.

In this step, you will verify Microsoft Windows with Command Prompt. You will save the confirmed details in a ticket template using Notepad.

In this step, get ready to:

Verify the Windows edition, version, and OS build.
Create a structured incident ticket in Notepad.
Confirm the saved ticket persists after closing Notepad.

Verify your Windows environment

The winver command displays the Windows edition, version, and OS build. Recording these details ties your future evidence to the computer where you collected it.

Press the Windows key to open Windows search.
Type Command Prompt into the search field.
Select Command Prompt from the search results.
Display your Windows information by running this command:

winver

What Does winver Confirm?

The About Windows dialog identifies the installed edition. It also displays the version and OS build used for your support record.

Record the displayed Windows edition here: your Windows edition.
Record the displayed Windows version here: your Windows version.
Record the displayed OS build here: your OS build.
Record Microsoft ended Windows 10 support on October 14, 2025 if the displayed edition is a standard Windows 10 edition.
Continue the lab without changing the operating system.
Close the About Windows dialog after recording the displayed values.

About Windows Dialog Missing?

Check that you entered winver as one word in Command Prompt. Run it again after correcting any typing mistake.

If the dialog still does not open, help me verify Windows from Command Prompt.

Create and save the ticket template

A structured ticket keeps the report, evidence, diagnosis, action, and outcome in predictable places. This format makes your troubleshooting process easy to follow.

Press the Windows key to open Windows search.
Type Notepad into the search field.
Select Notepad from the search results.
Create the ticket structure by pasting this text into the blank Notepad document:

Ticket ID:
User Report:
Environment:
Windows edition: [[WINDOWS_EDITION="your Windows edition"]]
Windows version: [[WINDOWS_VERSION="your Windows version"]]
OS build: [[OS_BUILD="your OS build"]]
Windows 10 support note (if applicable): Microsoft ended Windows 10 support on October 14, 2025.
Impact:
Baseline:
Evidence:
Diagnosis:
Action Taken:
Verification:
User Response:
Escalation:

How Is the Ticket Organized?

The environment fields preserve the Windows details you recorded from the About Windows dialog.
The report fields capture what the user experienced and how the incident affected them.
The evidence fields separate observed command results from the diagnosis you reach later.
The final fields record your action, verification, user response, and escalation decision.

Delete the Windows 10 support note line if your displayed edition is not a standard Windows 10 edition.
Select File in Notepad.
Select Save As.
Select Documents in the save dialog.
Enter IT-Support-Ticket.txt in the File name field.
Select Save.

You should see IT-Support-Ticket.txt as the document name in Notepad. The saved file now lives in your Documents folder.

Ticket Name or Location Looks Wrong?

Check that the file name ends with .txt. Confirm that the save location is your Documents folder.

If the save did not work, help me save this Notepad ticket correctly.

✔️ Awesome, I've got everything!

Your ticket contains every required heading. Confirm that you saved the latest changes before continuing.

ⓧ I'd like to double check the full code

Ticket ID:
User Report:
Environment:
Windows edition: [[WINDOWS_EDITION="your Windows edition"]]
Windows version: [[WINDOWS_VERSION="your Windows version"]]
OS build: [[OS_BUILD="your OS build"]]
Windows 10 support note (if applicable): Microsoft ended Windows 10 support on October 14, 2025.
Impact:
Baseline:
Evidence:
Diagnosis:
Action Taken:
Verification:
User Response:
Escalation:

Compare this reference with your saved file. Remove the Windows 10 support note line when that edition does not apply to your computer.

Reopen and verify the saved ticket

Closing Notepad tests whether the ticket exists as a saved file. Reopening it proves that your headings and environment details persist beyond the current editing session.

Close the Notepad window with the X button in the top-right corner.
Press the Windows key to open Windows search.
Type IT-Support-Ticket.txt into the search field.
Select the file result to reopen it in Notepad.

You should see the saved ticket headings and the three Windows environment values. A standard Windows 10 edition should also show the support-end note.

Switch back to the Command Prompt window from earlier.

Before the final check, which three environment details do you expect the dialog to repeat?

Repeat the Windows environment check by running this command:

winver

What Does the Final Check Prove?

The repeated command lets you compare the live Windows information with the values saved in the ticket. Matching details confirm that your workspace records the correct environment.

You should see the Windows edition, version, and OS build in the About Windows dialog. Your reopened Notepad file should contain the required ticket headings.

Close the About Windows dialog after matching its details with the ticket.

Ticket Missing or Empty?

Search for IT-Support-Ticket.txt again. Check your Documents folder if Windows search does not list the file.

If the file opens without your headings, return to the template above and save it again. Help me recover my saved Notepad ticket.

That foundation is in place: your saved ticket now carries the exact Windows context behind every result. Next, you will capture a healthy local network baseline.

Capture a Healthy Local Baseline

Your saved ticket in Notepad already records the Windows environment behind this incident. A healthy local baseline gives you a known working result before you investigate the reported destination.

One failed destination can look like a total outage when there is no comparison point. You will use Command Prompt to document the active adapter before testing the local TCP/IP path.

In this step, get ready to:

Record the active adapter's TCP/IP configuration.
Test the local loopback destination.
Write a cautious baseline conclusion.

Inspect the active adapter configuration

An active network adapter carries your current connection. Its observed settings provide evidence that Windows has network configuration to work with.

Switch back to Command Prompt from the previous step.
Display the full TCP/IP configuration for every adapter by running this command:

ipconfig /all

What does this command show?

The ipconfig /all command displays the full TCP/IP configuration for every adapter.
The command leaves your network settings unchanged.
The active adapter's populated fields provide the evidence you need for the ticket.

Locate the adapter section that contains the connection's observed IPv4 Address.
Confirm that the same adapter section lists a Default Gateway.
Confirm that the same adapter section lists DNS Servers.

You now have one adapter section that ties the current connection to its observed IPv4 gateway details and DNS configuration.

Switch back to IT-Support-Ticket.txt in Notepad from earlier.
Add a three-line adapter entry under Environment using the observed IPv4 Address, Default Gateway, plus DNS Servers values.

You should now see all three observed adapter fields under Environment.

Save IT-Support-Ticket.txt in Notepad using the save method from the previous step.
Check that the three adapter fields remain visible under Environment.

Good progress. Your ticket now links the recorded Windows environment to the adapter configuration observed on this computer.

Can't identify the active adapter?

Compare only adapter sections that show populated network values.
Use the adapter carrying your current Wi-Fi or Ethernet connection.
Avoid changing any network settings while you identify the evidence source.

Help me identify the active adapter

Test the local loopback path

The name localhost resolves to a loopback destination inside your computer. A reply provides focused evidence about the local TCP/IP path.

Before you run the test, pause to predict whether the computer can reach its own loopback destination.

Switch back to Command Prompt from earlier.
Test the local loopback path by running this command:

ping localhost

What does this command test?

The ping localhost command sends echo requests to the local loopback destination.
Received replies provide basic evidence that the local TCP/IP path responds.
The summary records how the local requests were handled.

You should see replies from the local loopback destination. The summary should report received responses.

Switch back to Notepad from earlier.
Add a two-line entry under Baseline with the observed reply status plus the displayed summary.

You should now see the actual loopback result recorded under Baseline.

Save IT-Support-Ticket.txt.
Check that the reply status plus summary remain visible under Baseline.

That gives you a working local comparison point. Your ticket now contains observed evidence from the computer itself.

Didn't receive loopback replies?

Confirm that the destination was typed as localhost.
Record the actual result instead of replacing it with expected text.
Keep the network settings unchanged so the ticket reflects the original environment.

Help me understand my loopback result

Write a cautious baseline conclusion

The ping command provides basic connectivity evidence. Its result supports a narrow conclusion about the local path.

Add the following conclusion under Baseline in IT-Support-Ticket.txt:

The local TCP/IP path is responding and the active adapter has configuration, but this does not yet prove every website or application is reachable.

Why keep the conclusion cautious?

The first clause states the evidence supported by the adapter configuration plus loopback replies.
The final clause prevents the ticket from making unsupported claims about websites or applications.

Save Documents\IT-Support-Ticket.txt in Notepad.

Before you review the ticket, pause to predict which details should now appear under Environment plus Baseline.

Review the Environment section in Notepad.
Review the Baseline section in Notepad.

Under Environment, you should see the Windows edition, version, plus OS build from the previous step. You should also see the active adapter's IPv4 Address, Default Gateway, plus DNS Servers.

Under Baseline, you should see the observed ping localhost reply status plus summary. You should also see the cautious conclusion about the limits of this evidence.

Your healthy local baseline is documented. Next, you will reproduce the user's reported destination failure and compare it with this working local test.

Reproduce the User's Failure

Your ticket already shows that the local TCP/IP path responds. The active adapter also has recorded configuration.

The reported destination is still unexplained. In this step, you will use Command Prompt to reproduce the user's symptom before selecting any action.

In this step, get ready to:

Add the simulated user report to the ticket.
Test the reported destination from Command Prompt.
Keep the successful local baseline visible while marking the diagnosis as pending.

Record the simulated report

A help desk ticket keeps a user's report separate from the technician's conclusion. Recording the wording first protects the evidence trail.

Switch back to Documents\IT-Support-Ticket.txt in Notepad.
Find the User Report heading.
Add the simulated statement beneath that heading by copying the text below:

The user says support-check.invalid cannot be reached and assumes Wi-Fi is down.

Why Separate Report From Diagnosis?

The User Report section records what the user believes.

The Evidence section holds test results. The Diagnosis section holds the supported conclusion.

Save Documents\IT-Support-Ticket.txt.
Read the User Report section to confirm the sentence appears exactly as shown.

Good work. The ticket now preserves the user's assumption without treating it as a proven cause.

Report Missing After Saving?

Make sure the sentence sits under User Report. Confirm that you saved IT-Support-Ticket.txt in Documents.

Help me place the simulated report in my support ticket.

Test the reported destination

The ping command accepts a host name as its destination. Its output gives you a direct comparison with the earlier ping localhost result.

Before you run the test, do you expect this destination to reply like localhost or behave differently?

Switch back to Command Prompt from earlier.
Test the exact destination from the report by running this command:

ping support-check.invalid

What Does This Command Test?

The ping command accepts support-check.invalid as the destination host name.
Replies would include round-trip times if this test received them.
The earlier ping localhost result gives you a successful local comparison.

You will see a failure in name resolution instead of replies. This is the intended shortfall.

That result is useful. You have reproduced the user's symptom without changing the network.

Highlight the complete command output in Command Prompt.
Copy the selected output with Ctrl+C.
Switch back to Documents\IT-Support-Ticket.txt.
Find the Evidence heading.
Paste the copied output beneath the heading with Ctrl+V.
Save Documents\IT-Support-Ticket.txt.

Under Evidence, you should see the exact output from your computer. It should show the name-resolution failure instead of replies.

Not Seeing a Name-Resolution Failure?

Check that the destination is spelled exactly as support-check.invalid. Make sure the command contains the .invalid ending.

Help me check my failed destination test.

Keep the diagnosis pending

One failed destination does not support a conclusion that the entire Wi-Fi connection is down. Your evidence currently shows a working local baseline plus one destination that does not resolve.

Keep the Network Unchanged

The current evidence supports more testing. Keeping the configuration unchanged preserves a clean comparison for the next test.

Do not reset the network adapter.
Do not clear DNS caches.
Do not change DNS settings.

Compare the successful ping localhost result under Baseline with the failed destination output under Evidence.
Find the Diagnosis heading.
Enter Pending beneath the heading.
Find the Action Taken heading.
Enter No network settings were changed.
Save Documents\IT-Support-Ticket.txt.

Before the final check, do you expect the ticket to prove a total Wi-Fi outage or show a problem limited to the reported destination?

Review the User Report section for the simulated complaint.
Review the Baseline section for the successful local test.
Review the Evidence section for the exact failed destination output.
Review the Diagnosis section for its current status.
Review the Action Taken section for confirmation that the configuration stayed unchanged.

You should still see successful ping localhost evidence under Baseline. You should also see failed ping support-check.invalid output under Evidence.

The diagnosis should read Pending. Action Taken should state No network settings were changed.

Strong work. Your ticket now demonstrates a reproducible shortfall while preserving the healthy local baseline.

You have reproduced the complaint without making an unsupported change. Next, you will use direct DNS tests to identify the root cause or justify escalation.

Isolate the DNS Root Cause

You have reproduced the user's failure while keeping the successful local baseline intact. The missing piece is whether the supplied hostname is invalid or public name resolution is failing.

The nslookup command queries the configured DNS server without using the client's DNS cache. Comparing a reserved invalid name with a known public name gives you evidence without changing any network settings.

In this step, get ready to:

Document the reserved name's DNS result.
Test public DNS with a known public name.
Classify the incident from the comparison.

Confirm why the reserved name fails

The .invalid namespace is reserved for names that are defined not to exist. A direct lookup shows how your configured DNS server handles the simulated destination.

Before you run the lookup, predict whether a reserved invalid name can return public address data.
Switch back to the Command Prompt window from earlier.
Query the reserved hostname by running this command:

nslookup support-check.invalid

What does this lookup show?

The nslookup command asks the configured DNS server about the hostname. It bypasses the client's DNS cache.

The hostname support-check.invalid sits beneath the reserved .invalid namespace. A negative answer is expected because names there are defined not to exist.

Return to IT-Support-Ticket.txt in Notepad from earlier.
Record the DNS server under Evidence exactly as displayed.
Record the negative result exactly as displayed.
Save IT-Support-Ticket.txt.
Check that Evidence now includes the DNS server used plus the negative result.

Your ticket now has direct DNS evidence for the same name that the earlier ping could not resolve.

Unexpected lookup result?

Check that the hostname ends in .invalid.
Run the command again if a typing error changed the destination.

Help me understand my reserved-name lookup result.

Test a public name

The invalid-name result explains why that specific destination fails. A public lookup reveals whether your configured DNS server can also resolve an Internet name.

Before you run the public lookup, predict whether it will return address data or fail too.
Switch back to the Command Prompt window from earlier.
Query the documented public test name by running this command:

nslookup bing.com

What does this comparison prove?

The hostname bing.com provides a public comparison point. Returned address data shows that the configured DNS server answered this public lookup.

A failed public lookup is separate evidence from the guaranteed invalid-name result. It supports escalation for a broader DNS or connectivity problem.

Return to IT-Support-Ticket.txt in Notepad.
Record the observed public lookup result under Evidence.
Copy the returned public address data if the lookup succeeds.
Copy the exact error if the lookup fails.
Save IT-Support-Ticket.txt.

Returned address data supports a working public DNS classification. A failure becomes evidence for a separate escalation path.

Public lookup did not return addresses?

Check that the destination is spelled bing.com.
Run the lookup one more time after correcting any typing error.
Keep the exact failure in Evidence if the corrected lookup still fails.
Leave the network settings unchanged.

Help me classify my failed public DNS lookup.

Write the evidence-based diagnosis

Your diagnosis needs to separate the guaranteed invalid hostname from the public DNS result. The public lookup determines whether you close the simulated complaint or document a separate escalation.

Choose the tab that matches your public lookup result.

✔️ bing.com returned address data

Returned public address data shows that public DNS resolution worked during your test. The user-provided invalid destination is the root cause of the simulated complaint.

Find pending under Diagnosis.
Replace it with a concise statement that support-check.invalid belongs to the reserved .invalid namespace.
State that this hostname is expected not to resolve.
Classify public DNS as working based on the returned public address data.
Identify the supplied invalid destination as the root cause.

ⓧ bing.com failed

The failed public lookup does not change the reserved-name finding. It creates a separate DNS or connectivity issue that needs escalation.

Find pending under Diagnosis.
Replace it with a concise statement that support-check.invalid belongs to the reserved .invalid namespace.
State that this hostname is expected not to resolve.
Record that the invalid-name finding remains valid.
Classify the separate public DNS or connectivity failure as requiring escalation.

Keep the existing note that no network settings were changed.
Save IT-Support-Ticket.txt.
Before checking the ticket, predict which diagnosis statement changes when the public lookup fails.
Review Evidence for the earlier ping failure plus both DNS lookup results.
Review Diagnosis for the conclusion that matches your public lookup outcome.

What should I see?

The Evidence section contains the exact earlier ping failure.
The Evidence section contains the DNS server plus the negative reserved-name result.
The Evidence section contains returned public address data or the exact public lookup error.
The Diagnosis section identifies the reserved invalid hostname plus the correct resolution or escalation path.
The ticket still states that no network settings were changed.

Your ticket now separates an invalid destination from a broader public DNS problem. Next up, you'll turn that evidence into a clear resolution or escalation message for the user.

Close the Help Desk Ticket

Your direct DNS tests have separated the reserved destination from the broader public lookup result. The remaining challenge is turning that evidence into a trustworthy help desk ticket.

Employers need evidence that you can turn technical output into an accurate record. They also need to see a response a nontechnical user can follow.

In this step, get ready to:

Complete the technical record using only observed evidence.
Write a plain-language response with the correct closure path.
Produce a redacted ticket that persists after reopening.

Complete the evidence-based record

Evidence-based documentation keeps observations separate from conclusions. The earlier results already provide every fact you need.

Switch back to IT-Support-Ticket.txt in Notepad from earlier.
Enter a short non-identifying value under Ticket ID.
Record the impact as one supplied destination being unreachable under Impact.

The top of your ticket now identifies the case without overstating its impact.

What belongs in Action Taken?

This section records the diagnostic process. Each entry should correspond to work you actually performed.

Include the Windows version check.
Include the active adapter configuration review.
Include the local loopback test.
Include the failed supplied-destination test.
Include the two direct DNS lookups.

Summarize those diagnostics under Action Taken without claiming a repair.
State under Action Taken that you made no network configuration changes.

Your action record now shows a targeted investigation without unsupported system changes.

Summarize the observed outcomes under Verification.
Compare Verification with Diagnosis to confirm that both sections support the same conclusion.

The technical sections now form a traceable path from the original report to your diagnosis.

Write the user response and closing decision

A user response translates technical evidence into plain language. Your closing decision should reflect the public lookup result you actually observed.

Explain under User Response that the supplied test address belongs to the reserved .invalid namespace.
State that names in this namespace are expected not to resolve.

The user-facing explanation now addresses the failed destination without blaming the entire connection.

✔️ bing.com returned address data

State under User Response that the public DNS test worked.
Enter a verified-resolution closure under Escalation that identifies the supplied invalid destination as the root cause.

Your closure now explains why the reported destination failed while preserving the successful public DNS evidence.

ⓧ bing.com also failed

State under User Response that further network investigation is required.
Enter a specific request under Escalation to investigate the separate public DNS or connectivity failure.

Your escalation now preserves the valid reserved-name finding while passing the separate public lookup failure to the next technician.

Scan Action Taken for any statement claiming that settings were repaired.
Remove any repair claim that is unsupported by your recorded actions.

The closing sections now match the work you performed and the results you observed.

Redact and verify the saved ticket

Redaction protects environment-specific details before you share the ticket. Finding every local identifier can be fiddly because the values appear across several sections.

Scan the entire ticket for personal host names.
Replace each personal host name with a neutral placeholder.

The portfolio copy now hides host-specific identity details.

Scan the entire ticket for local IP addresses.
Replace each local IP address with a neutral placeholder.

The portfolio copy now protects the local addressing details recorded during diagnosis.

Replace each DNS suffix with a neutral placeholder.
Replace each adapter identifier with a neutral placeholder.

Your environment evidence is now suitable for sharing without exposing local network identifiers.

Keep the verified Windows edition under Environment.
Keep the verified Windows version under Environment.
Keep the verified OS build under Environment.
Confirm that every original heading contains a concise entry.

Before the final check, what do you expect to remain in the file after you close and reopen it?

Save the current IT-Support-Ticket.txt file in Notepad.
Close Notepad.
Reopen IT-Support-Ticket.txt from Documents by selecting it in Windows search.

You'll see the redacted ticket with every heading intact. Its final section contains either a verified-resolution closure or a specific escalation request.

Can't find the saved ticket?

Search for the exact file name IT-Support-Ticket.txt.
Confirm that the selected search result comes from Documents.

Help me find my saved ticket.

✔️ Awesome, I've got everything!

Your reopened ticket contains the complete redacted incident record.

ⓧ I'd like to double check the full ticket

Confirm that every original heading contains a concise entry.
Confirm that User Report states: "The user says support-check.invalid cannot be reached and assumes Wi-Fi is down."
Confirm that Environment retains the verified Windows edition.
Confirm that Environment retains the verified Windows version.
Confirm that Environment retains the verified OS build.
Confirm that personal host names have neutral placeholders.
Confirm that local IP addresses have neutral placeholders.

What should the closing show?

A successful public lookup supports a verified-resolution closure for the invalid supplied destination.

A failed public lookup supports a specific escalation request for the separate DNS or connectivity problem.

Confirm that DNS suffixes have neutral placeholders.
Confirm that adapter identifiers have neutral placeholders.
Confirm that Baseline preserves the observed local test result.
Confirm that Evidence preserves the observed command results.
Confirm that Diagnosis identifies the reserved .invalid namespace.
Confirm that Action Taken lists only diagnostics you performed.
Confirm that Verification lists only outcomes you observed.

Retain the Windows 10 support-end note if it applies to your computer.

That is the case closed. Your reopened report now demonstrates accurate diagnosis, careful documentation, privacy awareness, and clear user communication.

Secret mission

Trace the Network Path

DNS evidence tells you whether a name resolves. Extend your ticket with an annotated route trace. Record responding hops plus timeout context for a network specialist.

Clean Up Your Resources

Your Windows network checks created no cloud resources or paid services. The saved Documents\IT-Support-Ticket.txt file has no ongoing cost.

Resources you used:

Local Documents\IT-Support-Ticket.txt file containing your redacted incident report.

Keep everything running

No action is needed. Keeping the file preserves your redacted ticket as an employment work sample.

Leave Documents\IT-Support-Ticket.txt in your Documents folder.
Use the ticket as a reference for evidence-based troubleshooting.
Share only the redacted copy.

Pause - I'll come back to this later

Pausing closes the diagnostic tools while preserving the saved ticket.

Close Command Prompt.
Close Notepad.
Leave Documents\IT-Support-Ticket.txt in your Documents folder.

The diagnostic commands have already finished. Nothing continues running after both tools close.

Delete - I don't want to use this again

Deleting the ticket removes your only project artifact. Your Windows environment stays unchanged.

Use Windows search to open File Explorer.
Select Documents in the left navigation pane.
Select IT-Support-Ticket.txt in the file list.
Press the Delete key.
Confirm IT-Support-Ticket.txt no longer appears in Documents.
Empty Recycle Bin to remove the file permanently.

The ticket is now removed. Your network settings remain untouched.

Nice Work!

Strong finish! Your redacted Windows help desk case study in Documents\IT-Support-Ticket.txt now documents an evidence-based network diagnosis from the first report through resolution or escalation.

What you learned:

Built a structured incident report that follows the help desk ticket lifecycle from the user report through resolution or escalation.
Established a healthy local baseline using TCP/IP configuration evidence. Used that baseline to separate local connectivity from a failed destination.
Used DNS evidence to classify public name resolution as working or requiring escalation. Translated the result into a redacted response for a nontechnical user.
Secret Mission: Added an annotated route trace that records responding hops plus an observed round-trip time. Explained why a missing intermediate ICMP response does not automatically prove an outage.

Ready to quiz yourself?