Diagnose a Slow Laptop

Diagnose a simulated DNS outage and document a Tier 1 Windows support ticket.

Introduction

30 Second Summary

When a laptop feels slow, the fastest-looking fix can create a bigger problem. A useful diagnosis starts by separating what the user reports from what the evidence proves.

In this project, you will investigate a fictional expense portal incident. You will turn each finding into a complete Tier 1 ticket from intake through verified closure.

What You'll Build

Picture presenting a finished support ticket that shows how live, read-only checks and controlled evidence narrowed a vague complaint about a slow laptop to one failing DNS server.

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

  • A Task Manager baseline that lets you compare reported slowness with measured CPU, memory, and disk usage.
  • A command-line evidence chain that proves client configuration and IP reachability before testing name resolution.
  • A defensible DNS diagnosis that isolates the preferred server for a safe escalation.
  • Secret Mission: Reject an unauthorized workstation DNS change. Keep the user productive through the approved escalation.

Are there any prerequisites?

You'll need a Windows 11 Home computer with administrator access, a Microsoft account, and study-level familiarity with Windows, TCP/IP, and DNS terminology. All diagnostic tools are built into Windows, so you can move from your phone to the computer without installing software.

Before We Start

This project begins with a simulated Tier 1 ticket on your Windows 11 Home computer. You are committing to evidence-first, read-only troubleshooting that protects your real network configuration.

Set Up Your Tier 1 Workbench

A vague support request can pull a technician into guesses before any facts are recorded. A repeatable workspace gives each observation a home before you form a theory.

Your built-in toolset supplies read-only evidence without changing the real computer. This step creates the private record that keeps that evidence organized.

In this step, get ready to:
  • Create a private ticket record with fixed sections.
  • Verify that the built-in diagnostic tools are available.
  • Capture a read-only baseline for your account and computer.
Create the ticket record

A consistent ticket structure keeps evidence separate from theory. That separation makes every later decision easier to defend.

  • Press the Windows key to open Start search.
  • Type Windows Notepad into the search box.
  • Select Windows Notepad from the search results.
  • Click inside the blank editing area.
  • Add the ticket structure by entering these section headings:
User report

Scope

Evidence

Theory

Actions

Escalation

Verification

User update

Why use fixed sections?

  • User report preserves the original request.
  • Scope records who or what is affected.
  • Evidence stores observations from each check.
  • Theory records the cause supported by the current evidence.
  • Actions records each troubleshooting step.
  • Escalation prepares a handoff when the issue exceeds Tier 1 authority.
  • Verification proves that service has recovered.
  • User update closes the communication loop.
  • Use Notepad's Save as... command to open the Save As dialog.
  • Select Documents as the save location.
  • Enter Help Desk Ticket 001.txt as the file name.
  • Press Enter to complete the save.

You should see Help Desk Ticket 001.txt in Notepad's title area. Your ticket now has a private home in Documents.

Can't find the saved ticket?

Return to Notepad's save option. Confirm that the selected location is Documents.

Check that the file name ends with .txt.

Help me find or save my ticket file.

Open the diagnostic tools

Task Manager gives you a live view of process activity and resource usage. This setup pass remains read-only.

  • Press Ctrl + Shift + Esc to open Task Manager.
  • Select Processes in Task Manager.
  • Select Performance in Task Manager.

You should see process resource columns in Processes. You should see resource graphs in Performance.

What do these views show?

  • Processes lists applications plus background processes with their resource usage.
  • Performance displays graphs for CPU, memory, and other available categories.

The layout can vary slightly across Windows versions. The Processes and Performance names remain your stable landmarks.

Command Prompt provides text-based checks. Event Viewer provides access to Windows event logs.

  • Press the Windows key to return to Start search.
  • Type Command Prompt into the search box.
  • Select Command Prompt from the search results.
  • Press the Windows key to return to Start search.
  • Type Event Viewer into the search box.
  • Select Event Viewer from the search results.

