Resolve a Windows DNS Incident

Diagnose a Windows Hosts-file override and document the DNS incident resolution.

Introduction

30 Second Summary

When a familiar website suddenly stops opening, the whole internet can seem broken. A careful support technician needs to find the exact cause before changing the computer.

In this project, you will resolve a controlled DNS name-resolution incident on Windows 11. You will support the fix with before-and-after evidence in a professional incident report.

What You'll Build

Your finished report tells the complete story of a local Hosts file incident from the wrong address through the verified fix.

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

  • A repeatable name-resolution test that shows Windows directing example.com to the lab address 192.0.2.1.
  • A restored workstation that no longer sends example.com to the incorrect lab address.
  • A professional incident report that explains the symptom, scope, root cause, resolution, rollback, and validation.
  • Secret Mission: A reusable knowledge-base article that helps another technician diagnose and resolve Hosts-file overrides.

Are there any prerequisites?

You need a working internet connection. You also need permission to approve administrator prompts on a Windows 11 computer.

Before We Start

Before the hands-on work begins, commit to diagnosing a Windows name-resolution incident without damaging the existing network configuration. Your evidence will explain the root cause before you safely restore access.

Prepare a Safe Support Workspace

A protected system file needs a known-good starting point before any troubleshooting change. A baseline test records how name resolution behaves before the incident begins.

An untouched Hosts file backup gives you a rollback path if a later edit causes trouble. A dedicated report preserves the evidence behind each support decision.

In this step, get ready to:
  • Protect the original Hosts file in a dedicated rollback folder.
  • Capture normal IPv4 name resolution evidence with elevated Windows PowerShell.
  • Save the baseline in a ticket-style incident report.
Build a protected rollback workspace

The lab workspace keeps your evidence separate from the protected Windows directory. The backup stays unchanged throughout the incident simulation.

  • Press Windows+E to open File Explorer.
  • Select Desktop in the left navigation pane.
  • Click New in the File Explorer toolbar.
  • Select Folder.
  • Type IT-Support-Lab as the folder name.
  • Press Enter to create the folder.
  • Double-click IT-Support-Lab to enter the lab workspace.

The IT-Support-Lab folder now appears on your Desktop. This is the home for every lab artifact.

  • Click New in the File Explorer toolbar.
  • Select Folder.
  • Type Hosts Backup as the subfolder name.
  • Press Enter to create the subfolder.

The Hosts Backup subfolder now gives the rollback copy a clear home.

  • Press Ctrl+L to select the File Explorer address bar.
  • Type C:\Windows\System32\drivers\etc into the address bar.
  • Press Enter to load the protected directory.
  • Select the file named hosts.
  • Press Ctrl+C to copy the file.

Why preserve the original file?

Copying hosts leaves the active system file unchanged. The untouched copy provides a known-good rollback if the controlled edit needs to be reversed.

  • Select Desktop in the left navigation pane.
  • Double-click IT-Support-Lab.
  • Double-click Hosts Backup.
  • Press Ctrl+V to paste the copied file.
  • Confirm that a file named hosts appears without a file extension.

Your untouched rollback copy is protected inside Desktop\IT-Support-Lab\Hosts Backup. The active Hosts file remains unchanged.

Can't find the Hosts-file backup?

  • Confirm that the source address bar shows C:\Windows\System32\drivers\etc.
  • Check that the copied file is named hosts without an extension.

If the copy still does not appear, help me troubleshoot the protected Hosts-file backup.

Capture a clean resolver baseline

An elevated Windows PowerShell session keeps the later troubleshooting work in one window. The administrator prompt can feel significant, but these baseline commands only read network behavior.

  • Press the Windows key to open search.
  • Type Windows PowerShell into the search field.
  • Right-click Windows PowerShell in the search results.
  • Select Run as administrator.
  • Approve the administrator prompt.
  • Confirm that the PowerShell window identifies itself as an administrator session.
  • Compare Windows' IPv4 choice with the configured DNS server's answer by running these commands:
ping /4 example.com
nslookup example.com

What do these commands show?

  • The opening line from ping /4 example.com shows the IPv4 address selected by Windows for the hostname.
  • The nslookup example.com command sends the lookup to the configured DNS server without using the client's DNS cache.
  • Missing echo replies can reflect blocked ICMP traffic. The address in the opening line is the evidence that matters here.
  • Find the selected IPv4 address in the opening line of the ping output.
  • Record that value here: your ping baseline address.
  • Find the answer address or addresses for example.com in the nslookup output.
  • Record those values here: your nslookup baseline addresses.
  • Confirm that neither result identifies 192.0.2.1.
  • Keep the elevated Windows PowerShell session open for the next step.

