Lesson 2: Configure the Service Environment

Yesterday you established what Harborview owns and what it needs.

Today you turn those requirements into a target state.

This is where technicians get into trouble if they confuse possible with appropriate.

A system can support more RAM, more services, more open ports, more administrator access, more cloud applications, and more automation.

That does not mean it should.

Configuration is about choosing the smallest design that satisfies the client requirement and remains supportable.

Start with the workstation role

Harborview's six desktops are general-purpose community workstations.

They need to support:

• browser productivity;
• schoolwork;
• job applications;
• video meetings;
• basic media creation;
• shared printing.

That workload should drive the configuration.

A workstation does not need a high-end discrete GPU merely because one fits in the case.

It does need enough CPU, RAM, storage, graphics capability, camera/microphone support, networking, and OS compatibility for the required applications.

A strong decision sounds like:

The workstation keeps the supported integrated graphics configuration because the client workload does not require a dedicated GPU, while 16 GB RAM and NVMe storage satisfy the expected browser, meeting, and basic media workload with operating headroom.

That is more useful than:

Integrated graphics is cheaper.

Cost matters, but it is not the only system requirement.

Visual reference

See the system before you troubleshoot it

reference sheetTechnician Service Challenge Packet

Harborview · target

Translate requirements into testable state

Every proposed configuration needs an acceptance test and a rollback path.

1. 01
   Service paths

   Define required wired, wireless, print/scan, VM, identity, and cloud paths.

2. 02
   Controls

   Define least privilege, update, logging, and data-handling expectations.

3. 03
   Recovery

   Define what must restore, from where, and how success will be proven.

Harborview persistent environment

Harborview service environment: isolate the failing boundary

Use the Week 18 client environment as one connected service system. Trace the affected path before changing hardware, networking, operating-system, security, or service state.

Baseline environmentSeeded fault ASeeded fault BReset layout

1. predict2. run3. inspect4. compare

Predict before you run it

What do you expect to keep working, and where do you think the path will stop?

Run the trace

Client desktop

wired learner workstation

Managed mobile

Wi-Fi + MDM + cloud identity

Switch

wired local path

Access point

wireless local path

Router / firewall

gateway and policy

MFD printer

print + scan service

Practice VM

bounded support workload

Cloud productivity

identity, mail, storage

React Flow

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Read the topology as text

• Client desktop: wired learner workstation
• Managed mobile: Wi-Fi + MDM + cloud identity
• Switch: wired local path
• Access point: wireless local path
• Router / firewall: gateway and policy
• MFD printer: print + scan service
• Practice VM: bounded support workload
• Cloud productivity: identity, mail, storage

1. Client desktop → Switch: Ethernet
2. Managed mobile → Access point: Wi-Fi
3. Switch → Router / firewall: LAN / gateway
4. Access point → Router / firewall: wireless LAN
5. Switch → MFD printer: print/scan path
6. Switch → Practice VM: support network
7. Router / firewall → Cloud productivity: remote service

Hardware compatibility still needs proof

For each workstation, verify the chain:

motherboard/platform
→ CPU support
→ RAM generation/population
→ storage interface
→ power/cooling
→ display/peripheral capability
→ firmware support
→ OS/driver support

If a component fits physically but fails platform or firmware support, stop there.

The capstone is not an excuse to forget the first half of the course.

Storage should match the workload and recovery plan

Harborview workstations need responsive local operation.

An SSD is a reasonable system-drive choice for that workload.

But ask:

• How much local data should users store?
• Which files belong in cloud storage?
• Which data needs offline availability?
• What happens if the workstation SSD fails?
• Is synchronization being mistaken for backup?

A fast drive does not solve recovery.

The client needs a data plan, not just a storage device.

Account design should keep daily work non-privileged

The client requirement says:

standard-user daily accounts with an approved administrative support path.

That means the target state should not use permanent local administrator rights for normal users.

