Thin Client Use Case Guide

Thin Client Use Case Guide:

A thin client is a lower-cost, lightweight computer that relies on a virtual desktop running on a remote server to do most of the processing and storage. Instead of running everything locally like a traditional desktop or laptop, it primarily acts as a secure access point to web-based tools, virtual desktops, and centrally managed applications.

This article will help you determine whether a thin client is a good alternative to a traditional computer. The best use cases are scenarios where the endpoint provides access to centrally managed virtual desktops, lightweight applications, or browser-based services, rather than supporting significant local processing, local storage, or specialized peripherals.

How to Use This Guide

Use the green, yellow, and red categories as a starting point for intake conversations.

  • Green scenarios are generally good candidates for thin clients.
  • Yellow scenarios may be appropriate but should be piloted before broader use.
  • Red scenarios are generally not recommended because they introduce operational risk, support complexity, or user experience concerns.

Decision Matrix

Category

Best-Fit Scenarios

Guidance

Green: Good Fit
  • Staff who do not have a need for a full computer, such as basic access for timesheets, email, or similar services.
  • Shared offices or common spaces used by adjunct faculty before or after classes.
  • A department informally supporting a small shared computing need.
  • Mobile users who need a consistent desktop experience on campus and off campus.
  • Labs without highly specialized software, or labs that would benefit when the user experience is centrally managed.

Thin clients are appropriate when users primarily access a standard virtual desktop, web tools, or a small set of centrally managed applications.

 These scenarios benefit from simplified endpoint management, reduced local device complexity, and a consistent user experience.

Yellow: Pilot First
  • Classroom workstations that are not instructor stations.
  • Student employee workstations.
  • Lightweight employee roles or shared-service use cases.
  • Faculty or staff whose primary work is web, email, and light Office productivity.
  • Shared computers with a maximum of two monitors.

These scenarios may be viable but should be validated through a pilot. The goal of the pilot is to determine whether the use case should move to green or red based on performance, peripheral needs, authentication experience, support effort, and user satisfaction.

Red: Not a Good Fit
  • Kiosk-style secondary devices or walk-up devices used for basic access.
  • Non-NetID access scenarios, such as public access devices in library or community spaces.
  • High-stakes classrooms or instructional environments where downtime would significantly disrupt teaching or operations.
  • Instructor stations in classrooms.

Thin clients are generally not recommended where they add another layer of complexity without a clear operational benefit, where NetID authentication can’t be required, or where the risk of disruption is too high.

 

Green Scenarios: Good Candidates

Green scenarios are the best starting point for thin client adoption because they have predictable requirements, limited local computing needs, and clear alignment with a centrally managed virtual desktop model. These scenarios typically involve shared spaces, task-based access, or continuity of experience rather than specialized desktop computing.

Example: A staff member in a shared administrative area only needs to access a browser-based timekeeping system and occasional email. Rather than replacing an aging desktop with a full computer, the department could deploy a thin client that connects to a standard virtual desktop or approved web resources.

Yellow Scenarios: Pilot Before Committing

Yellow scenarios are not automatic approvals or rejections. They should be evaluated through a defined pilot with success criteria (see below), support expectations, and a decision point. After the pilot, the scenario should be moved to green if it proves sustainable or red if the experience, support model, or technical requirements create too much risk. Contact OTS to confirm whether a pilot is appropriate for your scenario. If approved, you will be asked to provide feedback on the criteria below to help inform the final decision.

Example: A student employee front desk position primarily uses email, WebEx Teams, shared documents, and a small number of web-based systems. This may be a good thin client candidate, but it should be piloted first to confirm printing, sign-in flow, response time, and any role-specific applications work reliably.

Pilot Success Criteria for Yellow Scenarios

Criterion

What to Validate During the Pilot

User experience

Confirm that sign-in, launch time, responsiveness, audio/video, printing, and peripheral behavior meet expectations.

Application fit

Validate that required applications work properly in the virtual desktop environment and do not require unsupported local installation.

Monitor and peripheral needs

Confirm that the scenario works within the expected hardware limits, including the two-monitor guideline for general use.

Support effort

Track support tickets, troubleshooting time, and escalation patterns during the pilot.

Service dependency

Confirm that stakeholders understand the dependency on the virtual desktop platform, network connectivity, and the production support model.

Decision outcome

At the end of the pilot, document whether the scenario should move to green, move to red, or remain limited to a specific supported configuration.

 

Red Scenarios: Generally Not Recommended

Red scenarios are typically poor fits because they either do not benefit from the added virtual desktop layer, require access models that are difficult to support, or create unacceptable operational risk if the virtual desktop service is unavailable.

Example: A public walk-up device in a library lobby is intended for quick, anonymous access to a catalog or website. A thin client would likely add unnecessary sign-in, virtual desktop, and support complexity without improving the user experience, so a simpler kiosk or managed public-access option would be a better fit.

Print Article