You now have two views of normal name resolution. Both provide the clean evidence that the controlled incident needs.

Baseline not resolving cleanly?

  • Return to a working internet connection if either command cannot resolve example.com.
  • Stop before continuing if either baseline result identifies 192.0.2.1.

A pre-existing conflict needs to be resolved before this controlled lab begins. Help me diagnose an unexpected baseline result.

Complete the baseline report

A clear incident report turns terminal output into support evidence. Notepad keeps this record portable without adding a ticketing platform to the lab.

  • Press the Windows key to open search.
  • Type Notepad into the search field.
  • Press Enter to open Notepad.
  • Enter the current session date after a Date: label.
  • Enter Ticket ID: LAB-001 on the next line.
  • Enter Reported symptom: followed by a plain-language note that the user cannot reach example.com as expected.
  • Enter Baseline ping address: followed by your ping baseline address.
  • Enter Baseline nslookup address(es): followed by your nslookup baseline addresses.

The draft now connects the reported symptom to specific before-change evidence.

  • Click File in the Notepad menu bar.
  • Select Save as.
  • Select Desktop in the save window.
  • Open the IT-Support-Lab folder.
  • Enter incident-report.txt in the file name field.
  • Click Save.

Good work. Your rollback copy now has a written baseline beside it, so every later change can be measured against evidence.

Before you recheck the baseline, do you expect either command to show the lab address?

  • Switch back to the elevated Windows PowerShell session.
  • Recheck the clean baseline by running these commands:
ping /4 example.com
nslookup example.com

What does this final check prove?

  • The repeated ping confirms the IPv4 address currently selected by Windows.
  • The repeated nslookup confirms that the configured DNS server still returns a result.
  • The absence of 192.0.2.1 proves that the controlled override is not active yet.
  • Confirm that neither command identifies 192.0.2.1.

You should see normal addresses for example.com. Neither baseline result should identify the lab address.

Seeing the lab address already?

Stop before reproducing the incident if 192.0.2.1 appears now. The workstation already has a conflicting condition outside this lab.

Restore a known-good starting state with your administrator before continuing. Help me investigate this unexpected address.

  • Switch back to File Explorer.
  • Select Desktop in the left navigation pane.
  • Double-click IT-Support-Lab.
  • Confirm that Hosts Backup appears in the lab folder.
  • Confirm that incident-report.txt appears beside the backup folder.
  • Double-click incident-report.txt to reopen it.
  • Confirm that the report contains the date.
  • Confirm that the report contains ticket ID LAB-001.
  • Confirm that the report contains both baseline address results.

Your protected backup and baseline evidence are ready. Next, you will reproduce the user's name-resolution incident under controlled conditions.

Reproduce the DNS Incident

The baseline established that example.com resolves normally before any lab changes. A controlled reproduction now gives you evidence of the reported symptom while your rollback copy stays untouched.

The Windows Hosts file can map a hostname to a specific address. You will add one temporary mapping with Notepad.

Windows PowerShell then reveals how the workstation responds to that mapping. The result becomes the incident evidence you will diagnose in the next step.

In this step, get ready to:
  • Access the active Hosts file with administrator permissions.
  • Add the controlled local name-resolution override.
  • Flush the DNS client cache before reproducing the symptom.
  • Record the observed result in the incident report.
Open the active Hosts file as administrator

The active Hosts file sits in a protected Windows folder. Notepad needs administrator access to save a change there.

Editing a protected system file can feel risky. Your untouched Hosts Backup\hosts copy remains available for the rollback later in the project.

  • Press the Windows key to show the Windows search bar.
  • Type Notepad into the search bar.
  • Right-click Notepad in the search results.
  • Select Run as administrator.
  • Click Yes when Windows asks for approval.

Why administrator access matters

Windows protects the active Hosts file from standard app sessions. An elevated Notepad session can save the controlled lab change.

  • Select File from the Notepad menu.
  • Select Open.
  • Go to C:\Windows\System32\drivers\etc in the file picker.
  • Select All files (*.*) from the file type menu.
  • Select the hosts file.
  • Click Open.

