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
Citrix is a good option for Thin Clients if your users don't need a lot of local horse power...
What they don't mention in the glossies is that all of those users with thin clients are out of the water if the servers are down. So if you cheap out on servers and staff, you'll find your users dead in the water for hours or days due to problems that usually aren't that bad.
Conformity is the jailer of freedom and enemy of growth. -JFK
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.
allow me to offer my condolences. How early 90's.
I can't speak for Windows thin client solutions, as I haven't seen one since Citrix made an NT 3.51 X-Terminal based solution back in '96 or so. It worked. Sort-of. But my impression of X-Terminals is that when display hardware was expensive, it made sense. Today, a megapixel capable display and computer is *really* cheap. With disk and even 2D acceleration. Solve your problem with a central file server, that's what I say.
The rest of Windows brokenness is your problem to fix.
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.
At my university (Michigan State University) they use a deployment program called Rembo, and is works extremely well (manages different application sets for different computers, and even different operating system choices (many labs have multiple linux and unix choices, but every computer has at least Windows 2000 and many an XP option that is still in beta)).
Sorry for my lack of knowledge of exactly what it is, but I am a political science major and don't know that much about networking and such.
Computers allow humans to make mistakes at the fastest speeds known, with the possible exception of tequila and handguns
Your ideas intrigue me and I wish to subscribe to your newsletter.
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.
Is based on management costs, more so then hardware, then there are other possibilities. Ghost and/or Deepfreeze. Novell ZENWorks. "Just" group policy with AD, or Microsoft SMS.
My old high school (WSHS) used to have a network of about 200 computers with half of them being thin clients. If I remember correctly the thin clients ran Linux and used the XWindows GUI. They had Netscape installed locally for browsing and used Citrix to server applications through the Citrix Program Neighbourhood (It contained applications like IE, MS Office suite, AutoCAD, Photoshop etc.). The thin clients were alright when it came to browsing but when it came to using applications through Citrix it was horrible. They were really slow and using them was a painful experience. I remember doing a technical graphics and it was horrible because the clients just weren't up to the task of running AutoCAD, Architectural Desktop and Mechanical Desktop. In 2003 they decided to ditch all the thin clients and replace them with normal desktops, which was a real relief. :P
However I have a feeling that it wasn't the clients themselves that were the problem and it was in fact Citrix that was the problem. Even on the desktops Citrix would lag. I remember some teachers making requests to the network admin to have some programs installed locally on the desktops because Citrix was just too problematic. It was always crashing and their were lots of programs that completely refused to work through Citrix.
So IMO thin clients are alright as long as the software that serves them is up to the task. If it is a small network (Less than 50 computers) then Citrix is alright but on a large network it just can't cope.
Well I think that's enough reminiscing for today
I seriously doubt Microsoft's marketing department could have written a better pitch... uh, post. Hmmm...
Um, you say the clients weren't up to it, or that Citrix couldn't handle it, but the clients wouldn't really be doing anything and other posters cite citrix as being efficient. I think your situation was a server that wasn't powerful enough for the number of clients. Either add more servers, or upgrade them to multiple gig of ram and quad processor, and you can handle more clients.
Mark of the Coder fades from you. You perform Opening on World of Warcraft. Warcraft crits GPA for 4. GPA dies.
We run about 50 Wyse thin clients at the credit union I work at. They have some definite pros and cons. The nicest thing for us is that we can see the desktops of our tellers at any of our 6 branches. Makes support a hell of a lot easier. Plus if there's a power outage where your clients are, when they come back up you're right where you left off (assuming your servers are on UPSs).
Where you run into trouble is the shared server resources. If you have a few people using large Excel documents it can seriously affect performance. It can also be a problem if you allow things like Flash. A resource heavy Flash program can eat up a single CPU (core,HT,whatever) pretty easily. Also, if your servers are in a different location from your clients, a network outage pretty much means your dead in the water until it comes back up.
Currently we're about 50/50 on thin clients to PCs because some apps are just better off on a PC. Also, when you buy the clients, you might want to get ones with legacy ports. Most USB devices won't forward to the desktop, but serial and parallel will.
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.
We're starting slowly on it and only moving 25 desktops. We're limiting scope rather heavily... at my place of work, it's 'management money' to provide a desktop with basic functionality (web, office, time card, and the other stuff you need to actually be an employee). We're looking at $500 hp thin clients, which are a bit cheaper than the $1k dell desktops we get currently.
Our network infrastructure is already pretty solid. Out first server will have redundant power supplies, redundant ram, UPS, conditioned power and mirrored OS drives. Storage will be on a raid 5 array. 25 users at 80 gigs a piece is only 2T, which we cover pretty regularly with smaller arrays. Of course, they can be expanded upon. We'll be using Windows DFS so that we can add on transparently.
Certainly, it may not look cheap at first, but we're very confident that we will be able to handle all 25 clients with no issues, having quite a bit of experience with terminal services already with that number. 25x$500 savings is 12500. Our server and disks will be in the neighborhood of 8k, so we'll see some savings there. We have a special arrangement for the windows server software, and that cost is already covered.
Then we start factoring in the support costs. We generally replace desktops every 3 years. These will last at least 5. Our average desktop runs about 200W (sans monitor) and these will run more like 30W. Even with our incredibly cheap power (special arrangement with the city) we'll end up saving a not unsbstanial amount there.
Time to deal with customer will go from about half an hour to 10 minutes. If settings get messed up, reboot. If it breaks, here's a new one, here's your settings already on the server. I should mention we also have an already existing backup strategy and facility, so that will be covered automagically.
-- Who is the bigger fool? The fool or the fool who follows him? --
I have to manage a 21 user CPA firm. Thin clients work great EXCEPT when you have to deal with software that does not WILL NOT work in a terminal server (Quickbooks I am looking at you, and CCH/ProSystem fx). That and all the horrible 1980's abominations of software that accountants like to use. From an admin point of view its great, users like it also. Its just that 70%+ of the normal Windows software does not work on a server let alone a terminal server, it wants to run on a workstation.
In fact, the biggest issue has been callers sticking gum in my CD drives.
Wow!! Now THAT's REMOTE ACCESS!!!
Or was it the person answering the phone that put the gum in the drives?
We use it a lot. Linux and WinCE based.
They work with very little problems against Citrix Server. We have hundreds of these, mostly in remote locations and on small lines (64-256kbit/s).
The main gain (compared to PCs locked down) is much lower service fee for hardware, as well as for software, as it is only on the citrix farm we do most patching.
Just kidding, though if they ever put IE on it, I could do most everything on it that I'd normally do on my PC.
Having rolled out this very same configuration for a client recently I can say with some authority that the only firmware issue is the last one (black screen connection issue), the rest is Citrix and Wyse configuration mistakes on the part of the network administrators.
We had thin clients to cut costs out on the factory floor. We switched software vendors and the new vendor's app (surprise!) doesnt support citrix or rdp. So I've been setting up older machines to host the app and I have a small pile of not terribly expensive thin clients doing nothing.
I'm not saying theyre bad, just not practical or feasible for most cases.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
I used to run a 40 client Citrix network and while it has some big benefits it has it's drawbacks too.
You need to take a really good long look at what your users are doing and in your case it's going to depend what department you're in. I've consulted a bit for a uni too so I have an idea what you are looking at. Lab machines that are mostly used for preparing papers and such are a good candidate. If you can lock them down tight enough you will have much less work today distributing office app patches and such. Depends how the labs are used though, TS is not a good candidate for feature rich web surfing.
Your admin department's machines will be a bit harder. Take a walk around and get a really good idea how your users work and what apps they use. There may be a lot of little apps here and there that will cause you problems on thin clients, especially if they do accounting. Also take a look at what your users do with things like PDAs, sync software for a cell phone or something could turn out to be a major PITA. If you have more than 20% of your users that have special requirements it probably won't be worth doing. Laptops will be a major hurdle as well, if they are going to be useful away from the network they have to stand on their own.
Don't under estimate the potential for a prof to get uptight about "their machine" either, IME they don't take "no you can't do that" very well.
Windows CE may be an attractive option for you. You'll have the quintessential Windows-like interface, a ridiculously low memory interface (~400KB), and the OS itself is built into ROM - restoring the OS can be as simple as flipping a switch. Also, Windows CE is (for the most part) invulerable to viruses that plague traditional Win32 systems.
Lenovo/Neoware Thin Clients for example (not affiliated, just found them through a google search) low-end models cost >$400ea., have a 400MHz VIA processor, 64MB of RAM, 2 USB2.0 Ports, and no fans. I'm not a systems administrator, but these systems sound ideal for poorly-ventilated/cooled areas (face it, universities are full of them) where students can work on documents from their thumbdrives and browse the internet without risking network or system integrity.
Frink: Nice try floyd, but you were designed for scrubbing, and scrubbing is what you shall do.
Did the cost savings materialize as expected?
Short answer: Not really, no.
Long answer: MS's terminal server licensing has become a bit of a rip-off - in the old days, when they charged for maximum concurrent users, it was okay (one user; one license), but now they'll want to charge you for every combination of client and server that you use, and it can get very expensive if your users switch PCs (one user, as many licenses as different PCs they use to log in).
Also, you'll possibly end up paying too much for other software too, as some products don't take TS environments into account, so you'll have to buy expensive server licences rather than user licenses.
And finally, although the simplicity does make things easier to manage, it is different to a normal windows environment, so there are training costs.
Sorry.... I may sound a bit jaded, but when my previous employer implemented TS, we had the same thoughts as you, and it just didn't work out the way we planned. But by the time we realised how expensive it was, it was too late to pull out.
It's possible things have changed in the year or so since I left there, but I wouldn't count on it.
Hope that helps.
(Spudley Strikes Again!)
We ran thin clients at a residential college here in Australia. For the most part they worked quite well once we got over the learning curve.
.. thin clients really aren't cut out for that.
Two things killed thin clients for us. First, there was a trend in our computer lab of using it for multimedia work - eg photoshop, premiere
Second, licensing. It depends on the vendor, but Microsoft licensing agreement says you need a license for every single thin client. This is okay if it's something like say Office where it's quite feasible that every thin client may use it simultaneously. But for something less commonly used (eg Publisher), it's a huge cost overhead especially when only one person may use it at a time.
Since no one here has yet to mention the nightmare that security can be in a windows TS system, I will go ahead and let you know. If you care anything about security you will be paying some good money to citrix for their reporting tools that keep track of what apps which users run and such.
The main issue is that when you have multiple end users coming from the same ip address (the TS) online fraud tracking can be almost impossible if the user hides their tracks.
what do i mean?
Lets say you have 10 users all running firefox, at the same time, then one of them uses a customers credit card to buy stuff from some online store. How do you find that user? well, hopefully the online store has some good logs to help you (yeah right), otherwise you are going to be search browser history and cookie data to see which user went to that site. If the user is smart they will purge their data in such a way that only that entry is no longer in their privacy data.
Your only option is to setup a proxy which requires authentication per user and has damn good logging enabled.
Another issue is trying to lock down the TS. It can be done, but it takes a long time to get the right balance of security and usability for all the applications that your users will need to run. God help you when you get applications that refuse to install, or requires stupid permissions to run.
In the end I found that TS works for general users that use a defined set of applications.
In a perfect world these applications would be restricted to:
- simple office documents
- limited external websites (you better be using a secure proxy)
- web based internal applications (you better have strong authentication and good audit trails)
Its spelt "L-I-N-U-X", but pronunced as "Free Beer"
"...thin clients are much cheaper and easier to maintain than a user controlled desktop machine...."
Define "user controlled desktop machine". If by that, you mean you are giving users local admin rights, and/or not centrally managing your Windows computers using Active Directory, then of course moving to a thin-client solution might save some cash. But consider the possibility of learning how to properly manage your existing infrastructure. You might be able to save a ton of cash without subjecting your students and staff to the drawbacks of a thin client solution. "Fat client" management products like ZenWorks, SMS, and Deepfreeze are very costly, and worst of all, largely redundant as for the most part, they duplicate functionality that is already offered by Active Directory. They also mask the real problem - that the IT staff are basically ignorant point-n-click monkeys with little to no understanding of how Windows really works.
Once you've mastered the art of proper centralized management, you can start saving money right away. First of all, you can simply not renew the licenses of your now obsolete, incompetence-masking "management tools" like SMS/Deepfreeze. Second (and best!) of all, since you'll now be deploying software to clients from a central server, you can now lay off that dumb-ass staff member that through his proven incompetence is releagated to walking around to client machines with CD's and doing the next...next...next...finish dance. I would suggest putting on an a IT version of "the weakest link". Find a female dean - preferably a redhead to play the bitchy lesbo host. Have her ask trivia questions related to the technologies you use and internal IT policies and procedures at work. I know, I know, you're thinking "But we already know that Joe is the dumb ass we want to fire. We don't to have a trivia session to figure that out". Well, you might be right, but even though you'll probably already know ahead of time which bastard you want to can, playing the game can clue you into other staff members who might deserve to be put on the shortlist for the next round.
I'm not so old as to have completely forgotten university life... IMHO, student labs aren't that great an environment for thin clients. (Not that there are that many great situations in general!) Disclaimer: I've only been responsible for a small Windows TS install - half a dozen clients over the 'net... so take this with a large grain of salt. Here's a simple test. Turn on a basic CPU usage chart (e.g. the ubiquious Task Manager in Windows). Browse the web and do basic run of the mill stuff that a university kid would do. Remember, young folks are perfectly capable of handling a half-dozen browser windows at once. Every time that CPU chart spikes, you run the risk of a slow down for everyone on the same server. True, it's not totally comparable, but then again, you'll have 20+ users on the same machine. Every student lab needs full access to the web, including Flash, Java, and even DHTML (ok, "AJAX"). It doesn't take long before you run out of all the processing capacity that you have available. Oh, and media is becoming more and more a core part of using the internet. That's torture on thin clients. For managability, things are way better than they used to be in the world of Windows. Disk imaging software is better and cheaper. Limited access accounts are easier to setup and most newer applications are (finally) compatible with that access level. And hardware is dirt cheap -- cheaper than the comparatively low-volume thin clients -- if you get selective with CPU's, the power difference doesn't have to be that large. Plus, in the end, you'll have vastly more CPU and hard drive space "around" the network. Sooner or later someone will find something smart to do with it all... like distributed backups or something.
Though I've read up on the subject, as far as anecdotal support goes I've only seen a small number of thin client sites in recent years. However, of the thin client sites I've seen, I have to say that the ones running LTSP or a variant, have been really pleasant to use and the ones running (or more correctly trying to run) Windows-based thin clients have been poor to unusable.
A third option to consider would be to buy extra screens, mice and keyboards and go multi-headed aka "multi-seat". It'll more than do for stations where students are just using the web (to include mail) or working on papers, spreadsheets, or presentations.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
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
I recommend phoning you local Sun office and ask for a demo & quote for SunRays. I used to work for Sun and all the desks had SunRays instead of(/aswell as) workstations, and I really liked them, even being a techie - although I did have a workstation to develop on also. Recently they also support Windows as the Server/Desktop if that's what you really want (personally, due to cost, I'd go for Solaris or Linux with a Windows like window manager - at least *Nix fans can change their own WM then aswell). I haven't tried all the possible thin client options, but SunRays will be damn hard to beat! Read the datasheet here.
On a general note, I'd recommend looking at all the options in detail and compare initial cost, TCO and usabilitiy before deciding.
Time is an illusion. Lunchtime doubly so. - Douglas Adams
Simply put, thin client is usable if the server allows many users to work at the same time. It's multi-user and multi-session. Multisession means sharing, protecting, restricting resources, protecting users from conflicts by accessing shared resources, allowing them to work without interruptions from other users working on the same system.
Multisession was present in UNIX from the beginning, 70's, 80's. Linux supported multisession nearly from the start. The system was designed to be multi-session from the beginning.
DOS was strictly single-user.
Windows 95, 98 made first lame attempts at multi-user. WinNT provided something called terminal services but that was just multi-access to common shared resource. Win2K didn't really move ahead. WinXP tried the first pseudo-multisession, similar to win3.11 pseudo-multitasking - user switching.
The first real multisession, with great fanfares, came with XP Service Pack 2, allowing multiple users to conveniently, safely and without problems use the same machine simultaneously. In this case "multiple" meaning "two".
If you want to try out the Microsoft's bleeding edge technology, feel free to do so.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
My suggestion is TEST IT yourself, to help you make your decision on how to do it.
5 4-321959-89307-338927-89307.html/
There are plenty of others.
But know you need to answer the following at least first:
What kind of server are you going to run? Windows TS, Citrix, or Linux? If you're a Windows Admin who knows user management, Active Directory, and GPOs already, then the learning curve is shortest to the Windows TS. Citrix will mean learning it as a whole new server application. And Linux will mean knowing Linux and having apps that run on Linux.
What kind of thin client are you going to run? The thin client has to support connecting to the type of server you chose. Besides Linux thin clients, which by the way can connect to Windows TS using "rdesktop", and do so quite well, there are two kinds of Windows thin clients, CE and XP-embedded. OH, and just because you know Windows desktop OS's, don't think that immediately translates to knowing how to configure Windows thin clients, CE or XP-embedded. They are a wholly separate beasts.
And then you have to decide if you are going to centrally manage the images of the thin clients or not. You can configure them each individually, or you can set up a PXE server, and boot your thin clients from images you've prepared and stored there. I think some thin clients can be set to autoload their images from FTP or TFTP servers also. But centralized thin client management is a whole other project that you may not have the resources to implement and maintain.
As someone else on this thread mentioned, you have to know if the applications you want to run in this setup will run in the server/client configuration you choose. And the only way to know this, may be to try it. For example I'm currently implementing and ERP application, that won't run via the Windows CE thin clients, but will run via the Windows XP-embedded thin clients. (But I'm running them via Linux thin clients.)
Remember you can test your thin clients with the administrative TS that comes with every Windows server.
Here you'll find examples here of some decent thin clients:
http://h10010.www1.hp.com/wwpc/us/en/sm/WF04a/124
I'm using the HP t5525 Linux Thin Client with Windows Server 2003 R2 Terminal Services. This works great. I don't have time right now to deal with the central administration of images, so I spent a morning figuring out how I wanted to configure the t5525, and listed out instructions on how exactly to end up with the same config each time we need to configure one manually. Two of us set up a room of 10 of these, unpacking, hooking up, and configuring, and test connecting to Win TS in 40 minutes.
I tried a t7510. It would be a great "grandparent PC" for a grandparent with broadband who wanted to web-browse (and maybe get sued by RIAA by downloading music and videos to play in Windows Media Player). But it was too quirky and different from XP-desktop to know instantly how to configure/maintain it. And again, I didn't need all the crap it came pre-loaded with. This is supposed to a "thin client" running apps on the TS, not a "thin client" running apps on itself.
Anyways, the cost of the thin-clients is so low, you really ought to get a couple and try them yourself, before you commit to your grand solution.
WIndows thin clients cost MORE than desktop PCs. Support is a nightmare for all but the most popular applications. No vertical software vendor supports running their stuff on Citrix.
we have a mix of wyse and CLI terminals in our environment numbering somewhere near 35000. Call volume has dropped almost 50% over the last year, first call resolution is up, number of escalated calls are down. as far as success stories go, we're one of them.
Your sig(k) has been stolen. There is a puff of smoke!
For upper-year CS students who needed to run compute-intensive apps, we still used workstations, so they'd only hurt themselves when they write a runaway cpu-hog (;-))
Another institution we knew, in Holland, used X-terms and the Win4Lin terminal server product to provide Windows apps to their Sunray clients, at a very low cost.
If you do go the Xterm/Sunray route, you will need a service machine in the lab to stick CDs into, preferably on the desk of the lab monitor. If you gut your lab PCs and run LTSP and RDesktop, you can probably skip that step.
--dave
davecb@spamcop.net
To a great extent the answer is it depends. I have had experience with Citrix in two different environments. In the first I was not directly involved but it was closer to what you are describing. It was a school lab situation.
The problems they ran into included multiple logins or simultaneous reboots are an issue. You essentially have all the machines hitting the server at one time. The hardware requirements that their vendor recommended were woefully inadequate. What was supposed to handle 40 users started to degrade at 10 and would start to fail around 20 or 25. The initial server was scraped and replaced with a much more robust solution. This issue was at least partially a vendor issue.
The second implementation is the one I support now. From this one I can say that ICA is not in my environment as fast as being on the local LAN if you are going over a busy WAN connection. I have not measured this yet but my theory is this is more related to latency than actual bandwidth exhaustion. On the LAN Citrix or Terminal Server are both very nice. Printers are a beast. This won't be much of a problem in a lab environment since it's just a mater of making sure you purchase printers that work but for an environment where you have people using home equipment it's a complete headache. Citrix knows this is a problem and things are getting better.
One of our apps is a resource hog so publishing it was horrible for the server. You definitely want to profile any applications before the implementation to make sure that they will work in a multi user environment. Thankfully this app is very rarely used by my Citrix users.
Something you probably want to consider is teaming the servers so if one goes down you do not completely loose access. Don't forget you have to be able to carry the whole load with missing machines or you are wasting your time.
My experience in both environments is that you can never lock the desktop/server down as much as you would like to. If you have a "nice" user base this may not be a problem but if you have people who want to tinker this can be a huge problem. Citrix does offer some advice and it will get you part way. Unfortunately anything that people can do to your locked down PCs now they will be trying to do to your server in a thin client environment. Personally for ease of management, I like Deep Freeze. That is the product that the university I worked for went to a few months after I left and the last time I asked they were having great results. But I know that is not what you are looking for.
I have a Esprit 100-TCE thin client. I just wish I knew enough about it and porting linux to replace WinCE on it with Linux.
*It's not what you can do for the Dark Side but what the Dark Side can do for you!*
Here are specific plus and minus things we have run into that haven't been mentioned.
Thin Client Plusses:
1. I don't have to run Windows update on all those PC's
2. Easy to enforce policies
3. Users can switch locations easily
4. Last a long time (most of ours are 6 years old but only our newer ones accept a wheel mouse)
Thin Client minuses:
1. If the server goes down, everyone goes down
2. Some peripherals like scanners need PC's
On another note, if you use Microsoft TS CAL's, be sure you set it up as "per user" rather than "per device". They don't really know how to count the "per user" ones yet so it just looks for 1 license. The "per device" one remembers every device that signs on for one time and is harder to manage.
but beware of thin clients based on Windows XP Embedded. This is basically a "dumbed down" version of XP, meant to run a few local applications (browsers, media players, etc.). However, being XP, they are susceptible to many of the same vulnerabilities that "fat" XP is. Vendors will tell you that they're immune because they use "nonwritable storage." The problem is, that's not really true. They use a "RAM disk" scheme that is basically a reboot-to-discard-changes operation. While the system is powered and on the network, it's a target, and seeing how many zero-day XP vulnerabilities there are, you're forced to keep chasing this security target for eternity. There goes your supposed lowered TCO...
a sp
We have tried Wyse and Neoware clients based on XP Embedded. They both functioned OK. RAM limitations for the RAM disk were the achilles heel - lots of apps (IE, QuickTime, Real & WMP) expect a disk to use as cache. It will work, but you have to pay attention to application-level caches. As I mentioned, the REAL problem with these systems is that you have to manage them just like fat clients - patch, patch, patch, reboot, patch, etc. We absolutely hated the Wyse Rapport software. Neoware's was easier, but the delays in getting XP Embedded specific patches from either vendor was unacceptable, despite the fact that these systems were vulnerable to the same errata as "fat" XP.
The next style is the Linux-based thin client. These are far slimmer (less built-in code) than their XP Embedded cousins, often running on much lower powered platforms (PPC is quite common), making them much less susceptible to common Linux-on-X86 vulnerabilities. I haven't tried them yet, so I can't speak to the management scheme. But, I figure it's somewhere near the XP Embedded space - you still have multiple boxes sitting on desktops that need to get upgraded from time to time. I just think the fact that Linux thin clients are so much slimmer makes them far less likely to be exposed to the same risk as XP Embedded.
My favorite thin client architecture thus far is the Sun Ray platform. This is a TRUE thin client, in that the clients don't really run any software. For the most part, they behave as an Ethernet-based remote KVM. Add smart card-based "hot desking" and you have a truly usable "network computer" environment. They even run RDP for running Windows apps now. The best thing about Sun Ray is that software upgrades are done on ONE BOX (the Sun Ray Server System server, which can be Solaris or Linux). At most, you have to manage a handful of servers, if you run a cluster. But these are all in the same room, right next to your professional sysadmin, who keeps on top of patches and locks it down right. Very much a different beast than a box on every desk.
eWeek has a special report on thin clients; http://www.eweek.com/category2/0,1874,1725167,00.
Good luck!
Charles
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
This isn't just games. Example: A government site might (and some do) require running a specific (Windows Only) application. The application might (and at least one does) write various configuration files to various places with NO idea of sharing. To use thin clients in this situation I've only seen 3 choices:
Let users write over each others files (bad)
Let one user have total configuration control (not quite as bad sometimes)
Go in and tweak the app somehow so each user has their own configuration filespace (Often doable but forget about support)
Microsoft Office apps are not among these but an awful lot of 3rd party apps are, companies aren't necessarily interested in worrying about the (currently small) slice of the market that uses thin clients.
I really hope thin clients catch on enough that the above gotchas go away.
Thinstation is so nicely customizable. We've converted two labs now, and the big big win is that you can make the labs multi-platform without needing a reboot.
A rack of dells, some Windows TS 2003, some Linux (Ubuntu), and then you write a custom 'chooser' that runs on Thinstation and lets the users decide.
We avoided Windows License Hell because our central IT services have a TS license server. Doesn't avoid Application License Hell though. We cant get Version 15 of Random Stats Package working because it only lets you run on the console with its license restrictions, until Central IT Services set up a license manager...
Do it. We had one lab of 25 people logged into one Windows box (dual 2.6GHz/4G RAM I think) and all running Matlab, Firefox, and the CPU didn't hit 60% (and I dont think thats because the network was the bottleneck). 95% of the time people are just wondering what key to press next in a lab environment.
Barry
I tried to do this for a small startup about 2.5 years ago. I used Wyse WinTerms, a couple of good, beefy HP servers and Windows Terminal Services for roughly 30 users. The biggest issue I ran into was local devices not working. We just had too many times where someone needed to use a CD-Rom, a PDA, etc. and it just didn't work. It was supposed to but didn't. You really need to look hard at how your users use their current enviroment and make sure they can still do the same things as easily as they do now (or get an policy in place that says they can't do those things). I would imagine in a school enviroment that flash drives are used heavily and I'd be sure to make certain that data can get passed easily from the citrix/terminal server to the client to the flash drive.
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
There's a column by Tom Yager in the current (5/8/06 issue) of Infoworld that talks about this subject from an interesting perspective: that server based applications and virtualization of the servers and by extension the applications so that thin clients may be all that's required in certain applications.
I can't say whether your environment would benefit, but it's another way of looking at the question.
Interesting that the school setup 3 IP's instead of just one Virtual Server with network load balancing and session directory to handle it all...
With a network load balanced cluster you just setup one virtual IP say 192.168.1.100... and then the session directory would automatically assign an RDP connection to each of the three servers based on network load... for example 192.168.1.101, 192.168.1.102, 192.168.1.103... one note though... all the terminal servers must be on the same subnet in order to be in the same network load balanced cluster... so perhaps the IP Addresses on those thin clients are on different subnets?
Seems strange anyways...
Addbo
What are the thin clients available for linux and freebsd ?
Chris ,
Php Programmers.
As others have commented, the problem was most likely either with a poorly set up Citrix environment or with apps that just don't play well with Citrix.
I'm the sole local tech support for ~500 thin clients and 100 full PCs, which access Citrix from a farm located half way across the country. We're just one of several remote sites all accessing the same servers. It's not always lightning fast, but overall it works just fine. I think that the key is making sure that the servers in the Citrix farm are adequate for the job, and that load balancing is properly implemented.
BTW, from a support standpoint there's no comparison between thin clients and PCs. Despite a firewall with some fairly restrictive rules regarding where users can go on the net (it can't be blocked completely- they need net access to do their jobs), the PCs are a constant spyware headache for me, and also seem to have significantly more hardware issues than the thin clients, due to the complexity of the machines and the greater number of moving parts (i.e.- more than zero).
Boundless Expansion, Self-Transformation, Dynamic Optimism, Intelligent Technology, Spontaneous Order- BEST DO IT SO!
It sounds like you're approaching this exactly as you should, and with full awareness of the pros and cons.
You're probably already planning this, but I'll go ahead and give you some unsolicited advice anyway- rather than a single Citrix server, start setting up a farm ASAP. It's overkill for only 25 thin clients, but the redundancy will significantly reduce any downtime due to server failure (theoretically to zero), and as your thin client environment grows the advantages gained through load balancing are enormous.
If your budget allows for it, it's better to have the capacity now than to wait until the users are complaining about slow performance before reacting. It'll also be better for both your server admin(s) and your desktop support to start out with a "server farm mindset". In our environment any widespread issues typically only affect a single server, and it's good for the troubleshooters to be in the habit of making that one of the first things they check.
Boundless Expansion, Self-Transformation, Dynamic Optimism, Intelligent Technology, Spontaneous Order- BEST DO IT SO!
The newer HP thin clients (like the 5700) feature embedded Win XP, rather than CE. We've just recently migrated to them. They're more capable, though I've found them to be trickier to configure. This could just be bias on my part, as I've been working with CE-based thin clients for years and the XP ones are new to me.
Boundless Expansion, Self-Transformation, Dynamic Optimism, Intelligent Technology, Spontaneous Order- BEST DO IT SO!
If I could mod you +6 I would. I think that you've summarized and expanded on every worthwhile point in this entire thread. I've done configuration and support for thin clients off and on for the past 4 years or so, and I can't think of anything to add that you haven't already covered better than I could.
Boundless Expansion, Self-Transformation, Dynamic Optimism, Intelligent Technology, Spontaneous Order- BEST DO IT SO!
Ironically, I'm typing this on a Sun Ray "client" (I'll resist the temptation to quibble with that word) that's connected to a Solaris system. I have no idea what OS the Sun Ray runs, but I'll bet it's not Solaris!
I work for Sun and we use Sunray thin clients for our desktops. I really like it. Low power, no noise, efficient desktops. With Sun Ray Software 4 you can deliver windows, linux or solaris desktops!!
Check out Sunrays: http://www.sun.com/desktop/index.jsp?tab=1
Check out Sun Ray Software 4: http://www.sun.com/software/sunray/index.jsp
I designed a 5,000 seat farm for a particular bank, based on the Citrix XP backend. Ignoring the usual cock-ups and mistakes that come from working in an enterprise environment, the development and implementation was pretty smooth. From a Windows perspective, TS out of the box will give you a good experience. Whether you goto Citrix or not depends how much you wish to tweak the end user experience (you can do different configs based on different ip addresses, good for low bandwidth connections) and whether you need the "enterprise" level features "out of the box", remembering that you will be paying enterprise prices for that level of user licensing (features like resource and summary database for reporting, integrated billing, advanced load balancing, snmp integration etc etc) Citrix also does companion features which can also provide a technical edge - for instance allowing you access to applications based on ip address, so for instance you can't access the payroll app if you are sitting at home. On the potentially darker side, it can have great shadowing features and thus in terms of helping users its a great boon. There is also a feature coming up where you can record user interaction for later (mis)use. Better shutup about that since I'm on slashdot here :)
On the terminal side, Wyse have a great range that includes their own OS, Blazer and Linux. Blazer is more lightweight, XP is the largest. You still have to patch XP but Wyse does the legwork in indentifying the patches and getting them on their website (forget the rubbish later on in this thread, you do need to patch them and no nobody from MS claims you dont need to!) Rapport is reasonable at maintaining the image. Wyse now have an addon to stream custom OS' images to the thin client based on logon details now - Blaser is very lightweight so this is possible. We have keyboards with smart card readers integrated working, so they are pretty flexible.
Finally, have a look at x64. The comments on this page about lack of scale and stability are criminally outdated. Windows x64 doesnt have the 2GB addressable memory segment, which was the limiter to the number of users that you could get on one host using 32bit Windows (nos profiles in working memory etc.) So with x64 you can now scale up a box rather than scale out and achieve a decent user count rise as you add CPU/memory.
In my opinion Thin Client is a viable technology for the basic knowledge worker. It cant replace laptops altogether at this point but certainly it will reduce your TCO in certain areas.
At my work we have a problem with machines exposed to mechanical damage. We're trying different things, but one thing I really like are VNC approaches. Makes it easy to troubleshoot, very flexible. We put racks of servers in and have KVM etc out on the floor. If one of the cheap machines on the floor gets destroyed no problem, we don't even have to have downtime.
There are kvm solutions over ethernet that are worth looking into.
Man, you really need that seminar!
<quote>WIndows thin clients cost MORE than desktop PCs.</quote>
/Citrix solution with accompanying applications.
INDEED!!! Certainly terminal solutions are more expensive for low user counts. It becomes more economical with more users.
Wyse Terminal Client $500
Flat Panel Monitor $250
Windows 2003 Server CAL $60
Windows Terminal Services CAL $85
MS Office 2003 Standard Edition $376
HP/Dell Server Hardware ~$350/user
Microsoft Server License $$$/user
Citrix Licenses $$$/user
Antivirus software $$$/user
Total Greater Than $1,371/user
Alternative Dell Optiplex Desktop flat panel monitor with XP and MS Office plus more software $1,270
For those that will say; 'Use LTSP, it's free!'. I say; get a life!
First, it's all about the applications. They want/need/require Windows applications on the desktop. That mandates a Windows Terminal Server
Secon, good luck finding a client terminal that supports X11 for under $500! No I'm not interested in using junk PCs off of eBay. I need to be able to call a vendor and order 200 identical, new, under warranty, ready-to-go units!
it may be worth it for difficult to deploy applications but it will never be as responsive as a PC and will be totally useless if lots of people wan't heavy processing.
for the computer labs imaging combined with an auto deploment tool like the one from zenworks is probablly the best method.
For amdin staff just make an image with everything they need and depending on the severity of the problem either swap out the system drive (or reimage immedidiately if you can get the image size down to something where this is tolerable) or reimage them the following night depending on the severity of the problem.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register