You should see a Command Prompt window ready for input. You should also see Event Viewer open without making any changes to its logs.

Does a tool fail to open?

Close the search results. Search for the tool again using its full name.

Keep the other verified tools open while you retry the missing one.

Help me open a built-in Windows diagnostic tool.

Record the device baseline

A device baseline identifies the computer you are testing before any ticket-specific conclusions exist. These checks only display information.

Keep this baseline private

The next checks reveal your local account name plus network details. Keep Help Desk Ticket 001.txt private.

Do not publish a screenshot of the command output or the completed baseline.

Before you run the checks, consider which command will reveal the most network detail.

  • Run the three read-only baseline checks in Command Prompt by entering:
whoami
hostname
ipconfig /all

What do these commands reveal?

  • The whoami command returns the current domain plus user name.
  • The hostname command displays the computer's host name.
  • The ipconfig /all command displays the full TCP/IP configuration for every adapter.

The first two commands each return a short identity value. The final command returns detailed adapter sections with addressing information.

Can't identify an active adapter?

Look for an adapter section that contains a current IPv4 address plus a default gateway. Ignore disconnected adapter sections.

Help me identify the active adapter safely.

  • Return to Help Desk Ticket 001.txt in Windows Notepad.
  • Record the account name from whoami under Evidence.
  • Record the computer name from hostname under Evidence.
  • Identify the active adapter section in the ipconfig /all output.

Choose the active adapter

Use the adapter section that shows a current IPv4 address plus a default gateway. This keeps disconnected or unused adapters out of your baseline.

  • Record the active adapter name under Evidence.
  • Record the IPv4 address under Evidence.
  • Record the default gateway under Evidence.
  • Record the DNS server fields under Evidence.
  • Save Help Desk Ticket 001.txt.

That's your first evidence chain complete. The ticket now contains local facts without any simulated-case conclusions.

What does this baseline prove?

The baseline identifies the account plus the computer being used for the lab. It also preserves the current adapter details before the simulated investigation begins.

Every command only displayed information. Your real network and system configuration remain unchanged.

  • Return to Task Manager from earlier.
  • Confirm that the Processes view is available.
  • Confirm that the Performance view is available.
  • Return to Command Prompt from earlier.
  • Confirm that the account name, computer name, and TCP/IP details remain visible.
  • Return to Event Viewer from earlier.

You should now have all four Windows tools open or verified. Your private ticket should contain the required sections plus the local baseline.

✔️ Awesome, I've got everything

Your Tier 1 workbench is ready. Keep the ticket private because its Evidence section contains local device information.

ⓧ I'd like to double check the full ticket

Compare Documents/Help Desk Ticket 001.txt with this checkpoint.

These sections should be present:

  • User report.
  • Scope.
  • Evidence.
  • Theory.
  • Actions.
  • Escalation.
  • Verification.
  • User update.

The Evidence section should contain this local read-only baseline:

  • The account name returned by whoami.
  • The computer name returned by hostname.
  • The active adapter name shown by ipconfig /all.
  • The IPv4 address shown for the active adapter.
  • The default gateway shown for the active adapter.
  • The DNS server fields shown for the active adapter.

No simulated-case conclusions should be recorded yet. No real network or system configuration should have changed.

Your workbench is ready for evidence-first troubleshooting. Next, you will turn the reported symptom into a precise problem statement.

Define the Problem and Scope

Your private ticket now holds a read-only baseline from your own computer. That gives Jordan's fictional case a known starting point.

The word “slow” points toward performance. The exact failed task and scope must be clear before any safe action is justified.

In this step, get ready to:
  • Define Jordan's failed task and incident scope.
  • Evaluate the resource-bottleneck theory with Task Manager evidence.
  • Use Event Viewer timeline evidence to choose the next test.
Interview the fictional user

A useful intake turns a broad complaint into facts you can test. Each follow-up question should reduce uncertainty about the task, timing, or scope.

Jordan's Intake