You should see the original Hosts-file contents in the elevated Notepad window. The backup inside Desktop\IT-Support-Lab\Hosts Backup remains untouched.

Can't access the active Hosts file?

  • Confirm that the file type menu shows All files (*.*) if the hosts file is hidden.
  • Confirm that Notepad was started with the administrator option if the protected file cannot be edited.

Need help with the protected file? Help me access the active Windows Hosts file safely in an elevated Notepad session.

Add the controlled override

Each Hosts-file entry places an IP address before its hostname. Text after a # labels the purpose of the entry as a comment.

  • Place the cursor on a new line at the end of the active hosts file.
  • Paste the controlled lab mapping into that line:
192.0.2.1 example.com # IT-support-lab

What does this entry contain?

  • The address 192.0.2.1 belongs to a documentation-only IPv4 range.
  • The hostname example.com is the name used throughout this lab.
  • The comment # IT-support-lab identifies the controlled entry for later removal.
  • Press Ctrl+S to save the active hosts file.

The lab entry remains visible after the save. Every original line stays in place above it.

Can't save the Hosts file?

Confirm that this is the active file at C:\Windows\System32\drivers\etc\hosts. Confirm that Notepad is running with administrator access.

Keep the backup copy unchanged. Help me troubleshoot why elevated Notepad cannot save this Hosts-file entry.

  • Close the elevated Notepad window.
Flush the cache and reproduce the symptom

The DNS client cache stores name-resolution information on the workstation. Resetting it gives the saved configuration a clean test.

  • Switch back to the elevated Windows PowerShell session from earlier.
  • Reset the DNS client resolver cache by running this command:
ipconfig /flushdns

What does this command do?

The command clears the workstation's DNS client resolver cache. The next name-resolution test starts with the current local configuration.

PowerShell confirms that the DNS resolver cache was flushed.

Before you run the test, which address do you think Windows will choose for example.com?

  • Test IPv4 name resolution by running this command:
ping /4 example.com

How should you read this test?

The opening line shows the IPv4 address Windows selected for example.com. That line is the evidence you need for this name-resolution test.

Echo replies may time out when ICMP traffic is blocked. The selected address remains valid diagnostic evidence.

You will see 192.0.2.1 in the first output line. The result counts even if the echo requests time out.

You have reproduced the controlled incident successfully. Windows now sends this hostname to the lab address.

Still seeing the baseline address?

  • Return to the active hosts file in elevated Notepad.
  • Confirm that the lab entry matches the line above exactly.
  • Save the active hosts file.
  • Return to the elevated Windows PowerShell session from earlier.
  • Run the cache-flush command above again.
  • Run the ping test above again.

Need help tracing the unexpected result? Help me find why Windows is not using my controlled Hosts-file entry.

A reproducible symptom becomes useful support evidence when the ticket records what changed for the user. Add the observed address before moving into diagnosis.

  • Return to incident-report.txt from earlier in Notepad.
  • Add the reproduced mapping of example.com to 192.0.2.1 under your observations.
  • Save incident-report.txt.

The reproduced address is now recorded beside the original baseline evidence.

  • Add that the user is directed to the lab address instead of the normal destination under user impact.
  • Save incident-report.txt again.

Your report now contains the baseline addresses plus the controlled 192.0.2.1 result. The untouched backup remains ready for rollback.

The incident is now reproducible and documented. Next, you will compare local Windows resolution with a direct DNS-server query to isolate the source of the mismatch.

Isolate the Local Override

That controlled test did its job. Local Windows resolution now maps example.com to 192.0.2.1.

A direct DNS server query can still return a valid answer while the workstation uses the local override. Comparing these resolution paths reveals the source of the conflict.

In this step, get ready to:
  • Record a privacy-safe summary of the active network connection.
  • Compare the configured DNS server answer with local Windows resolution.
  • Identify the Hosts-file entry responsible for the mismatch.
Record a privacy-safe network summary

The complete TCP/IP configuration establishes whether the workstation has an active network path. It can also expose details that do not belong in a shared incident report.

  • Display the complete network configuration in the elevated Windows PowerShell session from earlier by running this command:
ipconfig /all

What Does This Command Show?

  • The command displays the complete network configuration for each adapter.
  • The active adapter section shows whether an IPv4 address is present.
  • The same section shows whether a default gateway is present.
  • The listed DNS server address identifies where direct DNS queries are sent.
  • A short summary preserves the diagnostic evidence without publishing the full output.

