Tera2 Zero Clients in Horizon: A Support and Migration Decision Record
- Get link
- X
- Other Apps
Documentation-based decision guide. Revised September 12, 2026. The earlier healthcare fleet story, latency percentage, and fixed firmware recommendation were not supported by an attributable test. They have been removed. This article is not a completed migration case.
A Tera2 fleet should be evaluated device by device and workload by workload. A device that still connects is not automatically a supported long-term endpoint. Conversely, one slow call does not justify replacing every device. This guide is a support and purchasing decision record; the separate conferencing pilot covers workload measurement.
Start with an inventory that can be verified
Record the OEM model, processor family, firmware build, update source, support entitlement, monitor configuration, current Horizon Client/Agent environment where applicable, and intended user tasks. Confirm that the hardware is actually a Tera2 PCoIP zero client rather than a thin client running a software client. Product-family names are not interchangeable.
Answer three separate questions
- Support: can the owner document a supported firmware and server combination, security-update path, and recovery method? Obtain release-specific confirmation; an acquisition announcement is not an end-of-support notice.
- Function: does the actual endpoint support the authentication, peripherals, monitors, and collaboration features required by the user? Check the exact feature matrix rather than treating successful desktop login as full compatibility.
- Capacity: does a representative task meet an agreed usability target? Compare the existing device and a supported alternative using the same workload and route. Record observations without inventing a universal bandwidth or latency threshold.
Choose a bounded outcome
Retain: requirements are met and the support evidence is current. Name an owner and reassessment trigger, such as a planned Horizon upgrade or new collaboration requirement.
Temporary exception: the security owner accepts documented limitations, affected users, network scope, and expiry. “It still works” is not an exception approval.
Migrate: a required function or support condition cannot be satisfied. Pilot an alternative, including peripheral use, login, reconnect, and recovery, before buying at fleet scale. Keep a controlled fallback where it remains safe.
Avoid two migration shortcuts
Do not assume a hardware zero client can be converted by installing a thin-client operating system; verify the specific device's capabilities. Repurposing a PC is a different project. Do not describe HP Anyware as a drop-in connector for an existing Horizon deployment without a supported design and validation of agents, authentication, licensing, and endpoint compatibility.
The final decision record should contain evidence links, tested build combinations, unmet requirements, pilot results, security sign-off where needed, cost assumptions, and rollback ownership. Leave unknowns explicitly open. That record supports a defensible purchase decision more effectively than a generic claim that all legacy endpoints are obsolete.
References
- HP: Tera2 zero-client documentation (release-specific; not a blanket compatibility claim)
- Omnissa: Horizon protocol paths
Related troubleshooting guides
- Get link
- X
- Other Apps
Comments
Post a Comment