Jordan in Finance reports that the laptop feels slow.

The expense portal has not opened since 09:10.

Normal websites still load. Two nearby coworkers report the same portal problem.

No software or hardware changes were made on Jordan's laptop.

  • Ask Jordan to describe exactly what happens when the expense portal opens.
  • Ask when the issue started.
  • Ask who else is affected.
  • Switch back to the existing Help Desk Ticket 001.txt file in Windows Notepad.
  • Summarize Jordan's report under User report using the facts from the intake.
  • Read the entry to confirm it identifies Jordan's failed task and start time.

Your user report should now identify the expense portal as the failed task. It should place the start of the issue at 09:10.

  • Summarize the breadth of the incident under Scope using the intake evidence.
  • Add the three follow-up questions from the intake callout under Evidence.
  • Read the questions back to confirm each one reduces a specific uncertainty.
  • Record the absence of reported software or hardware changes under User report.

Good work. The intake now supports a focused investigation instead of a guess.

Evaluate the performance claim

Task Manager separates perceived slowness from measurable resource usage. Your live computer teaches you where to find the views while Jordan's controlled snapshot supplies the case evidence.

  • Switch back to Task Manager from your workbench.
  • Select Processes to identify how per-process resource usage is arranged.
  • Select Performance to locate the CPU, memory, and disk categories.

You now know where Windows displays overall resource use and unusually demanding processes. Jordan's simulator snapshot can be evaluated against the reported slowness.

Jordan's Task Manager Snapshot

  • CPU usage is 7%.
  • Memory usage is 52%.
  • Disk usage is 1%.
  • No process is consuming unusually high resources.
  • Compare Jordan's snapshot with the reported slow-laptop symptom.
  • Summarize the complete simulator snapshot under Evidence.
  • State under Theory that the data weakens the workstation resource-bottleneck theory.
  • Read both entries to confirm the measurements support your conclusion.
  • Save Help Desk Ticket 001.txt.

Your ticket now separates Jordan's description from the measured evidence. The current data does not support high resource usage as the cause.

Can't Find Both Views?

Task Manager can look slightly different across Windows versions. Use the stable Processes and Performance view names to orient yourself.

Help me locate the Processes and Performance views in Task Manager.

Correlate the timeline and choose the next test

Event logs can connect a reported start time with application or system failures. Your real logs provide orientation while the fictional timeline controls the incident evidence.

  • Switch back to Event Viewer from your workbench.
  • Locate the Application event log in the navigation pane.
  • Locate the System event log in the navigation pane.

You should now be able to identify both timeline sources. Your computer's events remain separate from Jordan's simulated incident.

  • Leave both event logs unchanged.

Jordan's Event Timeline

The simulator covers the period from 09:05 to 09:20.

The Application evidence contains no matching application crash.

The System evidence contains no matching system failure.

  • Predict whether the evidence supports ending random tasks, restarting immediately, or testing the network path.

Why Network-Path Testing Comes Next

Low resource use weakens the resource-bottleneck theory. The empty matching event window weakens the application-crash and system-failure theories.

The portal issue affects multiple people while normal websites still load. Testing the network path is the next evidence-backed action.

  • Record the simulated event timeline under Evidence.
  • Explain under Theory why the current evidence does not support a workstation resource bottleneck.
  • Read both entries to confirm the timeline and theory agree.
  • Record network-path testing as the next step under Actions.
  • Save Help Desk Ticket 001.txt.

The ticket now explains why random process termination or an immediate restart would be unsupported. Its next action follows the evidence gathered so far.

What Your Problem Statement Needs

  • Name Jordan in Finance as the affected user.
  • Identify the expense portal as the failed task.
  • Place the start of the incident at 09:10.
  • State that normal websites work while two nearby coworkers share the portal issue.
  • Conclude that current evidence does not support a resource bottleneck.
  • Add one problem-statement sentence under Theory using the checklist above.
  • Predict whether a reader could choose the next test from your sentence alone.
  • Read the sentence back to verify that every checklist point is present.

