Monday, October 19, 2009

Thin Clients, I Never Thought They Would Work

So, about 6-8 months ago I started looking for a way to convince executive management to replace aging desktop computers in our data entry facility in Tijuana, Mexico. At the same time, we were involved in numerous security audits with our customers and were being pressured to come up with more secure solutions for our data entry facilities.

I had looked at thin clients in the past, but I always thought that they would not provide the performance necessary for high-speed data entry applications. However, after pricing out replacement desktops and factoring in the resources it was taking to maintain the aging hardware in our TJ facility, I was able to convince management to test the thin client option.

The thin client we chose for our test was the HP T5145. We chose this model because it is the cheapest offering ( < $200) we could find so we thought it would be the easiest model to obtain a payback on.

The HP T5145 is a linux-based thin client that allows RDP and Citrix type connections. Other than that the capabilities are pretty limited. We purchased a thin client for testing, and were surprised to find that with some tweaking they performed fast enough in our data entry application. Now it is possible that newer desktops may have performed slightly faster, but as we started looking at the security and cost saving benefits of thin clients we made the decision to go ahead with the Thin Clients anyway.

Now whenever I read articles about cost savings from thin clients, people always love to point out the energy savings. While there are definitely energy savings to be had, I find this type of cost savings is more marketing and propaganda than anything else. I see the cost savings coming into play more in the replacement cycle of the hardware and a lighter administrative burden. Let me explain.

Most companies refresh their hardware every 3-4 years. There are various reasons for this and I won't go into them here. There are different numbers out there, but because thin clients do not have any moving parts most people agree they should last anywhere between 6 and 10 years. So, not only are they cheaper by less than half (Possibly more than half once you add terminal server/citrix licensing), they do not need to be replaced near as often. Now what about adminitration?

Our current setup supports 64 Thin Clients at our TJ production facility, and we run Terminal Services for these clients. However, instead of dedicating hardware to these terminal servers, we run the terminal servers as VMs on existing VMWare servers that run our servers also. We have 4 virtual machines (2 on each physical host) along with all of the other file servers, SQL servers, etc. that are needed for our production facility. If you license your Virtual Server with Datacenter edition processor licenses, it doesn't matter how many virtual machines you create on that physical machine. So, although you could argue it cost us more for the extra resources in the server that allowed us to run these machines, I find the cost is negligible as processing power and memory are so cheap right now that the main cost is in the storage. These servers do not use much storage space. Why does all this matter?

Well, now that you understand our setup, here is what I believe is the best part of the thin client solution. Instead of maintaining 64 client computers, we only maintain 4. For example, we used group policy to deploy the .NET framework 3.5 before the update came out through WSUS. Unfortunately, the method that Microsoft gave of deploying the product through Group Policy was convoluted and when they finally released the update through WSUS it would not install on any of the machines that had received the update through Group Policy. Moreover, the solution was to use the .NET removal/cleanup tool to remove all versions of .NET and then reinstall the .NET versions you needed to reinstall. Ah, if it was only that simple. We found that not all machines would reinstall with the same procedure so it changed from an easily automated task to a manual task (we eventually did find a solution that worked on the majority of machines, but for the sake of arguement lets say we didn't). It took on average 1.5 hours per machine to perform the process to fix the .NET install problem. However, instead of having to perform this procedure on 64 machines, we only had to do it on 4 (or we could have done it on 1 and cloned the machine 3 times to recreate the other terminal servers). I will let you extrapolate from here on other cost savings that may be had with this configuration. Now, what about security?

The thin clients can be run in stateless mode, which means they can retrieve their configuration from an FTP server based on a user logon. In this mode, the user cannot change any settings on the thin client (the administrator can change the configuration through simple changes in the xml file on the FTP server). So, we combine this with Group Policy to lock down the server (no usb or other personal storage redirection), a dedicated VLAN for the thin clients that only allows RDP access to the terminal servers, firewall rules that whitelist access to the Internet from the Terminal Servers (no file uploads to untrusted sources), and the setup is pretty secure. Now, I am not naive enough to say it is perfect. There are always exploits that you miss or new exploits that present themselves later, but it is so much better than what we had before.

So, now we have 64 thin clients in our TJ Production facility (data entry), 10 in our Utah production facility (data entry and miscellaneous use), and 25 in our Pennsylvania production facility (call center). You definitely need to test all necessary user applications over terminal services (Direct X does not work in terminal services (may work with Citrix), we cannot use our high-speed scanners with thin clients because they require SCSI cards, and certain applications require a console session. Also, test different resolutions - some of our applications that require faster response times work the best at 1024 X 768. Fortunately, that is the resolution they are programmed to work at), but if you can find a user group that thin clients work for, I highly recommend it.


  1. Very informative. We are considering VDI for both our Academic and Administrative computing environments. I would like to know the specs of the back end servers and the storage systems.

  2. I was actually considering doing this as my next post. Not necessarily specific to the Thin Clients but if I can't work them in to the post I will comment here on them. It might be a few days before I have time. I also wanted to research VDI a little bit because we looked at VDI also. I think the main reason we went with terminal server was that we were worried about licensing costs, but I wanted to double check to see if there was something else.

    Most of the comments I have received via a discussion I started on linkedin show people using either Citrix or Terminal Server. There was one using Xen.

  3. nice post, this is the way most people have been doing it for years. The only difference was that VM's replaced physical and Citrix was installed over TS.

    Budget is the deciding factor and you found a solution for your budget and need so well done.

  4. Prof,

    Here is some information on configurations and utilization statistics. See configuration 2, for the Thin Clients.