Week 18: Technician Service Challenge

A technician rarely receives a perfect little problem with one bad component and one obvious answer.

Real support is messier.

The computer may be fine while the account is wrong. The printer may work while the queue is stale. The Wi-Fi may be strong while DNS is broken. A security control may be doing exactly what it was designed to do while the user experiences that control as a failure.

This final week puts those systems in the same room.

The client

Harborview Community Learning Lab is opening a six-seat technology room for:

• schoolwork;
• job applications;
• browser-based services;
• video meetings;
• basic media creation;
• printing and scanning;
• staff administration.

The supplied environment includes:

6 desktop workstations
1 staff laptop
1 managed mobile device
1 multifunction printer/scanner
1 SOHO router/firewall
1 wireless access point
cloud productivity/email/storage
1 local practice VM
fictional accounts, logs, screenshots, diagrams, and tickets

Nothing in the capstone uses real credentials, student records, malware, external targets, or managed school infrastructure.

The systems are fictional.

The reasoning is real.

The client requirements

Harborview does not care which A+ objective you memorized.

It cares that the lab works.

The environment must support:

• normal office and school productivity;
• browser-based services and video meetings;
• shared printing and scanning;
• wired desktop connectivity;
• staff and managed-mobile Wi-Fi;
• standard-user daily accounts;
• an approved administrative support path;
• MFA on staff/cloud accounts;
• endpoint protection and firewall controls;
• disk/data protection;
• backup and recovery;
• safe service procedures;
• documented changes;
• privacy-safe support records.

Those requirements are the authority for every decision this week.

A technically impressive configuration that violates one of them is still wrong.

The capstone system

Think of Harborview as one dependency map:

people + requirements
        ↓
accounts + permissions
        ↓
endpoints + mobile + printer
        ↓
local network + Wi-Fi
        ↓
DNS / services / cloud
        ↓
applications + data
        ↓
backup / recovery
        ↓
security + operations

Every incident in the capstone breaks or misconfigures one part of that path while other parts remain healthy.

Your job is to find the first unsupported assumption.

How the week moves

Lesson 1: Intake, Inventory, and Baseline

Before changing anything, learn what the client owns, what the systems are supposed to do, what is already working, and which safety/privacy boundaries apply.

The baseline becomes your reference point for every later claim.

Lesson 2: Configure the Service Environment

Turn the client's requirements into bounded hardware, network, printer, mobile, OS/application, security, cloud/VM, backup, and support decisions.

The goal is not maximum technology.

The goal is a supportable system.

Lesson 3: Diagnose the Seeded Faults

The environment develops several problems from across the course.

You will not be told whether each one is Core 1, Core 2, hardware, networking, Windows, security, or operations.

You will receive evidence.

Use it.

Lesson 4: Security, Recovery, and Verification

A repaired system is not finished until required access works, prohibited access remains blocked, backups can actually restore data, endpoint controls remain healthy, and unresolved risks are documented.

Lesson 5: Service Record and Technical Briefing

You will hand the environment back to the client.

That means explaining:

• what you found;
• what you changed;
• why you changed it;
• what you verified;
• what remains unresolved;
• what the client needs to know next.

The evidence spine

Use the same chain throughout the capstone:

client requirement
→ baseline
→ service/configuration decision
→ incident evidence
→ theory
→ controlled correction
→ rollback/recovery
→ security/privacy review
→ functional verification
→ service record
→ client briefing

If one arrow is missing, the work is not complete.

The capstone is not a shopping list

You do not earn a stronger design by adding more technology.

Examples:

• RAID is unnecessary if it solves no stated availability requirement.
• Permanent administrator rights are unnecessary if only occasional maintenance requires elevation.
• A VM does not need bridged networking if the practice environment is supposed to remain isolated.
• A port-forward rule does not belong on the router because an application might need it someday.
• A cloud-sync client is not a backup merely because files exist in two places.

Every component, setting, and control should connect to a requirement.

The capstone is not a wipe-and-rebuild contest

Several seeded faults have narrow solutions.

A no-POST memory problem does not require Windows reinstallation.

A stale print queue does not require replacing the printer.

A DNS failure does not require resetting the entire network.

A plugin regression does not require reimaging the workstation.

A policy-controlled mobile setting does not justify removing management.

An unexpected MFA prompt does not justify disabling MFA.

The course has spent seventeen weeks teaching you not to skip the middle.

Do not start now.

What a successful final environment proves

At the end of Week 18, another technician should be able to inspect your evidence and answer:

What did Harborview require?
What was the baseline?
Which decisions satisfy those requirements?
Which faults occurred?
What evidence isolated each fault?
What changed?
How could the change be reversed?
What security/privacy boundaries remain?
Can required data be restored?
Does the final environment perform the required work?
What remains unresolved or outside local control?

If those answers exist only in your head, the capstone is not finished.

The final artifact is not a slideshow.

It is a defensible service state.