You should hear a precise account of the affected user, failed task, start time, incident scope, and current evidence. The sentence should make clear that the data does not yet support a resource bottleneck.

✔️ My ticket covers every point

Your ticket now turns a vague complaint into a testable problem with a defensible next action.

ⓧ I'd like to double check the ticket

Compare your ticket against this cumulative state:

  • The private ticket remains in Documents with the original eight sections.
  • Evidence retains your local account, computer, adapter, IPv4, gateway, and DNS baseline.
  • User report identifies Jordan in Finance as unable to open the expense portal since 09:10.
  • User report states that no laptop software or hardware changes were reported.
  • Scope states that normal websites still load.
  • Scope states that two nearby coworkers report the same portal issue.
  • Evidence contains three selected intake follow-up questions.
  • Evidence records simulated CPU usage of 7%.
  • Evidence records simulated memory usage of 52%.
  • Evidence records simulated disk usage of 1%.
  • Evidence records that no process has unusually high resource usage.
  • Evidence records no matching simulated Application or System failure from 09:05 to 09:20.
  • Theory states that the data weakens the slow-laptop resource-bottleneck theory.
  • Actions identifies network-path testing as the evidence-backed next action.
  • No real system or network configuration has been changed.

Your ticket has a defined symptom, scope, and evidence-backed direction. Next, you will test IP connectivity before blaming the laptop or Wi-Fi.

Prove IP Connectivity

Jordan's ticket now has a precise scope. Its Task Manager snapshot gives no evidence of a workstation bottleneck.

The Event Viewer timeline shows no matching application crash. Basic IP connectivity is the next fault domain in the evidence chain.

A successful IP path shifts attention to name resolution. Controlled simulator evidence keeps your real Windows 11 configuration untouched.

In this step, get ready to:
  • Validate Jordan's simulated client configuration.
  • Interpret the lossless IP test for each target.
  • Choose the next theory from the full evidence chain.
Validate the simulated client configuration

A client baseline shows whether later test results start from plausible values. The simulator supplies four fields for Jordan's adapter.

Jordan's Simulated Configuration

The IPv4 address is 10.20.30.44. The subnet mask is 255.255.255.0.

The default gateway is 10.20.30.1. The preferred DNS server is 10.20.30.53.

  • Switch back to Documents/Help Desk Ticket 001.txt in Windows Notepad.
  • Add all four simulated fields to the Evidence section.

You should now see one fictional client baseline beneath your live read-only baseline.

  • Label every required field as present.
  • Label the configuration as internally consistent for this scenario.

Your Evidence section now separates Jordan's simulator data from your own device data.

  • Save Documents/Help Desk Ticket 001.txt.

Good work. The ticket now has a controlled baseline for every network test that follows.

Interpret the gateway and portal tests

The ping command tests IP-level connectivity with ICMP echo traffic. A reply proves that the target answered across the tested path.

  • Review the supplied simulator result for ping 10.20.30.1.
  • Record four successful replies with zero packet loss in Evidence.

You should now see the gateway test recorded as lossless.

  • Review the supplied simulator result for ping 10.20.30.10.
  • Record four successful replies with zero packet loss in Evidence.

You should now see the portal-server test recorded as lossless.

What Do the Replies Prove?

The gateway replies show that Jordan's client can reach its default gateway by IP. The portal-server replies show that the client can reach 10.20.30.10 by IP.

ICMP success confirms only the tested echo traffic. It cannot prove that every application service is healthy.

  • Add a Theory sentence stating that IP connectivity to the gateway works.
  • Add a second Theory sentence stating that IP connectivity to the portal server works.

Your Theory section should now preserve both reachability conclusions.

  • Add the ICMP limitation from the callout to Theory.
  • Save Documents/Help Desk Ticket 001.txt.

That distinction is the key result. You have proved a working IP path without overclaiming portal health.

Commit to the next theory

