Slashdot Mirror
Windows Thin Clients - Worth Making the Switch?
Brendtron 5000 asks: "I work in the IT department of a major Canadian university. I've been given the task of investigating the pros/cons and costs associated with switching from Windows desktop machines to some kind of thin client solution. Both student lab and administrative machines are up for possible replacement. At first blush it seems that the cost savings will be considerable, given that thin clients are much cheaper and easier to maintain than a user controlled desktop machine. What were your experiences with switching to/managing thin client environments? Have the users been happy with thin clients? Did the cost savings materialize as expected?"
Back when Citrix produced an inexpensive version of Windows capable of supporting ~40 concurrent clients on a single dual-proc machine, the answer was "yes." The cost savings were huge. Not so much from the hardware, but from the support. Users were simply unable to screw up their desktops, could login remotely over a modem (!), and IT could share the session with the user to fix the problem without ever leaving their desk.
Then Microsoft got involved. They refused to license to Citrix again, and released their own Terminal Services. The price skyrocketed, the licensing became confusing, the protocol was much heavier, and the system became far less stable under load. Not much has changed.
It was a wonderful thing while it lasted, but don't expect to see any real returns on a modern Terminal Services system. The only real uses they have these days are remote administration and centralized applications. And you can expect to pay for those features.
Javascript + Nintendo DSi = DSiCade
My school replaced some (Windows 98) systems with Wyse thin clients. I'm not sure how many issues are due to my school's specific configuration/ignorance. If there are any software updates available for the thin clients, I'm sure they aren't installed. The servers run off of Windows 2000 with Citrix MetaFrame. They had three IP addresses in the configuration settings on the terminals.
I don't know how much the devices are supposed to be locked down, but anyone can go in and change the settings. I use them to connect to my remote hosts over RDP. Monitor/network settings will save between reboots, but the server list is cleared after every reboot. While the devices autoconnect to the server upon startup, the login eventually times out, and the session disconnects.
If a lot of people try to connect at once, about half of the systems time out. Since there were three IP addresses in the configuration settings, I assumed that the devices were sticking on one IP address and not trying the rest. This appears to be the case, as picking a different IP address seemed to help.
The printer settings also pose another problem. The same servers/published application is used for terminals in two different parts of the same building. Both rooms have their own laser printers. If you happen to be in the room that doesn't have its printer set as default, you either have to remember what room number you're in and change the printer (something half of the people in there fail to do) or walk down to the other room and get your printout.
I've noticed a few issues that are definitely with the thin clients themselves. Sometimes, they decide that they don't want to work properly anymore -- mostly on RDP connections. The screen will stop updating for a few seconds, then go black. Sometimes, the systray icons will show up, and about 10% of the time, the connection will decide to come back, but otherwise, the connection just stays on that black screen, and any subsequent reconnect attempts time out. The clients have to be rebooted before you can reconnect to any new hosts at this point.
Once again, if there any firmware updates that would fix this issue, they probably aren't applied.
I've been using LTSP to serve thin clients at a call center for almost six months now (Linux, not Windows, though), and I can honestly say that all the problems I anticipated never materialized. In fact, the biggest issue has been callers sticking gum in my CD drives.
Setting up LTSP is a snap, thanks to the great wiki at http://wiki.ltsp.org/ and the very helpful people on the mailing list.
The *really* hard part is just getting through your brain how exactly thin clients boot off the network, and establish a connection to X remotely. Once that starts to make sense, you really can get it working quickly and easily. There are just so many variables to start off with (NFS, X, XDMCP, PXE, DHCP, TFTP, Etherboot) at the beginning that there's a real learning curve. Once it's working though, it Just Works(tm). It's great.
Just setup a decent firewall to block outgoing stuff to where you don't want them to go, and make sure you give the clients lots of options when it comes to software. Working in a call center can't be the highlight of anybody's life, so I made sure to give them their choice of 4 window managers (GNOME, KDE, XFCE, Flux) and I put all the little games on there to keep them happy in their downtime.
The problems I worried about the most never materialized -- there's no process load, the connection is really fast never laggy (even with 35+ users connected all at once), and everyone picked up really quickly how to switch their preferences around, log in, and get their work done. I never should have put it off as long as I did. It's so much easier than having 40 separate windows installs to worry about and reflash / reinstall / reconfigure when one gets any kind of problems.
And last of all, with LTSP you can throw *any* kind of cheap hardware in the mix, and they all run equally fast. I had a few Pentium 100s on the network for a while, and you couldn't tell any difference in performance compared to the Athlon XPs.
I used to work at a school as a sysadmin where a vast majority of the machines were Tektronix X-terminals. We had Sun Sparcs and linux boxes on the back-end running FVWM.
From an admin point of view, it couldn't be beat. They rarely had problems. When they did, it was usually because paper got sucked up underneath and blocked the air intake. But even when there were problems, you just swapped out the pizza-box. And talk about quiet.
We only had one die - someone spilled cuppa-soup next to it and it got sucked up inside. Yuck.
This approach is great any any environment where you want consistent software settings, etc. We had 2 application servers. Want to install/upgrade applications? Just put them in 2 places, and everyone has it.
We also had a few "power" machines with the heavy duty-aps. Just SSH over, point your terminal to your screen (a script handled this by default), and you had all the power you need.
I had a lot of lazy days back then. Then we started turning them all into windows boxes... and I had a lot more work. It was sad.
I would hope that windows via thin-client would be as nice as it was with unix... but it sounds like the costs are just as bad.
Good luck.
I've done some work for an education instituion who wanted a multi-site, low-cost upgrade to their network.
The decision was made to go ahead with a Windows Terminal Services-based operation. The decision was helped by the fact that they were an educational institution with volume licence key access, so there was no cost in relation to that.
A Dell twin-processor server was ordered and setup with the standard host of software, integrated into their domain and ran like a charm. The clients were setup with ThinStation, which is a phenomenal piece of software. This alone has enabled them to save tens of thousands of dollars simply due to hardware considerations. A new site which they took over had a number of machines which would be considered out of date, or subpar. This included first and second generation Pentium PCs, etc that would not have been considered for 'active duty' if they were required to run Windows XP with the latest and greatest productivity suites.
At this point I should mention the initial deployment was planned for only the administration PCs, but due to the performance, savings and general ease of transition, management has indicated they would like to move forward with classroom deployment soon.
All up, this single server is operating up to 50 clients at any one time, and due to the fact that it's running Terminal Services, their remote site bandwidth requirements have decreased fairly significantly.
The time it takes to setup the ThinStation software is far outweighed by the time it would take to create and deploy a full image, and there is an additional benefit that everything is exactly the same no matter which staff member accesses which terminal.
I'm unsure how educational licences operate in the organisation mentioned in the OP, but if it's anything like my experience, then the labour costs, hardware costs and sheer frustration cut out from dealing with an equivalent non-TS environment are definitely worth it from the point of both myself and the client.
It's not a Windows solution, but PXES is an incredible linux-based thin client solution. It's used in my workplace and we never had an issue with it. You can pretty much recycle any old computer you have laying arround, create a bootdisk and off you go.
Just make sure the server machine has enough memory, and it just works. No hassles.
Obligatory Background:
:-/ ). Plus, many people's work is network bound--a dead conventional server means people can't save stuff or can't update the company database (or whatever they're doing) anyway, making the desktop of little real use when their related servers (or the network generally) go down.
I currently work for Sun's Network Systems Group (x64 servers). I use a SunRay to do the vast bulk of my work every day. I have run my own SunRay servers (running Linux) for over two years.
I used to work for a company called Taos, whose user infrastructure was entirely Windows Terminal Services + Citrix Metaframe. Another SA and I ran their terminal servers for my entire tenure there (about 2.5 years, plus I was doing application development at the same time).
The Response:
Those who hate thin clients (TCs for short) tend to do so for the following reasons:
1. Initial procurement cost and software licensure is no cheaper than desktops. For some software (the Citrix bits in particular), it's significantly more expensive.
2. Users can't (or damn well shouldn't be able to) run arbitrary software--the joke "screensaver" that their friend sent them, for example ("screensavers" are just eye candy anyway--who cares about saving a CRT anymore?).
3. Performance with certain apps (video in particular) is highly network-bound and potentially crappy.
4. Limited number of points of failure, so a dead server can affect many people.
5. "What do you mean I can't plug my webcam/phone/food processor in there?"
Most of these arguments are lame, because:
1. Thin client hardware has MUCH better longevity than its desktop bretheren--five or more years out of TC hardware is the rule, not the exception.
2. Users shouldn't be running arbitrary software anyway in most business settings.
3. Performance with most other apps is stellar, as the first user to load an app "greases the skids," putting most of the app in cache for everyone else.
4. If you do it right, you have configured your server to be relatively bulletproof, and have one or more backups (typically folks don't have backup desktop machines
5. Is more-or-less valid. There are some devices that simply will not work when attached to TC hardware (though a surprisingly large number of things will). Whether that's really a problem or not is in the eyes of the beholder.
You also get the following benefits out of TCs:
1. No crawling under a desk and facing the Dust Bunny Army (tm) to replace a dead drive, or removing 20 lbs of personal effects to upgrade someone's RAM.
2. True centralized deployment of software--no guessing if an app got installed or WTF is actually on someone's hard drive (deployment solutions for PCs other than ghosting the whole drive have this nasty habit of being fidgety).
3. With some solutions (Citrix in particular), you can "publish" an application, making just one app available to those who MUST use a PC, so you can mix-and-match your clients if needbe.
4. Usability over slower WAN links is usually pretty good (especially with Citrix).
5. Some solutions (particularly SunRay on Linux or Solaris) allow session "portability," which means that you can start typing a sentence, pull out your card, walk down the hallway (to, say, a meeting room), plop in your card and finish your sentence. To those that have never tried it, this seems silly. To those who use it daily, it's a Godsend (like those who are addicted to TiVo, SunRay session portability is something you just have to "get").
6. TC hardware is generally SILENT and consumes very little electricity.
SAs, like any users, hate TCs because they're "limited" in what they can do. The smart ones end up loving TCs precisely because users are limited in what they can do. That said, you also have to deal with the real TC problems:
1. Some apps just won't behave, or they require a ton of work to behave. This problem has gotten better with time, but stories abound of ba
"Time flies like an arrow; fruit flies like a banana." --Groucho Marx
Background: I work for a Health Authority in Canada and support around 300 users. We currently have ~100 thin clients deployed in our organization. They connect to 2 Network Load Balanced Terminal Servers running on Windows 2003 Enterprise Edition. We're not using Citrix (too expensive for our little shop)
;)
Server Specs: IBM xSeries 345, Model: 8670-L1X, 2 x 2.8 Ghz Xeon, 4 GB RAM, RAID-1 of 2 x 36.4 GB for paging file, RAID 1-0 4 x 73.6 GB for OS.
Currently have 40 users on one of the servers, CPU goes between 0 and 25%, RAM usage at 1.66 GB. So not exactly taxed.
My Experience is that Thin clients are much easier to support. Thin clients out of the box can be configured and setup in about 10 minutes (We use Windows CE thin clients from HP, and you just setup one thin client exactly how you like then export the settings to a file, using the file you quickly setup all other thin clients). Plus the ability to remote control a users desktop from the Terminal Server manager is great for helping with various little problems and saves a lot of time. (You do everything from your workstation)
If you're on a Windows Domain you can create an OU to place your Terminal Servers in, you can then create an extremely locked down Group Policy that applies just to those servers. Disable control panel, limit start menu, even logging off users who leave a connection idle for more than a specified amount of time. Of course how locked down you want to be will have to be tailored for each individual organization (for instance we allow our users to add their own printers)
I don't recall having any network performance issues as even Windows Terminal Server is "thin" enough for a decent LAN/WAN environment... we have clinics connected to us all around our little town... I connect to our servers at home via VPN and RDP and don't notice a large lag... even when I'm travelling out of town. We have Gigabit switches connecting our servers and 100Mbit connections throughout though... with fibre connecting the clinics.
The issue of "if your network goes down so does your terminal server" is true... but then again... without network we don't have ability to print, access our file server, or authenticate. Plus anything you were working on when the network goes out isn't gone... your session is just in a disconnected state, when you logon again your session is revived with all your work intact.
Thing is Thin Clients AREN'T for every user though... most users I've spoken to love the fact that the thin clients boot up so quickly and they can get to their work faster. But thin clients are really ideal for lots of users with a very standard set of application needs... Office 2003, Scheduling application, etc... there are some applications (like a few ERP and accounting applications) that aren't built too well for thin client use and if put on to a terminal server will chew through your server resources. If you have users who need to play with GIS data, or do AutoCAD, or graphic intensive things... then you're better off keeping with workstations for those users... but for users that use basic office productivity apps (I'm guessing like campus computer labs for students) then a thin client environment might be ideal.
You don't have to go all or nothing right? Pick the tool best for the job
You also have a choice on the windows side of whether to go Windows CE or Windows XP embedded... having tried the two out... I would strongly recommend Windows CE... it's a much smaller OS which boots up quicker and the ability to lock it down is phenomenal... I setup our CE machines to be single button logon which just connects to an RDP session... nothing else... unless you need to install and share out printers from a thin client (then I would recommend XPe)... or need to register your assets into the domain?
I find that I hardly ever have to do support calls for the Thin Clients, meanwhile for desktops/laptops they usually come up with quirky issues that take up a majority of my time. When I do have to support thin clients it can usually be centrally managed via the terminal server manager.
Anyways that's my two cents.
Addbo