In the first #Praim4Beginners article we talked about thin clients, whereas in one we’ll discover zero clients.
The term zero client, in its most “strict” form, defines an endpoint for server-based computing that has no local physical memory. Therefore, it doesn’t have a local persistent file system and all configuration settings are received at startup and temporarily stored only in volatile memory. Some solutions found on the market still adhere exactly to this definition (there are several that have followed one another over time); however, as the environments and technologies with which clients integrate rapidly evolve, there’s a risk of not having a flexible endpoint solution. In fact, these devices are usually equipped only with specialized hardware and the bare minimum (often proprietary) to connect to a specific technology.
Often zero clients are required to connect to just one specific server-based technology, i.e. simply through Blast Extreme, ICA or RDP. This could be initiated through a web portal, but they key aspect is for a single technology being used, which makes it possible to simplify the device as much as possible and to optimize the hardware (also in terms of costs). This is where a traditional zero client can be restrictive, as a device which conforms to this pure definition will only connect to the supported environment. The Teradici chipset which worked with PCoIP was a successful example, which however then had to leave the field as protocols evolved.
Zero client functionality, however, is now often simulated through the creation of a range of devices with predefined properties and connections to vertical platforms. These endpoints normally support different software and hardware peripherals and can also be converted to work in another vertical or be upgraded to work on newer servers or connecting thin clients as well. In this case zero clients they are already optimized and pre-configured in a “software mode” for the specific vertical.
Praim also offered specialized zero client workstations for “vertical” connection to Citrix, VMware, or Microsoft environments, all of which can be managed through the ThinMan centralized management console (with the possibility of two-factor authentication with ThinMan Smart Identity) and convertible into every moment in “general purpose” solutions (normal thin clients). To date, the automation offered by ThinMan and the hardware resources available even on entry level models always allow great flexibility and don’t make it more convenient for the end user to be bound to a specific vertical.
