There have been many articles written that explain the benefits of using dedicated thin client devices to access shared desktop services and more recently the virtual desktop interface (VDI). The arguments are very compelling, and are today accepted as a given, almost as de facto, as to how beneficial a thin client can prove to be in such environments. With all thin client implementations (and I include zero clients here as well) the success of the deployment and on-going support is inextricably linked to a management platform of one sort or another.
In this document, we investigate specifically remote device management and how Praim overcome this conundrum.
Why should remote management of thin clients be complex? The benefits of thin client have centred on simplicity and ease of deployment, these have long been touted as the salient points that make the technology so compelling, so where is the issue? This message has been the rallying cry for the thin clients since their initial release in the 1990’s, however, the reality is that these two strengths are today only part of the whole picture. Contemporary devices are now feature rich, complex devices that are geared to work in enterprise environments, and with the growth of hosted services are having to adapt to these requirements as well. Desktop as a Service (DaaS) now also provides more opportunity to use a “dumb” device, so using a thin client which can be remotely managed becomes a valuable add-on in these instances.
These are all valid points, but the necessity of management for remote devices is not that obvious. Management for thin clients needs to be more than deployment, and status checking. It must offer security, updates, auditing, upgrade/downgrade of firmware as well as a support function where accountability can be maintained. So, distributing this level of management without impacting the enterprise infrastructure or to devices that are not directly accessing the service is key.
The thin client itself also can add to the complexity of remote support. The operating systems of true zero clients and Linux based devices typically have very small footprints which have been trimmed to offer excellent levels of functionality for the minimum operating system load. These devices still need to be managed, and even with these efficiencies they still will create a degree of network traffic. If the devices firmware is running a version of Windows Embedded, then this overhead increases dramatically. Typically, a Linux based devices firmware can operate with under 500 MB of file space, Windows 10 Embedded 64-bit is 20 GB before anything else is added to it.
The value of the management system now starts to earn its salt. Management software should be able to use scheduling techniques, or strive to keep the management “chatter” as low as possible. This is acceptable in environments where network connection and performance are not a concern. Where low speed links are all that is available or where sites have many remote users, then relying on a single central platform has often been supplemented by site management servers. This solves the issue, but is only suitable where sufficient support determines that it is needed. What this fails to address is those sites that have only a few devices that make supporting them require management, but not enough to justify a dedicated remote management console. It also fails to address those sites that have no dedicated connection to the service that they are using. Paradoxically, adding more management servers adds to the complexity that thin client implementations strive to avoid.
Praim has addressed this specific issue by providing a complimentary product to their ThinMan Management platform, called ThinMan Repeater. This product has now extended the reach of the management platform to remote sites, without requiring the addition of extra servers to provide the management layer or sacrificing any management functionality. Available as an application that can run on Windows 7 or above, it fully integrates with the centralised ThinMan management console. From a connectivity perspective, this solution does not even need a dedicated connection, and can connect using WebSockets to the ThinMan server’s external URL.
By using ThinMan Repeater, gathering management information, distributing firmware and device updates from remote clients now will not place excessive traffic on inter-site network links. Only ThinMan Repeater will be involved in this data handshake. Furthermore, sites that are connecting only through a secure web site can now be included in management, without requiring VPN’s or permanent connections. Using ThinMan Repeater it is also possible to address the elephant in room, the Windows Embedded device. No longer are these devices excluded from the crucial round of Microsoft updates through concerns of network saturation. Using ThinMan Repeater can now potentially offer equal levels of service irrespective of the underlying operating system of the thin client or its physical location.
With this information, it is now possible to see that the choice of a thin client solution is more than choosing the cheapest device. The value that can be added by a vendor’s understanding of how to manage a device becomes apparent. Consideration of the way the network must function and integration is as paramount with thin clients as it is with traditional desktop devices.