You will see a populated section for the connection carrying your internet traffic. That section contains the four details needed for your report.

  • Locate the adapter section carrying your current internet connection.
  • Switch back to Desktop\IT-Support-Lab\incident-report.txt in Notepad.
  • Record the active adapter type.
  • Record whether an IPv4 address is present.
  • Record whether a default gateway is present.
  • Record the configured DNS server address.
  • Save incident-report.txt.

Good progress. Your report now establishes the workstation's network scope without exposing the complete configuration.

Can't Identify the Active Adapter?

  • Skip adapter sections that do not show an active connection.
  • Use the adapter carrying your current internet connection.
  • Keep the report limited to the four requested details.

If the active section is still unclear, help me identify the active adapter without sharing private network details.

Compare the two resolution paths

The nslookup command sends its query to the configured DNS server. The ping command shows the IPv4 address selected through normal local Windows resolution.

Before you compare them, do you expect both resolution paths to select the same address for example.com?

  • Compare the direct DNS answer with local Windows resolution by running these commands:
nslookup example.com
ping /4 example.com

What Do These Checks Compare?

  • The first command sends the lookup to the configured DNS server without using the client's DNS cache.
  • The second command displays the address selected by local Windows name resolution.
  • The opening line from the second command provides the relevant resolver evidence.
  • Blocked ICMP traffic can prevent echo replies without changing the selected address.

You will see the direct DNS query return an answer different from 192.0.2.1. The opening line from ping still identifies 192.0.2.1.

The mismatch narrows the fault to local resolution on this workstation. The configured DNS server is returning a different answer.

  • Add the DNS server answer to the observations in incident-report.txt.
  • Record that the DNS server answer differs from the local 192.0.2.1 result.
  • Save incident-report.txt.

Don't See Two Different Answers?

  • Confirm the workstation still has a working internet connection.
  • Confirm the active Hosts file still contains 192.0.2.1 example.com # IT-support-lab.
  • Use the address in the opening ping line even if the echo requests time out.

If the results still match, help me diagnose the missing resolver mismatch.

Trace the result to the Hosts file

The DNS client cache can include records preloaded from the local Hosts file. Inspecting both connects the resolver mismatch to a specific workstation entry.

  • Display the DNS client resolver cache in the elevated PowerShell session by running this command:
ipconfig /displaydns

What Does the Cache Reveal?

  • The command displays the current DNS client resolver cache.
  • The output includes records preloaded from the local Hosts file.
  • A matching record connects the lab address to the workstation's local resolution path.

You will find resolver evidence linking example.com with 192.0.2.1.

  • Switch back to incident-report.txt.
  • Add the cache observation to the report.
  • Save incident-report.txt.

The cache confirms that the lab address entered the local resolver path. The active system file can now reveal the source of that record.

  • Press the Windows key to open Windows search.
  • Type Notepad into Windows search.
  • Choose the administrator option for Notepad.
  • Approve the administrator prompt.
  • Use the file-opening control in the elevated Notepad window.
  • Browse to C:\Windows\System32\drivers\etc.
  • Set the file type filter to All files (*.*).
  • Select the active hosts file.

You will see 192.0.2.1 example.com # IT-support-lab on its own line. This is the local entry connected to the cached result.

Why Does This Entry Control the Result?

Windows checks the local Hosts file before requesting a normal DNS answer. The lab entry maps example.com directly to 192.0.2.1.

The direct DNS query follows a separate path to the configured server. This precedence explains the conflicting results.

  • Leave the active hosts file unchanged.
  • Switch back to incident-report.txt.
  • Add the Hosts-file observation to the report.
  • State that the IT-support-lab Hosts entry overrides normal DNS resolution for example.com.
  • Save incident-report.txt.

Can't Find the Active Entry?

  • Confirm Notepad opened the extensionless hosts file.
  • Confirm the file came from C:\Windows\System32\drivers\etc.
  • Keep the untouched backup in Desktop\IT-Support-Lab\Hosts Backup unchanged.

If the lab line is still missing, help me locate the active Hosts entry safely.

Before the final comparison, do you expect the configured DNS server and local Windows resolution to agree?

  • Verify the conflicting resolution paths in the elevated PowerShell session by running these commands:
nslookup example.com
ping /4 example.com

What Does the Final Comparison Prove?

