Managing PC estates is a time-consuming, expensive and thankless task. Better provisioning and management tools can obviously help, but implementing one or more of the various forms of desktop virtualisation available nowadays may also be beneficial.
The virtualisation option, and particularly the use of hardware-based thin clients in that context, was the subject of a recent survey. From this we learned that over their many years of existence, thin client devices have found their place in many environments. Relevant types of users and use cases called out in relation to this (in respondents’ own words) include:
“Office administration staff.”
“Operational and managerial staff using office or web based applications.”
“General business users, help desk or call centre agents, and anyone else who needs a moderate and consistent set of applications.”
The theme coming through here is the acknowledged role of thin clients in meeting the needs of employees with relatively undemanding application requirements. For users who spend most of their time accessing server or cloud based business applications, or performing lightweight tasks with Microsoft Office (email, word processing, etc), there’s a good case for virtualising and centralising their Windows environment.
Apart from the management and support benefits of reducing complexity on the user’s desk, doing away with the local ‘C: Drive’ as part of the centralisation process also removes a security headache. With this in mind, it’s not surprising to see users who frequently access sensitive or valuable data being identified as potential targets for thin client deployments. Examples here include:
“Admin staff using sensitive data.”
“Software development contractors so the source doesn’t leave the organisation’s core servers.”
Then sticking with the theme of risk management, another potential benefit comes to the fore:
“Thin clients in a DR scenario.”
What this comment is getting at is that it’s a lot quicker and easier to get users up and running again if their desktops reside on a server independently of physical devices.
Beyond the ‘horizontal’ categories of users and use cases we have touched on so far, a number of examples of vertical industry use of thin clients came through in the reader feedback and anecdotes:
“We use thin clients to replace the dodgy small form factor computers that are built-in to wall mounted display boards. Thin clients are much more reliable. They are also remotely controllable so the techs are safer – they’re no longer working on top of ladders, in the ceiling and behind heavy displays.”
“In healthcare the ability to turn many types of office workers into remote workers is hugely beneficial. Choosing a zero client that is effectively a streaming device is huge for the security of protected data. Freeing up office space and allowing management to have the ability to utilise home offices without compromising security makes our organisation nimbler. We are currently sending all of our medical coders home with zero clients.”
“The best use of thin clients I have ever seen was in a school where a single machine souped up with RAM and caching lots of files as a terminal server could run circles around the usual fat clients.”
Some of these industry-focused use cases appear very specific, but can be more broadly applied as the same ‘shapes’ of requirement often crop up elsewhere. Here are some other examples that fall into this category:
“Kiosk mode for certain applications is good in schools.”
“[Electronic signage] displaying looping video.”
“Remote/branch office and POS terminals [in a retail environment].”
“Perfect solution for dusty environments.”
But while many are clear on the potential, others in the study expressed concerns about the suitability of thin client technology to handle more demanding requirements in areas such as:
“Heavy media editing scenarios.”
Such perceptions are interesting given that networks, transport protocols, devices and software platforms have developed over the past few years to remove constraints in these areas (at least if you listen to desktop virtualisation solution vendors). Empty marketing promises, perhaps? You could be forgiven for thinking so when we also see references to ‘disappointing’ real world experiences like these:
“Seen problems with thin clients deployed in a police control room that could not play back 999 calls. Thick clients had to be used to listen to recordings.”
“Our experience with unified communications and thin clients is a bad one.”
So what’s going on? Well, some of the more qualified concerns and warnings provide a clue:
“Full-screen video is definitely not good with weak servers, slow networks or weak thin clients.”
“A major 80k user plus company I worked for attempted to roll out thin clients to 40k users overnight, with no change in network infrastructure. It sucked.”
“The worst result I have seen is [thin clients deployed] in a computer lab for students to edit media with Adobe Creative Suite, relying on the local graphics card to render video.”
“Seen CAD on Citrix over a WAN link. The guy who implemented this should have been shot.”
“It is not about the hardware thin clients on the desktop. It is about the back-end.”
Such comments allude to the fact that many problems stem not from inherent limitations of the technology, but inadequacies in the supporting infrastructure and/or inappropriate configuration of one kind or another. Turning this logic on its head, one experienced reader told us:
“When coupled with a decent central server and a high quality network, thin clients are ideal for the majority of standard workers.”
So does this mean that all of the problems we hear are down to ignorance or budgetary stinginess? Could thin client technology be used across the board if you just did it right? Of course not.
Mobile users who have to work in disconnected mode are clearly a non-starter for hardware-based thin clients. Furthermore, while techniques such as virtual to physical USB port mapping now work more reliably and flexibly, you can still run into peripheral connectivity problems depending on the kit you have in place and what you are trying to connect over which types of port. And for users with complex and frequently changing application needs, and those with requirements that simply can’t tolerate the latency of even a relatively quick network (despite all the modern protocol trickery), thin clients just don’t make sense. This reader comment is therefore very apt:
“Don’t assume that [thin clients] are appropriate for all types of user.”
Then beyond the user experience and other practicalities, you also have to do your arithmetic:
“One of the fallacies is the notion that lots of money will be saved by moving to thin clients. This kind of move offsets the cost of the hardware on the desk, but greatly increases the cost of infrastructure.”
In order to make objective decisions in this space, it’s important to add up all of the costs, from the desktop to the server, up through all layers of the hardware and software stack, and across the lifecycle from deployment to ongoing maintenance and support. Only then will you be able to figure out whether the benefits outweigh the investment.
Standing back, the overriding impression we get from this latest research, considering both the survey stats and the reader feedback listed above, is that the potential to exploit thin client technology is probably a lot broader than many imagine. Perceptions are often clouded by legacy experiences and knowledge, and perhaps also by more recent failures stemming from projects that weren’t necessarily scoped and resourced as well as they should have been. If this rings true, it therefore might be time to take another look.
If you do this, though, we would urge you to review the role of thin client technology as part of an analysis of your end user computing needs more generally. The chances are, if you do your homework and get up to date on current solutions, you will see a potential place for all types of traditional and desktop virtualisation options. Thin client technology may be a key ingredient in the mix as you look to solve your desktop related challenges, but it has to be considered in its proper context.
Content Contributors: Dale Vile & Tony Lock