by
Jeroen van de Kamp
Sorry, I have to get this of my chest. As you might suspect after reading the not-so-subtle title, there is something fundamentally wrong with thin clients.
Let me be specific here: I am NOT talking about good old trusty SBC (Terminal Server/XenApp) or the hot and sexy VDI as a concept. I'm talking about the actual "desktop appliance" or "access point" or "thin client" itself.
This discussion is not new, but now that VDI has made hosted desktops an attractive option again, there's a sort of revival of thin clients in our market space.
Thin clients can be discussed from two angles:
- First, there is the typical Citrix user who's been doing SBC for years already and has been pretty successful with it.
- Second, there are the organizations venturing into the VDI space who are interested in the power, manageability, and cost advantages of thin clients.
From either perspective (both SBC and VDI), that the only logical choice for the thin clients is not to use typical thin client solutions, whether Linux, Windows CE or Windows XP embedded.
To understand that logic, let's look at the constants we need to deal with in the context of thin-clients:
1. Organizations are required to build a mature and fully automated management infrastructure for PCs and laptops, even when 90% of the clients are “thin.”
The majority of distributed organizations with 1000 desktops or more are often required to support conventional PCs (for rich media editing, 2D/3D design, etc...) and laptops (mobility). This is today’s reality of Enterprise IT. Deploying 100% thin clients is still not feasible in the typical heterogeneous IT environment, even if you're considering all innovations we currently see in remoting protocols from all major vendors.
The problem is that it's not economic to neglect the management aspect of the remaining 10% (or whatever) of devices that are laptops or PCs. You can't ignore patching them just because they're the minority. And manual configuration of PCs and laptops is just too costly in distributed environments, even if you perform only one change every year. So this means that unless you can go 100% thin clients (which I don't think you can), then you have to build a management system for your non-thin clients.
The good news is PC management has matured considerably over the past few years. Building an effective management solution for laptops and PCs is not rocket science anymore.
And by the way, BYOL (Bring your own laptop) doesn't this fix this problem. BYOL is a cool concept, but the majority of organizations still require full management of the desktop/laptop for practical, legal, or security reasons. In most cases BYOL is not an option.
2. When it comes to the support of innovation and new features within remoting protocols such as RDP and ICA (HDX), traditional Windows (XP+) is, by a big margin, the best platform to choose.
All the cool features, especially those which require client-side rendering, are first developed for Windows. Quite often such innovations demand the availability of CODECs, the .NET framework, WPF, the Windows USB or printer driver architecture, and more.
The fact is that Linux or Windows CE as a thin client OS seriously lacks the rich media and user experience optimization support we see being developed first for the Windows client. This is relevant because any user experience- and performance-related innovations are very important to our end users and ultimately, the acceptance of any SBC and VDI solution.
3. A thin client is not a “fire and forget” solution. Thin clients require a mature deployment and management infrastructure.
Don’t believe me? Talk to all the IT admins who've been supporting thin client for years. They'll tell you from experience that a management infrastructure is required to deploy security fixes, client/application upgrades, root certificates, firmware updates, and configuration changes. Those who don’t probably have a very static IT environment.
In comparison to conventional fat clients, the rate of changes and updates on thin clients is considerably lower. However, one single update already justifies the investment in a management infrastructure, as manual configuration of all your thin-clients is extremely expensive.
The reality of thin devices, regardless of protocol, and even hardware embedded solutions (e.g. “PC-over-IP” devices), is that you need to be able to centrally manage and update them. The minute a bug is discovered, a security fix is required or a configuration change is needed--you need a management infrastructure where you can automate such changes.
4. Windows XP Embedded is not a thin OS at all...
Windows XP Embedded is surely more light weight than conventional Windows, but it's far from thin. Even when the OS is stored on a read-only flash disk, you still need to apply the monthly security updates and virus scanner/firewall updates to ensure the client doesn't become a broadcast station for worms within your network. In practice there are just too many examples of unmanaged XPe devices being the “source of all evil.” Remember Blaster and Sasser?
You could argue that there are a far fewer security updates required for XP Embedded. Unfortunately it's fairly common to use Internet Explorer to provide a web portal front-end to authenticate and access the SBC or VDI desktop. This means that, many of the monthly security updates are also valid and important for Windows XP embedded clients.
Finally, the reality of XP Embedded management solutions that they're very similar to the management infrastructure for PCs and laptops. These XP embedded management solutions have a lot of the same functionality and share the same complexity.
5. And all these other “little things” that we tend to forget or overlook:
- What about the standard vendor lock-in when using thin clients? Or do you want to support five different thin client devices with three different management tools from two different vendors after five years? You have no choice: in contrast with PC hardware, thin client management tools are vendor-dependent.
- Does the thin client vendor still provide updates for that five year “old” thin-client?
- How quick is the thin client vendor with making client bug fixes available for your client device when Citrix/Microsoft/VMware releases a new version of their client software?
- Cheap thin clients are clearly much slower when displaying remoting protocols: just compare the protocol display speed performance of Internet Explorer, PowerPoint, PDF and Excel to the protocol display speed performance on entry level PC hardware.
- Do you need the Full Monty when it comes to remoting protocol and user experience? The high-end thin client will be anything but “cheap”.
- Are doing VDI and using a non-Windows thin client? A VECD license is your only option. This will cost you $110 (The list price, per year, per “access point.”)
Considering these constants, are we truly aware of what the long term impact of a thin client is? Surely, traditional thin clients can be a very successful when the requirements are low, but when the latest and greatest is required, you have another option.
The solution: a thin PC
A smart client, slim client or thin PC--it's just a name--but this is basically a PC with OEM Windows Professional (XP to 7) configured as a thin client. This thin PC can be easily built on the same image and same deployment infrastructure used for PCs (and laptops). However, in “thin mode” this desktop is automatically logged on with a local generic account which is completely locked-down. In this mode only IE and the client software can be started to authenticate the user and provide access to the SBC/VDI environment. Functionally it's identical to Windows XPe.
Just secure the thin PC the same way we learned with XenApp / Terminal Server and configure software restriction policies (or now applocker with Windows 7) to lock down the machine even further. Additionally, use the free Steady State tool from Microsoft with is specially created for a read-only kiosk mode: http://www.microsoft.com/windows/products/winfamily/sharedaccess/default.mspx
Consider this:
- Chances are high you already have a deployment and management infrastructure for your PCs and laptops. What is the extra effort is required to also use this infrastructure for thin PCs? Let me rephrase this: if you already (properly) automated desktop deployment/management, how much effort would it cost you to upscale PC management from 100 to 1000 desktops?
- If you were to switch PC vendors, or when your current vendor introduces a new model, you can just continue managing the new devices using your existing deployment infrastructure.
- How expensive is a basic, entry level, slim-line, Windows Professional PC including 3 years support (or even netbooks and Atom-based devices when green IT is important)? Is it more expensive than a high-end XP Embedded client? Isn't it not much faster and far more functional than a high-end Windows XP embedded device?
- How good would a 3 year “old” PC perform as a thin PC?
- Would you use the option to install local client applications such as VoIP?
- Want to provide all the latest and greatest multimedia and user experience innovations, the latest protocols, and newest client software/codecs/drivers to your end users? How difficult would this be of you can manage the PC the way you want?
- SA on Windows ($50) and VECD for SA ($23) will total $73 per year if you get SA within 90 days of purchase of a PC with OEM Windows Professional. How does this compare to the going rate for standard VECD license of $110/year for non-Windows clients?
Is the thin PC the only way to go? No, but in many cases it seems the only logical long-term solution, especially when you need to support a heterogonous desktop environment which includes PCs and laptops.
Sure. there are plenty of scenarios and reasons--especially in organizations with no diverse desktop requirements--to go the traditional thin client route. But organizations considering thin clients should at least be aware of the choices now possible. And in many cases the most logical thin client option is actually quite fat.
PS: I got the VECD pricing from this article, feel free improve this information when needed.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.