The direct query confirms that the configured DNS server still returns its normal answer. The local result confirms that the active Hosts override still supplies 192.0.2.1.

You will still see different answers from the two commands. This isolates the root cause without changing the workstation configuration during diagnosis.

  • Return to the elevated Notepad window.
  • Confirm the active Hosts file still contains 192.0.2.1 example.com # IT-support-lab.
  • Switch back to incident-report.txt.
  • Confirm the report contains the privacy-safe active adapter summary.
  • Confirm the report contains the DNS server answer that differs from 192.0.2.1.
  • Confirm the report identifies the IT-support-lab Hosts entry as the root cause.
  • Frame your evidence screenshot around the mismatch plus root-cause lines.
  • Keep the configured DNS server address outside the screenshot.

Diagnosis complete. Your evidence now explains why this workstation uses the lab address while the configured DNS server returns a different answer.

You have isolated the local override without disturbing the evidence. Next, you will restore the known-good Hosts file and prove the lab address is gone.

Restore Service and Validate the Fix

Your diagnosis has traced the incident to a local Hosts file override. The workstation still maps example.com to 192.0.2.1.

A safe rollback restores the untouched system file. Resetting the DNS client cache removes stale local entries before fresh tests prove the result.

In this step, get ready to:
  • Restore the untouched backup as the active Hosts file.
  • Reset the DNS client resolver cache after the rollback.
  • Validate restored service with fresh resolution evidence.
Restore the known-good Hosts file

Replacing a protected system file can feel risky. The untouched backup gives you a known-good rollback point.

  • Close the active hosts file in Notepad.
  • Switch back to the File Explorer window from earlier.
  • Return to the Desktop\IT-Support-Lab\Hosts Backup folder.
  • Select the untouched hosts file.
  • Copy the selected file.

You now have the known-good file on the clipboard. The copy inside Hosts Backup remains untouched.

  • Return to C:\Windows\System32\drivers\etc in File Explorer.
  • Paste the copied hosts file into the folder.
  • Approve the administrator prompt.
  • Choose the option that replaces the destination file.

The protected rollback is complete. The active hosts file now comes from your untouched backup.

Flush the DNS client cache

Windows can retain resolver entries after the underlying configuration changes. A cache reset forces the next lookup to use the restored configuration.

  • Reset cached resolver entries in the elevated Windows PowerShell session from earlier by running this command:
ipconfig /flushdns

What does this command do?

  • The ipconfig /flushdns command clears the Windows DNS client resolver cache.
  • The next lookup must rebuild its result from the restored configuration.

PowerShell confirms that the resolver cache was reset.

Cache reset not completing?

  • Confirm you are using the elevated Windows PowerShell session from earlier.
  • Approve any administrator prompt that is waiting behind another window.

If the cache still does not reset, help me troubleshoot the DNS cache reset.

Retest and document restored service

The final comparison checks both Windows local IPv4 resolution and a direct query to the configured DNS server. The restored file should remove the lab address from both results.

Before you run the checks, do you expect either path to keep selecting the lab address after the rollback?

  • Compare local IPv4 resolution with the direct DNS answer by running these commands:
ping /4 example.com
nslookup example.com

How do these tests prove the fix?

  • The opening line from ping /4 example.com shows the IPv4 address Windows selected for the hostname.
  • Echo replies can still time out when ICMP traffic is blocked. The selected address is the evidence that matters here.
  • The nslookup example.com command sends a direct query to the configured DNS server.

Neither result should identify 192.0.2.1. That confirms the resolver has dropped the lab override.

  • Capture the IPv4 address shown in the opening ping line here: post-fix ping address.
  • Capture the DNS-server answer addresses here: post-fix nslookup addresses.

Still seeing the lab address?

  • Confirm the active hosts file came from Desktop\IT-Support-Lab\Hosts Backup.
  • Repeat the cache reset from the previous substep.
  • Retest both resolution paths.

If 192.0.2.1 remains, help me check why the Hosts-file rollback is not taking effect.

  • Press the Windows key to open search.
  • Type Notepad.
  • Select Notepad from the search results.
  • Use Notepad's file browser to navigate to C:\Windows\System32\drivers\etc.
  • Set the file type filter to All files (*.*).
  • Select the hosts file.
  • Open the selected file.
  • Confirm the file does not contain 192.0.2.1 example.com # IT-support-lab.