A defensible theory must fit every result already in the ticket. The candidates are failed Wi-Fi, an overloaded laptop, or name resolution.

Decision Feedback

Name resolution is the defensible choice. Successful IP tests weaken failed Wi-Fi.

The earlier resource data weakens the overloaded-laptop theory. The unresolved failure by portal name points toward direct DNS testing.

  • Go to the Theory section in your ticket.
  • Replace the general network-path next action with a sentence naming name resolution as the leading theory.

Your Theory section now identifies the remaining fault domain.

  • Go to the Actions section in your ticket.
  • Record direct DNS testing as the next action.

Your ticket now points to a specific next test.

  • Save Documents/Help Desk Ticket 001.txt.

Before the final review, which theory do you expect the full evidence chain to support?

  • Read the Evidence section from the simulated configuration through both ping results.
  • Read the Theory section from the resource conclusion through the leading theory.
  • Confirm that no real network configuration was changed.

You should see all four configuration fields marked as present. The ticket should describe the configuration as internally consistent.

Evidence should record four lossless replies from each IP target. Theory should identify name resolution as the leading explanation.

Theory should also preserve the ICMP limitation. The ticket should still state that no real configuration changes were made.

✔️ My ticket matches the evidence

Solid work. Your ticket now proves IP reachability while preserving the limit of that evidence.

ⓧ I'd like to double check my ticket

This checkpoint mirrors the required ticket state.

  • Confirm that User report identifies Jordan in Finance with an expense portal failure at 09:10.
  • Confirm that Scope records working normal websites. It should record two affected coworkers. It should record no reported laptop changes.
  • Confirm that Evidence retains the intake questions. It should retain the resource snapshot. It should retain the event timeline. It should retain the private local baseline.
  • Confirm that Evidence records 10.20.30.44 as the simulated IPv4 address. It should record 255.255.255.0 as the subnet mask. It should record 10.20.30.1 as the default gateway. It should record 10.20.30.53 as the preferred DNS server.
  • Confirm that both simulated ping records show four successful replies with zero packet loss. The targets should be 10.20.30.1 plus 10.20.30.10.
  • Confirm that Theory states that the resource evidence weakens the slow-laptop theory.
  • Confirm that Theory states that both IP targets are reachable. It should preserve the ICMP limitation. It should identify name resolution as the leading theory.
  • Confirm that Actions names direct DNS testing as the next action. The ticket should still state that no real configuration changes were made.

Your ticket now rules in a working IP path without blaming the laptop or Wi-Fi. Next, you will test name resolution directly.

Isolate the DNS Failure

Your ticket now shows that Jordan's laptop can reach the gateway and portal server by IP. The next goal is to find why the portal still fails by name.

Name resolution is the leading theory. A client-side DNS cache reset gives that theory a low-impact first test.

In this step, get ready to:
  • Test the simulated client DNS cache reset.
  • Compare direct queries to the preferred and alternate DNS servers.
  • Document the isolated root cause.
Test the client cache theory

The client resolver cache stores recent DNS results. Resetting it tests whether stale cached data is blocking the portal name.

  • Switch back to Documents/Help Desk Ticket 001.txt in Windows Notepad.
  • Scroll to the Actions section.

Before you reveal the simulator result, do you expect clearing cached DNS data to restore the portal name?

  • Review the simulated cache action shown below. Keep this test inside the supplied evidence:
ipconfig /flushdns

What Does This Simulated Action Test?

The action flushes the DNS client resolver cache. It can remove negative cache entries that preserve an earlier lookup failure.

A completed reset proves that the cache was cleared. The next portal check shows whether cached data caused the symptom.

  • Reveal the cache-reset result in the simulator evidence.

You'll see that the reset completes. The portal name still does not resolve.

This shortfall is intentional. The action changed the client cache while the underlying fault remained.

  • Record the cache-reset outcome under Actions. State that the simulated reset completed but portal resolution did not recover.
  • Save Help Desk Ticket 001.txt.

