Windows Thin Clients - Worth Making the Switch? 128
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?"
Watch the "savings" melt away (Score:3, Interesting)
My school uses thin clients and they're annoying (Score:4, Interesting)
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.
using thin clients at a call center (Score:5, Interesting)
Setting up LTSP is a snap, thanks to the great wiki at http://wiki.ltsp.org/ [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.
Worked great with Unix (Score:5, Interesting)
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.
Re:Yes, but not anymore (Score:4, Interesting)
Give PXES a try (Score:5, Interesting)
Just make sure the server machine has enough memory, and it just works. No hassles.
Re:Yes, but not anymore (Score:3, Interesting)
The U.S. Federal Government has pursued such an endeavor for places where multiple machines on a desktop are the norm. In those cases the thin client is replacing multiple network drops, one computer for each network, and sometimes a monitor for each (though usually a single-headed, VGA, PS/2 keyboard mouse). This may seem crazy to you and I, but imagine your internal accounting network which will never, never, never be exposed to the internet, not even remotely.
Their solution has been the DoDIIS Trusted Workstation, or DTW, (Google search [google.com]) which has had mixed reviews to poor. Most resistance comes before anyone ever sees the thing work, never mind the O&M savings to IT. It turns out that users are hooked on having their own, dedicated CPU time, even if they kick it every day. Mix that with the parent's comment about terrible Microsoft licensing and you have a recipe for failure.
User's reasons include: insufficient bandwidth to display the graphics I use, insufficient dedicated CPU time for the programs I need to run, and "one network glitch and the whole enterprise stops working." I think these are all valid complaints. IT complains because the cost savings in hardware isn't really there. Good luck buying a thin-client for under $400. You always have that $200 monitor, plus the box is really just a micro-ATX box with flash memory to boot off of (the fancy ones) or DHCP/BOOTP remote boot (the cheap ones).
Face it, I don't really think you are saving much in terms of central administration because you are going to have select users that need custom tools. When was the last time you successfully had one program installed on an Windows box that wasn't instantly visible to other users on the same machine. Think in terms of that specially licensed accounting app for which your company can only afford four seats. You'll give accounting their own machines just to keep from avoiding the potential of illegal multiple installs. I could be wrong on this, but even if it is possible, the administration of such a system is non-trivial.
So how does DTW stack up anyways? Not so well in the places I've heard them trying to force it into place. In theory, it does what everyone wants to really do, but that darned software attributed of usability keeps creeping it's ugly little head up.
Re:using thin clients at a call center (Score:5, Interesting)
Re:Yes, but not anymore (Score:2, Interesting)