A simple model:

daily user
   ↓
standard privileges

approved maintenance
   ↓
authorized elevation / technician account / managed process

Why?

Because most daily work does not require the ability to change system-wide settings.

The narrower privilege model limits accidental or malicious changes while still allowing support.

Windows edition and features should match the management requirement

Do not choose an edition because it sounds more advanced.

Check the required features:

• supported domain or management model;
• BitLocker or other required encryption;
• Remote Desktop host capability if actually required;
• policy tooling;
• hardware support;
• lifecycle.

If Harborview does not require a feature, do not use that feature as the only reason for a more complex deployment.

Requirement first.

The network plan should expose the boundaries clearly

A simple target topology might be:

provider
   ↓
router / firewall
   ↓
LAN
├── desktop workstations
├── printer/MFP
└── access point
     ├── staff laptop
     └── managed mobile device

Now define the logical responsibilities:

DHCP → endpoint configuration
DNS → names
router → default gateway / routing
firewall → traffic policy
AP → wireless access
cloud identity → authentication / MFA

One physical SOHO gateway may perform several of those jobs.

Keep the jobs separate in the documentation anyway.

Addressing should be deliberate

Use fictional/private addressing supplied by the lab scenario.

A reasonable plan could include:

LAN: private IPv4 subnet
router LAN address: predictable gateway
DHCP pool: user endpoints
printer: reservation or other managed predictable address
infrastructure addresses: excluded/reserved as required

The exact numbers are less important than avoiding collisions and documenting ownership.

A printer that changes address unexpectedly becomes a support problem even if the printer itself is healthy.

Predictability matters for services.

Printer deployment is a service path

Harborview needs shared printing and scanning.

That means the target design has at least two paths.

Print

workstation
→ driver / queue
→ network
→ MFP
→ print engine
→ paper output

Scan

scanner / ADF
→ MFP scan configuration
→ network
→ approved email / SMB / cloud destination
→ stored or delivered document

Those paths can fail independently.

A printer that makes a perfect test page can still have a broken scan destination.

A reachable MFP can still have a stale client queue.

Configure and verify them separately.

Printer privacy belongs in the design

If Harborview handles job applications, identity documents, or other private paperwork, consider the output path.

Questions include:

• Is the printer located where output can be collected promptly?
• Is secured/held print required for staff workflows?
• Are scan destinations authorized?
• Are address books or stored destinations appropriate for the environment?

A printer is a data endpoint.

Treat it like one.

The staff laptop needs mobility without losing management

The staff laptop uses Wi-Fi and cloud services while carrying more privileged staff activity than the public workstations.

A target state may include:

• supported OS;
• standard daily account;
• MFA-enabled cloud identity;
• disk encryption;
• endpoint protection;
• firewall;
• screen lock;
• approved Wi-Fi configuration;
• current patches;
• documented backup/recovery.

Do not disable controls simply because the laptop moves between networks.

Mobility usually increases the importance of those controls.

The managed mobile device is not a miniature unmanaged laptop

Harborview's mobile device should follow the supplied management model.

Possible target requirements include:

• MDM enrollment;
• device encryption;
• PIN/biometric lock under policy;
• supported OS/app patch state;
• approved Wi-Fi profile;
• cloud synchronization;
• remote lock/wipe capability;
• current backup;
• failed-login restrictions.

If MDM owns a setting, local changes may not be authoritative.

That will matter when the seeded faults arrive.

Wireless security should match the client population

Harborview needs staff and managed-mobile Wi-Fi.

Use the approved modern wireless security configuration supported by the fictional environment.

Questions include:

• WPA2/WPA3 support;
• identity/authentication model;
• guest separation if guest access exists;
• AP placement;
• channel/band planning;
• management access;
• firmware state.

Do not hide the SSID and call the network secure.

Visibility is not authentication.

The router/firewall should expose only what the client needs

Target hardening can include:

• unique management credentials;
• supported firmware;
• protected management access;
• no unnecessary public management exposure;
• UPnP disabled/restricted if not required;
• no unexplained port forwarding;
• guest/trusted separation where required;
• unused services disabled;
• documented firewall rules.

Every exception should answer:

Which client requirement needs this path?

If there is no answer, the rule probably does not belong.

Cloud productivity adds identity and entitlement decisions

Harborview uses cloud productivity, email, and storage.

Target configuration should account for:

• account provisioning;
• MFA;
• appropriate licensing/entitlement;
• sharing permissions;
• synchronization settings;
• offline availability where required;
• browser/app permissions for meetings;
• recovery/version history where available.

Identity sync, authentication, licensing, and application availability are different states.

Document them separately.

The practice VM should remain bounded

The local practice VM is for software/testing support.

Choose the network mode based on the requirement.

If the environment should remain isolated, host-only/internal networking may be correct.

If an approved exercise requires external access, change the network deliberately and document the new exposure.

Also define:

• CPU/RAM allocation;
• virtual disk capacity;
• snapshot role;
• independent backup requirement;
• host dependency.

A snapshot stored on the same host disk is still not an independent backup.

We have had this conversation several times now for a reason.

Backup design should answer a recovery question

Harborview needs recoverable data.

Build the plan from failure scenarios:

If a workstation SSD fails, what must be restored?

If a user deletes a synchronized file, how is an earlier good version recovered?

If the staff laptop is lost, which data already exists somewhere safe?

If a configuration change breaks an application, what state can be rolled back?

The plan can combine:

• cloud data storage/versioning;
• endpoint backup where required;
• configuration exports;
• known-good software packages;
• VM backup/export;
• restore testing.

A backup process that nobody has tested is still a hypothesis.

Change and support records should exist before the incidents

Define how Harborview changes are documented.

At minimum, a significant configuration change should preserve:

purpose
asset/scope
baseline
risk
approval
backup/rollback
change
verification
result

This matters because Lesson 3 includes an incident where an approved change causes a compatibility regression.

The rollback path should not be invented after the damage occurs.

Worked decision: printer address

Requirement:

Shared printer should be easy for all workstations to find consistently.

Options:

• unmanaged random static address;
• normal changing DHCP lease with no reservation;
• managed reservation/predictable address under the site's addressing plan.

The third option is usually easier to support in the supplied environment because the address remains predictable without leaving the DHCP plan.

The useful reasoning is not:

Printers need static IPs.

The useful reasoning is:

Shared services need predictable addressing under a managed plan.

Worked decision: permanent admin or controlled elevation

Requirement:

Users need browser productivity and video meetings. Technicians occasionally install approved software.

Permanent admin rights solve the technician's convenience problem by expanding risk for every normal user session.

Controlled elevation fits the actual requirement better.

Architecture should not make the dangerous capability permanent just because it is occasionally needed.

Build the target-state plan

Document:

Workstations

role:
hardware decision:
OS/edition:
daily account model:
endpoint protection/firewall:
storage/data model:
required peripherals:
verification:

Network

topology:
addressing:
DHCP/DNS roles:
printer addressing:
Wi-Fi/security:
router/firewall hardening:
allowed services:

Printer/mobile

print path:
scan path:
privacy requirement:
mobile MDM state:
mobile lock/encryption:
backup/sync:

Cloud/VM

identity/MFA:
license/entitlement:
sync/recovery:
VM resource plan:
VM network mode:
VM rollback/backup:

Operations

change record:
backup/rollback:
remote-support boundary:
privacy-safe ticket rule:
verification owner:

Before you move on

A good target state is not the most advanced system you can imagine.

It is the simplest environment that satisfies Harborview's requirements, preserves security and recovery, and leaves enough documentation that another technician can support it.

Next, the environment gets faults.

Do not abandon the model when something breaks.

The model is what makes the breakage understandable.