Your Actions section now preserves the attempted quick fix and its visible result. The client-cache theory no longer explains the failure.

Query the preferred DNS server

A direct nslookup query diagnoses DNS infrastructure without using the client's DNS cache. Naming the server sends the query to that specific server.

  • Review the simulated preferred-server query shown below. Keep the result hidden until after the prediction:
nslookup portal.example.com. 10.20.30.53

What Does This Direct Query Test?

  • The first value identifies the portal name being queried.
  • The second value selects the preferred DNS server at 10.20.30.53.
  • The direct query bypasses the client resolver cache.

Before you reveal the result, do you expect the preferred server to return the portal address or fail to answer?

  • Reveal the preferred-server result in the simulator evidence.

You'll see a timed out result. The preferred server did not respond within the query's allowed time.

  • Record under Evidence that the direct query to 10.20.30.53 timed out.
  • Save Help Desk Ticket 001.txt.

Your Evidence section now connects the failed portal lookup to the preferred DNS server. The browser symptom has a direct infrastructure test behind it.

Compare the approved alternate server

A controlled comparison keeps the portal name unchanged. Only the DNS server address changes.

  • Review the simulated alternate-server query shown below. Keep the result hidden until after the prediction:
nslookup portal.example.com. 10.20.30.54

Why Compare the Alternate Server?

  • The queried portal name stays identical.
  • The server changes from 10.20.30.53 to 10.20.30.54.
  • The comparison isolates how each DNS server handles the same record.

Before you reveal the alternate result, do you expect another timeout or a portal address?

  • Reveal the alternate-server result in the simulator evidence.

You'll see 10.20.30.10 returned for the same portal name. The approved alternate server resolves the record successfully.

You've found the decisive split. One DNS server fails while the approved alternate resolves the same name.

  • Record under Evidence that the query to 10.20.30.54 returned 10.20.30.10.
  • Save Help Desk Ticket 001.txt.

Your Evidence section now contains both sides of the DNS comparison. The same record succeeds when the responding server changes.

  • Write one root-cause statement under Theory. Identify 10.20.30.53 as the failing shared component. Rule out a bad portal record based on the alternate response. Rule out a general network outage based on the successful IP tests. Rule out Wi-Fi and workstation performance based on the earlier scope and resource evidence.
  • Save Help Desk Ticket 001.txt.

Your Theory section should now name one failing component and connect every rejected theory to evidence. That makes the diagnosis defensible.

Before you perform the final check, which conclusion should the full evidence chain support?

  • Review Actions to confirm the failed simulated cache reset is recorded.
  • Review Evidence to confirm both direct DNS query results are recorded.
  • Review Theory to confirm the preferred DNS server is identified as the shared failure.

You should see a completed cache reset with no recovery, a timeout from 10.20.30.53, and a successful response from 10.20.30.54. Together, those results isolate the preferred DNS server.

✔️ My DNS evidence is complete

Your ticket now contains the cache test, direct server comparison, and evidence-backed root cause.

ⓧ I'd like to double check the full ticket

Compare your cumulative ticket state with this reference. Keep the real local values you recorded during setup.

Private local Tier 1 ticket record with sections: User report, Scope, Evidence, Theory, Actions, Escalation, Verification, and User update. Evidence contains the learner's local read-only baseline: whoami account name, hostname computer name, active adapter name, IPv4 address, default gateway, and DNS server fields. User report and Scope record that Jordan in Finance cannot open the expense portal since 09:10; normal websites work; two nearby coworkers report the same portal problem; and no laptop software or hardware changes were made. Evidence records three selected intake follow-up questions, simulated CPU 7%, memory 52%, disk 1%, no unusually high process, and no matching simulated Application or System failure from 09:05 to 09:20. Theory states that the data weakens the slow-laptop/resource-bottleneck theory. Evidence records Jordan's simulated IPv4 address 10.20.30.44, subnet mask 255.255.255.0, default gateway 10.20.30.1, and preferred DNS server 10.20.30.53 as present and internally consistent; four successful, lossless ping replies to 10.20.30.1 and 10.20.30.10; and the conclusion that IP connectivity works while name resolution requires testing. Actions records simulated ipconfig /flushdns, which completed but did not restore portal resolution. Evidence records nslookup portal.example.com. 10.20.30.53 timed out and nslookup portal.example.com. 10.20.30.54 returned 10.20.30.10. Theory identifies preferred DNS server 10.20.30.53 as the failing shared component, not the portal record, general network, Wi-Fi, or workstation. No real configuration changes made.

