Lesson 1: Intake, Inventory, and Baseline

The fastest way to create a bad support plan is to start changing things before you understand the client.

Harborview Community Learning Lab has hardware, accounts, cloud services, printers, Wi-Fi, data, and users who expect all of it to work together.

Before you touch configuration, build the baseline.

Intake answers what the client actually needs

The client brief is not background decoration.

It defines success.

Harborview needs:

• six usable desktop stations;
• one staff laptop;
• one managed mobile device;
• shared print/scan capability;
• wired desktop networking;
• staff/mobile Wi-Fi;
• browser-based productivity and video meetings;
• standard-user daily accounts;
• controlled administrator access;
• MFA for staff/cloud identity;
• endpoint protection and firewall controls;
• backup/recovery;
• privacy-safe records;
• supportable changes.

Every later decision should point back to one of those requirements.

If it does not, ask why the technology is there.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

Inventory is more than counting devices

An inventory should tell another technician what exists and what matters about it.

For each asset, record information such as:

asset ID
asset type
model / platform
assigned role
operating system
important hardware
network method
security/management state
serviceability notes
warranty / lifecycle clue
required client function

A useful inventory does not say:

Desktop 1.

It says something closer to:

HCL-WS01, student desktop, Windows 11 Pro, wired Ethernet, 16 GB RAM, NVMe system drive, standard-user station, endpoint protection enabled, used for browser productivity and video meetings.

The second record tells you why the asset exists.

Compatibility belongs in the baseline

Before support begins, verify that the system design is internally plausible.

Examples:

Workstations

Check:

• CPU/platform support;
• RAM generation/capacity;
• storage interface;
• graphics/display requirements;
• network capability;
• Windows edition/version requirements;
• camera/microphone availability for video meetings.

Staff laptop

Check:

• battery/service condition;
• Wi-Fi capability;
• docking or peripheral requirements;
• encryption support;
• managed account/security state.

Printer/MFP

Check:

• Ethernet/Wi-Fi/USB role;
• driver/support path;
• scan destinations;
• ADF/flatbed requirement;
• secured-print/privacy requirement if used.

Managed mobile device

Check:

• OS support state;
• Wi-Fi/cellular capability;
• MDM/profile state;
• encryption;
• screen-lock policy;
• synchronization requirement.

Compatibility is still a chain.

Week 2 never stopped being relevant.

Build the network dependency map before troubleshooting it

Harborview's network can be represented like this:

internet/provider
      ↓
SOHO router/firewall
      ↓
local switch / LAN
   ├── desktop workstations
   ├── printer/MFP
   └── wireless AP
          ├── staff laptop
          └── managed mobile device

Above the IP path sit services:

DHCP
DNS
cloud identity
cloud productivity/email/storage
printing/scanning
video meeting service

A user may experience one application failure even while everything below it works.

The map gives you somewhere to place that failure later.

Cloud service is still part of the client system

Harborview uses cloud productivity, email, and storage.

That adds dependencies:

Trace those dependencies on the persistent Harborview topology above; the environment is the same even when the active service path changes.

Do not write cloud: working as one baseline checkbox.

Separate the layers.

A user may sign in successfully while lacking the correct license.

Cloud storage may be available while one folder is excluded from synchronization.

Video meetings may work while microphone permission is denied locally.

The cloud did not make troubleshooting disappear.

It moved some boundaries.

The practice VM has a specific purpose

The local practice VM exists for software/testing support.

That means you need to know:

• host resources;
• guest OS;
• virtual disk location;
• virtual NIC state;
• network mode;
• snapshot/backup role;
• whether external access is required.

Do not change the VM to bridged/external networking just because external internet sounds more useful.

The network mode should match the practice requirement.

A host-only VM can be healthy and intentionally isolated.

Safety boundaries are part of intake

Before any service work, identify stop conditions.

Examples:

• swollen battery;
• burning smell;
• liquid exposure;
• damaged power connection;
• visibly damaged electrical component;
• printer fuser or hot internal mechanism;
• unsupported physical service procedure.

A capstone should not reward unsafe curiosity.

If the evidence already says stop, more testing is not better testing.

Privacy boundaries are part of intake too

Harborview uses fictional accounts and records, but the support model should still respect real privacy principles.

Do not include in support notes:

• passwords;
• MFA codes;
• unnecessary personal content;
• private message contents;
• full confidential documents;
• unrelated screenshots.

Record the evidence needed to support the ticket.

Not everything the technician can see belongs in the record.

Authorization defines what you may change

For each system, identify who owns the configuration.

Examples:

• Windows local setting may be controlled by central policy;
• mobile setting may be controlled by MDM;
• cloud account access may be controlled by identity administration;
• router/firewall settings may require network-owner approval;
• remote-support access requires an authorized ticket/session.

The question is not merely:

Can I change this?

It is:

Am I the correct person to change this under the client process?

Baseline evidence should be observable

A baseline is not:

Everything looks good.

A stronger baseline uses inspectable evidence.

Workstation baseline

Possible evidence:

POST: normal
Windows boot: normal
RAM/storage detected as expected
Device Manager: no supplied critical warning
wired link: up
valid IP/gateway/DNS
cloud sign-in: works
browser productivity: works
video-meeting camera/mic test: works

Printer baseline

printer network: reachable
internal test page: correct
shared queue: available
print test: correct
scan test: reaches approved fictional destination

Staff laptop baseline

battery: no swelling/damage
Windows: supported
Wi-Fi: associated
valid IP configuration
MFA sign-in: normal
BitLocker/encryption: required state present
endpoint protection/firewall: healthy

Mobile baseline

screen lock: compliant
MDM: enrolled
Wi-Fi: working
encryption: enabled
sync: expected services working
updates: required state current

VM baseline

host resources: normal
VM boots
virtual NIC: connected
network mode: documented
required allowed destinations: work
required isolated destinations: remain isolated

Baseline does not mean “prove every feature in the universe”

Test the requirements Harborview actually depends on.

If the lab does not use optical media, you do not need a 20-minute optical-drive certification ritual.

If the printer is not configured for fax, do not invent a fax requirement.

Scope keeps the baseline useful.

Worked intake problem: printer is reachable but scanning requirement is unknown

Suppose:

printer prints normally
MFP network: reachable
ADF: present
client brief: requires shared scanning
scan destination: not documented

Is the baseline complete?

No.

The hardware exists, but the required scan path is still unproven.

The missing information becomes a requirement/configuration question for Lesson 2.

Do not call it a failure yet.

You simply do not have enough evidence.

Worked intake problem: six workstations, one different RAM configuration

Inventory shows:

WS01-WS05: 16 GB supported configuration
WS06: 8 GB + unmatched additional module
system currently boots

Does booting prove the configuration is ideal or fully supported?

No.

Record the variance and verify the board/platform memory requirements before changing anything.

The baseline captures abnormal state even when it has not yet caused a visible incident.

Build the Harborview baseline packet

Create:

Asset inventory

asset ID:
role:
platform:
important hardware:
network path:
security/management state:
required client function:
serviceability/compatibility note:

Requirement matrix

client requirement:
assets/services involved:
current evidence:
proven / unproven / not applicable:
remaining question:

Dependency map

Include:

• endpoints;
• printer;
• mobile;
• router/firewall;
• access point;
• DNS/DHCP;
• cloud identity/service;
• VM;
• backup/recovery.

Boundary record

safety stop conditions:
privacy restrictions:
authorization boundaries:
managed-policy owners:
external/provider dependencies:

Before you move on

The baseline does three things:

1. tells you what Harborview needs;
2. tells you what the environment currently proves;
3. tells you what you are not authorized to assume.

That becomes your reference point for every configuration and every incident that follows.

Next, you turn the requirements into a supportable target state.