The restored Hosts file contains the original pre-lab content without the lab entry. This confirms the rollback at the configuration source.

  • Open Desktop\IT-Support-Lab\incident-report.txt in Notepad.
  • Document that the untouched hosts backup replaced the active system file.
  • Add the post-fix ping address post-fix ping address.
  • Add the post-fix DNS answer addresses post-fix nslookup addresses.
  • Record that the active hosts file no longer contains IT-support-lab.
  • Record that neither final test identifies 192.0.2.1 as the service-restored validation.
  • Save incident-report.txt.

Your report now preserves the rollback action plus the post-fix evidence. Another technician can see exactly how you proved service was restored.

The original Hosts file is back in service with fresh resolver evidence to prove it. Next, you will turn the completed diagnosis into a professional ticket closure.

Close the Ticket Professionally

Your workstation now resolves example.com without the lab override. The report already holds the evidence that proves the rollback worked.

A technically correct fix still needs a complete help-desk ticket that another technician can follow. The user also needs a plain-language conclusion that confirms service is restored.

In this step, get ready to:
  • Complete every required incident field with evidence from your session.
  • Close the ticket with a plain-language message.
  • Prove the saved report retains every field.
Complete the incident evidence

Your earlier notes contain raw observations from each test. Root-cause analysis turns those observations into a clear path from the reported symptom to the verified fix.

  • Return to the Desktop\IT-Support-Lab folder in File Explorer from earlier.
  • Double-click incident-report.txt.

The report opens in Notepad. Its existing notes already contain the diagnostic results collected throughout the incident.

What belongs in the incident summary?

  • Ticket ID: Use LAB-001.
  • User impact: Describe the access problem caused by the incorrect address mapping.
  • Reported symptom: State what the user noticed before the diagnosis.
  • Scope: Record that the evidence isolated the problem to local Windows resolution on this workstation.
  • Baseline: Include the initial address selected by the baseline ping. Include the initial answer from the configured DNS server.
  • Compare the opening sections of incident-report.txt with the incident summary fields.
  • Add any missing summary field using evidence from your existing notes.
  • Save incident-report.txt in Notepad.

You should now see LAB-001 beside a complete symptom summary. The scope should identify this workstation's local resolution.

Good. The opening of the ticket now tells another technician what happened before the deeper diagnosis.

What belongs in the technical record?

  • Tests performed: Include every earlier check that used ping. Include every earlier check that used nslookup. Include each ipconfig check. Include your Hosts-file inspection.
  • Observations: Record that local resolution used 192.0.2.1. Record that the configured DNS server returned a different answer.
  • Root cause: Identify the local Hosts entry 192.0.2.1 example.com # IT-support-lab as the source of the mismatch.
  • Resolution: State that the untouched backup replaced the active Hosts file.
  • Rollback performed: Record that the known-good pre-lab file was restored.
  • Validation: Include the post-fix addresses. State that neither result identified 192.0.2.1. Confirm that the restored Hosts file no longer contains IT-support-lab.
  • Compare the technical sections of incident-report.txt with the technical record fields.
  • Add any missing technical field using evidence from your existing notes.
  • Save incident-report.txt in Notepad.

The report should now connect the reproduced 192.0.2.1 failure to the local Hosts override. It should also document the rollback plus the successful post-fix checks.

Missing specific evidence?

Keep every conclusion tied to an observation already recorded during this session. Use the related command result or file change when a field feels vague.

Preserve the failure evidence plus the post-fix evidence. Help me connect my Windows DNS evidence to the correct incident-report fields.

Write the closure message

The technical record serves other technicians. A user-facing closure message confirms the outcome in language the user can understand.

What makes a closure professional?

  • Service outcome: Confirm that access works again.
  • Plain language: Explain the result without resolver jargon.
  • Neutral tone: Describe the configuration change without assigning blame.
  • Technical accuracy: Identify the local override as the cause.
  • Move to the end of incident-report.txt.
  • Add the label User closure message:.
  • Write one or two plain-language sentences stating that access is restored.
  • Add a sentence stating that the completed checks confirmed service works.
  • Review the message for a neutral tone.
  • Add Final status: Resolved below the closure message.
  • Save incident-report.txt in Notepad.

The report now ends with a user-readable result. Its final status shows Resolved.

That completes the communication piece. The ticket now serves the user as clearly as it serves the next technician.

Prove the report persisted

A report is only reliable when its saved copy contains the complete record. Closing the editor tests whether every change persisted to the file in your lab workspace.

