Lesson 5: Windows Technician Practical

Real Windows tickets do not arrive labeled:

Use Disk Management now.

They arrive as:

The new drive is missing.

The setting keeps changing back.

The mapped drive stopped working.

This machine needs encryption and domain management.

Windows is broken after an update.

Your job is to locate the responsibility before choosing the tool.

Ticket 1: edition mismatch

Requirements:

domain join
BitLocker
central policy
inbound Remote Desktop host
supported TPM/UEFI platform

Hardware is adequate.

The proposed Windows edition does not provide all required features.

What failed?

The edition/capability decision.

Do not troubleshoot Group Policy or firewall rules before confirming the operating system can support the required role.

A running installation can still be the wrong deployment.

Ticket 2: thirty-laptop rollout

Requirements:

30 similar laptops
same approved Windows baseline
organization network available
minimal technician touch
no user data yet

Manual USB installation would work.

That does not make it the strongest operational choice.

Compare manual local installation, prepared imaging, remote/network deployment, and zero-touch provisioning.

A strong plan identifies:

• why the selected method fits the scale;
• what network or deployment service it depends on;
• how the baseline stays maintained;
• how failed provisioning is recovered.

Efficiency without recoverability is not deployment architecture.

Ticket 3: new drive missing from File Explorer

Evidence:

firmware: drive detected
Device Manager: device present
Disk Management: disk visible
volume: unallocated / not mounted
File Explorer: drive missing

The first failed boundary is Windows storage configuration.

The hardware path has already been proven farther than the user realizes.

Do not replace the disk because Explorer does not show a drive letter.

Ticket 4: nightly CPU spike

Evidence:

Task Manager: CPU spike near 02:00
Task Scheduler: approved job at 02:00
Event Viewer: task launch recorded at 02:00
performance returns to normal afterward

Is malware impossible?

No.

Is it the strongest current explanation?

Also no.

The scheduled task matches the timing and behavior.

Evidence should make one theory stronger and another weaker.

Ticket 5: mapped drive stopped working

Evidence:

client IP / gateway / DNS: normal
server: reachable
\\fileserver\media: works directly
Z: mapping: points to \\old-fileserver\media

The file server is not the first failed boundary.

The mapping is stale.

Use the mapped-resource view or net use concept.

Do not change DNS because a drive letter points to the wrong path.

Ticket 6: local setting keeps returning

Evidence:

user changes setting
setting returns after policy refresh
gpresult: controlling policy applied

Windows is not forgetting.

Policy is doing its job.

The correct response may be to document the requirement, identify policy ownership, and request or escalate a policy change if appropriate.

Repeated local editing is not a fix when local state is not authoritative.

Ticket 7: one approved application is blocked

Evidence:

network: healthy
other applications: normal
required local communication path: documented
Defender Firewall: relevant app/rule path blocked

Do not disable the firewall globally.

Design the smallest justified exception under the approved scenario.

Then verify:

• the required application path works;
• unrelated firewall protection remains intact.

A fix that removes the entire control is not automatically a good fix.

Ticket 8: damaged Windows installation

Evidence:

hardware: healthy
user-data backup: verified
recovery environment: available
system-file damage: supplied evidence
clean install: not yet justified

A repair or recovery-first approach may preserve more state.

Possible sequence:

confirm backup
  ↓
inspect error / recovery state
  ↓
use supported repair or system-file recovery path
  ↓
retest boot + required functions
  ↓
escalate to reimage / clean install if integrity remains untrustworthy

Do not reach for destructive installation because it feels decisive.

Use the least disruptive action that still produces a trustworthy system.

Ticket 9: user cannot reach an approved network share

Evidence:

IP configuration: valid
DNS: valid
server: reachable
UNC path: access denied
current identity: verified

Now you have moved past basic networking.

Investigate:

• share/path correctness;
• permissions;
• account or group membership;
• domain/workgroup context;
• policy.

A reachable server does not prove authorization to the resource.

Ticket 10: USB device disappears after idle

Evidence:

device works after reconnect
physical port: stable
symptom begins after idle period
USB selective suspend: enabled in supplied power plan

Power-management configuration becomes a reasonable hypothesis.

Do not replace the motherboard before testing the power-policy boundary.

Settings can create symptoms that look like hardware failure.

Ticket 11: laptop has internet, but VPN cannot connect

Evidence:

Wi-Fi: connected
IP configuration: valid
DNS: working
normal websites: reachable
VPN: fails to establish

The local network path is healthy enough for general internet use.

Move toward the VPN-specific configuration, authentication, client, remote endpoint, or policy boundary.

Do not keep changing Wi-Fi settings because the VPN is a higher-layer dependency.

Ticket 12: application works on Ethernet but not on a metered WWAN path

Evidence:

WWAN: connected
internet: available
connection: marked metered
background synchronization: paused by supplied configuration

This may be expected behavior, not broken connectivity.

The technician needs to identify the metered policy and the application's actual requirement before changing network state.

Build four full Windows service records

Choose four tickets from different categories and document:

user requirement / symptom
Windows layer involved
last proven-good boundary
first failed or uncertain boundary
best tool / command / Settings surface
why that tool fits
inspection vs state change
risk / backup / rollback concern
controlled correction
verification of original requirement
remaining uncertainty

Do not choose four networking cases.

Show that you can move across:

• edition and feature support;
• deployment and storage;
• process, event, and performance evidence;
• policy and identity;
• networking, VPN, proxy, and firewall;
• recovery.

The Windows mental model

By now, a Windows machine should look like layers of responsibility:

hardware + firmware
      ↓
boot / partition / filesystem
      ↓
Windows edition + version
      ↓
drivers + services
      ↓
users + groups + policy
      ↓
network + firewall + proxy
      ↓
applications + data

The interface may hide those layers behind Settings pages and consoles.

Your job is to keep the architecture visible anyway.

Next we leave Windows-only support and compare macOS, Linux, filesystems, applications, and cloud productivity without pretending every operating system uses the same tools.