How to Use This Reference

Use the reference as a cumulative content checklist. Your private baseline should retain the local values from your own computer.

Your evidence now isolates the preferred DNS server without changing Jordan's workstation. Next, you'll escalate the shared failure and verify the simulated recovery.

Escalate, Verify, and Close

Your DNS comparison has isolated preferred server 10.20.30.53 as the failing shared component.

A change on Jordan's workstation would mask one symptom. The shared service would stay broken for other users.

This step turns your evidence into an actionable escalation. You will verify recovery before closing the ticket.

In this step, get ready to:
  • Build an evidence-backed handoff for the network team.
  • Capture two-layer recovery evidence.
  • Close the ticket with a plain-language user update.
Write the escalation handoff

An evidence-backed escalation gives the next team enough detail to act without repeating your investigation. It also records the safety boundary you maintained.

  • Switch back to Documents/Help Desk Ticket 001.txt in Windows Notepad.
  • Place your cursor under the Escalation heading.
  • Record the affected scope as Jordan in Finance plus two nearby coworkers.
  • Record 09:10 as the incident start time.
  • Summarize the working IP path from the successful tests to 10.20.30.1 and 10.20.30.10.
  • Record that preferred server 10.20.30.53 timed out.
  • Record that approved alternate server 10.20.30.54 returned 10.20.30.10 for portal.example.com..
  • Summarize the completed cache reset that did not restore portal name resolution.

What makes this handoff actionable?

The affected scope shows that the incident reaches beyond one workstation. The start time gives the network team a precise investigation window.

The working IP path narrows the fault away from general connectivity. The direct server comparison points to 10.20.30.53.

The unchanged-configuration note preserves a clear safety boundary. Your escalation passes evidence forward without creating another fault.

  • Request that the network team investigate preferred server 10.20.30.53.
  • Confirm that the adapter, firewall, and server configurations remained unchanged.
  • Save Documents/Help Desk Ticket 001.txt.
  • Read the completed Escalation section from top to bottom.

That is a solid Tier 1 handoff. The network team can act without repeating your investigation.

Verify the simulated repair

A reported repair needs evidence before the incident can close. You need one technical check plus one user check.

Before you reveal the repair evidence, predict whether the original preferred server answers now.

  • Review the simulator's new recovery result for preferred server 10.20.30.53.

You see the restored server resolve portal.example.com. to 10.20.30.10.

  • Record the restored preferred-server result under Verification.
  • Review the simulator's portal check from Jordan.

Jordan successfully opens the expense portal.

Why verify twice?

The successful server response proves that name resolution has recovered. It directly tests the component identified in your theory.

Jordan's portal check proves that the original failed task works again. Together, these checks support closure.

  • Record Jordan's successful portal check under Verification.
  • Save Documents/Help Desk Ticket 001.txt.
  • Reread the Verification section.

You should see both the restored DNS result and Jordan's successful portal check. Your recovery evidence now covers the service plus the user's task.

Close the communication loop

A user update translates the technical recovery into a clear outcome. The ticket closes only after Jordan confirms that access works.

  • Place your cursor under the User update heading.
  • Write one plain-language sentence stating that expense portal access is restored.
  • Ask Jordan to confirm that the expense portal opens.
  • Review Jordan's simulated response.