Before you close the file, do you expect every saved section to remain when you reopen it?

  • Close Notepad.
  • Return to the Desktop\IT-Support-Lab folder in File Explorer from earlier.
  • Double-click incident-report.txt.
  • Compare the reopened report with the checklist below.

What should I see?

  • The ticket ID shows LAB-001. The user impact is specific. The reported symptom matches the reproduced failure. The scope identifies this workstation.
  • The baseline preserves the pre-lab results. The tests performed field names each diagnostic check. The observations include 192.0.2.1. They also include the different DNS-server answer.
  • The root cause identifies the local Hosts entry. The resolution records the restored original file. The rollback field records the untouched backup.
  • The validation field includes the post-fix results. The user closure message confirms restored service. The final status shows Resolved.

The reopened report should contain every required field with evidence from your session. It should preserve the reproduced failure plus the successful post-fix result.

Report changes missing?

  • Confirm that you reopened Desktop\IT-Support-Lab\incident-report.txt.
  • Add any missing changes in Notepad.
  • Save the report before closing it again.

The backup Hosts file should remain untouched. Help me recover missing changes from my incident report.

Your report can contain local network details. A cropped screenshot protects those details while still proving the ticket is closed.

  • Capture a screenshot of the reopened report showing the user closure message plus Final status: Resolved.
  • Crop out any local IP or DNS server addresses before uploading the screenshot.

Strong finish. You have closed LAB-001 with a report that another technician can follow.

Secret mission

Turn the Fix into a Knowledge-Base Article

Turn your resolved incident into a reusable troubleshooting article for another technician. You will document a safe diagnostic path in KB-Hosts-Override-Troubleshooting.txt without changing the restored system configuration.

Clean Up Your Resources

Clean Up Your Resources

Your restored Windows Hosts file remains safe in its system location. Choose whether to keep the local lab files at no cost, pause your open tools, or delete the lab folder.

Resources you used:

  • The IT-Support-Lab workspace at Desktop\IT-Support-Lab.
  • The protected rollback copy at Desktop\IT-Support-Lab\Hosts Backup\hosts.
  • The completed incident report at Desktop\IT-Support-Lab\incident-report.txt.
  • The reusable knowledge-base article at Desktop\IT-Support-Lab\KB-Hosts-Override-Troubleshooting.txt.

Keep everything running

No action is needed while you keep the lab as a future troubleshooting reference.

  • Retain the Desktop\IT-Support-Lab folder.
  • Keep the backup beside the completed support documents.
  • Redact local IP addresses before sharing the files.
  • Redact DNS server addresses before sharing the files.

Pause - I'll come back to this later

Closing the open tools clears your workspace while preserving every lab file.

  • Close the elevated Windows PowerShell session from earlier.
  • Close any Notepad windows that remain open.

Your report files remain in Desktop\IT-Support-Lab. The restored system configuration remains active.

Delete - I don't want to use this again

Deleting the lab folder can feel final. It removes your saved lab evidence from the Desktop.

  • Use Notepad to review the restored C:\Windows\System32\drivers\etc\hosts file from Step 4.
  • Confirm the file does not contain 192.0.2.1 example.com # IT-support-lab.
  • Return to the elevated Windows PowerShell session from earlier.
  • Repeat the post-fix IPv4 ping test for example.com from Step 4.

You should see an address other than 192.0.2.1 in the opening line. This confirms the rollback is still active.

  • Use File Explorer from earlier to return to the Desktop.
  • Delete the entire IT-Support-Lab folder through File Explorer.
  • Confirm IT-Support-Lab is no longer listed on the Desktop.

Your local lab files are now removed. The restored system Hosts file remains active.

Nice Work!

Nice Work!

You did it! You completed the full help-desk ticket lifecycle on Windows with evidence from the reproduced failure through the verified fix.

You've learned how to:

  • Reproduce a controlled IPv4 name resolution incident. Capture the 192.0.2.1 failure as diagnostic evidence.
  • Identify a local Hosts-file override by comparing Windows local resolution with a direct DNS query. Use DNS client cache evidence to confirm the root cause.
  • Perform a safe rollback with the protected Hosts-file copy. Prove the bad address is gone after clearing the cache. Close LAB-001 with a professional incident report.
  • Secret Mission: Produce a reusable knowledge-base article with diagnosis, rollback, validation, and escalation guidance.

Ready to quiz yourself?