Jordan confirms that the expense portal opens successfully.

  • Record Jordan's confirmation under User update.
  • Mark the ticket status as closed.
  • Save Documents/Help Desk Ticket 001.txt.

Before you read the ticket from top to bottom, decide which missing field would keep the case open.

  • Read the completed ticket from the user report through the closed status.

You should see a complete chain from reported symptom to confirmed recovery. The closed status should appear only after Jordan's confirmation.

✔️ My ticket is complete

Your ticket contains the scope, evidence, escalation, recovery checks, user confirmation, and closed status.

ⓧ I'd like to double check the full ticket

  • Confirm the opening sections capture Jordan's portal problem, the 09:10 start time, normal website access, and two nearby affected coworkers.
  • Confirm Evidence covers normal resource usage, the event timeline, working IP connectivity, and the direct DNS comparison.
  • Confirm Actions records the completed cache reset that did not restore name resolution.
  • Confirm Theory identifies preferred server 10.20.30.53 as the failing shared component.
  • Confirm Escalation requests network-team investigation of 10.20.30.53 while recording that no configuration was changed.
  • Confirm Verification records that restored server 10.20.30.53 resolves portal.example.com. to 10.20.30.10.
  • Confirm User update states that access is restored, requests confirmation, and records Jordan's successful check.
  • Confirm the ticket ends with a closed status while preserving the note that no real configuration changes were made.
  • Scroll to the Escalation section so the final ticket sections fill the Notepad window.
  • Keep your local baseline details outside the screenshot frame.

Case closed. Your ticket now shows how evidence led to a safe escalation, verified recovery, and professional closure.

Secret mission

Reject the Unauthorized Shortcut

A technician proposes manually changing Jordan's adapter to an unapproved DNS server. Your challenge is to reject the shortcut while preserving the evidence, the approved escalation path, and a calm user update.

Clean Up Your Resources

Clean Up Your Resources

This local project has no cloud resources or ongoing costs. The only cleanup choice concerns a ticket file that can contain local identity details.

Resources you used:

  • A local ticket file at Documents/Help Desk Ticket 001.txt. It may contain local identity details plus network evidence.

Keep everything running

No action is needed. This option keeps your closed ticket available for later review.

  • Keep Help Desk Ticket 001.txt in Documents as a private practice record.
  • Remove local identity details from any copy you plan to share.
  • Remove network evidence from any copy you plan to share.
  • Leave your Windows settings unchanged because the project made no real configuration changes.

Pause - I'll come back to this later

Pause by closing the ticket while keeping the file in place. You can resume from the same Windows computer later.

  • Save Help Desk Ticket 001.txt in Windows Notepad.
  • Close Windows Notepad.
  • Keep Help Desk Ticket 001.txt in Documents until you are ready to continue.

Delete - I don't want to use this again

Deleting the ticket becomes permanent after the Recycle Bin is emptied. This cleanup affects only the ticket file.

  • Close Help Desk Ticket 001.txt in Windows Notepad.
  • Press the Windows key to open search.
  • Type Documents into search.
  • Select the Documents folder from the results.
  • Right-click Help Desk Ticket 001.txt.
  • Select Delete.
  • Open Recycle Bin from the Windows desktop.
  • Empty the Recycle Bin.
  • Confirm the permanent deletion when Windows asks.

You should no longer see Help Desk Ticket 001.txt in Documents or the Recycle Bin.

Nice Work!

Nice Work!

Case closed! Your Tier 1 record traces Jordan's portal incident from a vague report to a verified recovery without changing your real Windows configuration.

You've learned how to:

  • Apply the CompTIA troubleshooting methodology to build a complete Tier 1 case file from user intake through verified closure.
  • Use Task Manager resource data plus Event Viewer timeline evidence to reject an unsupported performance theory.
  • Build an IP-to-DNS evidence chain that justifies escalation of the failed shared server at 10.20.30.53.
  • Complete the optional Secret Mission by rejecting an unauthorized adapter DNS change while preserving the approved escalation path.

Ready to quiz yourself?