Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Windows Thin Clients - Worth Making the Switch? 128

Posted by Cliff from the cost-analysis-and-tradeoffs dept.
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?"
This discussion has been archived. No new comments can be posted.

Windows Thin Clients - Worth Making the Switch? More

Windows Thin Clients - Worth Making the Switch?

Comments Filter:

  • Yes, but not anymore (Score:5, Informative)

    by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Tuesday May 09, 2006 @10:14PM (#15298277) Homepage Journal
    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.

    • Re:Yes, but not anymore (Score:4, Interesting)

      by online-shopper ( 159186 ) on Tuesday May 09, 2006 @10:53PM (#15298460)
      You could also look at using LTSP as a way to bootstrap thin clients to talk to a Windows server. you still have to deal with half of the MS licensing stupidity. Though you might consider using LTSP to hook up to a linux server. The project has seen moderate success in a variety of situations.

      • Re:Yes, but not anymore (Score:4, Informative)

        by Eil ( 82413 ) on Wednesday May 10, 2006 @01:28AM (#15298974) Homepage Journal
        We've done exactly this for a number of customers. The thin clients boot up, grab a kernel from the LTSP machine, then start X and a copy of rdesktop pointed at the Windows terminal server. The only major downfalls are that things like printers, USB devices, sound, and local removable media do not automatically get passed to the server. I understand that some of these are actually being worked on. We've also had a couple of employees complain that they couldn't play their music CDs in the machine. (And one of those actually had a brand new company-provided FM radio/CD player sitting on his desk right next to him...)

        One word of caution: If you plan to run Windows 2003, do not expect certain peripherals (scanners and printers, mainly) and software to work properly. Since it's touted by MS as a server OS, many driver and application developers specifically exclude it from the software's internal compability list and the software will refuse to install. If you think you'll be hooking up a lot of peripherals or running a lot of odd little applications, consider Windows 2000 instead, which unfortunately is pretty much unsupported by Microsoft these days...

        • Re:Yes, but not anymore (Score:4, Informative)

          by override11 ( 516715 ) <cpeterson@gts.gaineycorp.com> on Wednesday May 10, 2006 @07:45AM (#15299899) Homepage
          The latest LTSP (which we recently upgraded too) supports locally connected USB devices (mice, thumbdrives, scanners, etc), and they can even be shared by multiple users! We have 45 users running off a single LTSP server (dual 2.4 ghz, 4 gigs RAM), providing OpenOffice, running Mochasoft through Wine (dont ask), Evolution email, firefox, etc. Runs really nice, and so easy to maintain!
        • I must disagree with the Windows 2003 statement. I run Meedio as a media center on 2003. All my peripherals work, including the MS Media Center only remote control and keyboard. All my software works, including fingerprint reader, winamp and nero. If I can use it as a media centre most business will have no compatibility issues (and incidentally Citrix now has specific features to deal with twain devices now.)
      • The Linux Terminal Server Project [ltsp.org] aka LTSP would be the way to go. Based on what I've read, which is a fair amount, it's faster, cheaper, lower maintenance, more secure, more flexible, and has lower systems requirments than the corresponding MS Windows offering. If you want a real-life case study, then Portland, Oregon schools [k12.or.us] are the place to look, they're not afraid of MS sales teams any more and don't mind being public.

        Though I've read up on the subject, as far as anecdotal support goes I've only see

        • Multi head would also be what i reccomend, you get some cost savings and also more reliability.

          Thin clients suck for student computr labs. When each student tries to log in at the same time the server can get really bogged down and the ones at my old college used to take about 5 mins to log in. Also if you develop a problem with any of your terminal servers, or for some reason there are netwrok issues the whole setup goes kaput. You don't just lose 1 machine, you lose 30. Thats very hard for normal peopl

    • 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

      • Re:Yes, but not anymore (Score:5, Informative)

        by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Wednesday May 10, 2006 @12:11AM (#15298749) Homepage Journal
        User's reasons include: insufficient bandwidth to display the graphics I use,

        This wasn't an issue with ICA. Modem speeds were more than enough for our users to feel like they were at work. 10MBit LAN connections hooked up to a hub made their thin clients seem like they were flying. (Granted, this was back when Windows was designed to run in 16 - 256 color modes.) I wouldn't recommend playing a video game over ICA (though you could), but everything else from Word to Videos worked great.

        insufficient dedicated CPU time for the programs I need to run

        This wasn't an issue for us. For most office workers, CPU simply doesn't matter as it's underutilized anyway. You need very powerful apps that are generally outside the purview of office workers to make a dent in the CPU power.

        and "one network glitch and the whole enterprise stops working."

        This was always an issue. Thankfully, the network was stable and the the machine was mostly stable. So we were usually able to schedule downtime outside of business hours. In the few cases that a reboot was necessary during business hours, it was usually quick and not much different from a user perspective than losing access to some sort of client/server application. Plus, they actually knew it was down as opposed to getting a cryptic "cannot connect to server" message from the client software.

        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.

        Citrix WinFrame was so nice for this. What you'd do is you'd create a desktop type for each category of user. (For us it was by department.) You could configure this desktop to have access to specific application icons, and no others. Security could be reenforced with Windows ACL permissions aligned to the same users. You then save that desktop configuration and assign it to as many users that needed it. There were a few oddballs who had very specific requirements, but it was easy to meet their needs with all the regular Desktop support we *didn't* have to do.

        When Microsoft released Terminal Services, they screwed up many (most?) of these features that made it a workable concept.

      • Re:Yes, but not anymore (Score:4, Informative)

        by llefler ( 184847 ) on Wednesday May 10, 2006 @12:53PM (#15301953)
        Good luck buying a thin-client for under $400.

        You're just not looking very hard. I have two terminals that I purchased new for $150 each. Even if you match it with a 17" LCD you can still come in under $400.

        http://www.ntavo.com/ [ntavo.com]

        I'm not affiliated with them, just purchased a couple terminals to demo to clients. They support X and RDP.
    • The winstation code that makes up Terminal Services in modern-day NT was, for the most part, the code developed by Citrix that would have been the new WinFrame hotness. Microsoft simply licensed it from them and incorporated it into the base OS. Microsoft added hooks for their RDP protocol, Citrix still offers you hooks to bolt on their ICA protocol, high-end management features, published applications, security tools, all the good stuff... as part of their add-on package.

      Users can still be shadowed, you

    • Experience at a Health Authority: Positive (Score:5, Informative)

      by addbo ( 165128 ) on Wednesday May 10, 2006 @11:59AM (#15301535)
      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

      • (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).

        You mean to say that your users boot up a Windows system for the sole purpose of accessing another Windows system? Oh well, given today's do everything with a PC [slashdot.org] mentality, that's not too suprising. But you have to admit it's a little weird.

        Ironically, I'm typing this on a Sun Ray [sun.com] "client" (I'll resist the temptation

        • You mean to say that your users boot up a Windows system for the sole purpose of accessing another Windows system? Oh well, given today's do everything with a PC [slashdot.org] mentality, that's not too suprising. But you have to admit it's a little weird.

          Well, what exactly do you expect? The thin client has to run something, no matter how minimal it might be, in order to start up what ever type of terminal service, be it VNC, X11, RDP, etc. It may not be a full featured OS, but it will be an OS. If it

          • It may not be a full featured OS, but it will be an OS. If it didn't, it wouldn't be a thin client, it would be a dumb terminal.

            In point of fact these machines are closer to to dumb terminals than any kind of real "client". All they do is download a video stream and upload mouse and keyboard events. They're not really "clients" at all. They're only called clients because the first machines created to serve this kind of market actually were designed as clients that downloaded application software (usually

    • Many of the so-called "thin" clients nowadays are based on XP embedded... I would avoid these things like the plague!

      Of the ones i saw, they all had 256-512mb of ram, and XP embedded is almost a full copy of XP, complete with the normal problems but harder to install patches on.
      It seems incredibly stupid to use a fully featured OS to run a remote desktop client and nothing else, users could break out of the rdesktop client and access/abuse the local machine.
      • Sounds like a poor implementation than a problem with XP Embedded considering the installer gives you the option to strip out practially everything. 256megs of ram isn't even required for XP Pro let alone embedded.

        My experience with XP embedded in the kiosks we provide at our auctions is that they are quite reliable and easily locked down provided you set the right policies and don't install stuff that is not needed. Yes, it can be full featured but if its a thin client it makes no sense to do it.

        So we a

  • Citrix (Score:2, Redundant)

    by $exyNerdie ( 683214 )
    Citrix is a good option for Thin Clients if your users don't need a lot of local horse power...
    • In addition to that the Citrix client can run it on Linux based thin clients like the one I am typing this in http://www.sigsegv.cx/hp-thin-client.html [sigsegv.cx] (I am a big fan of "eat your own dogfood"). Personally, I have replaced the OS, but in an enterprise environment you are obviously better off keeping the original and using bundled Altiris for management.

      Based on the stuff shipped by HP, my overall impression is that while Thin Client Winhoze starts lower than Linux (at 64MB RAM/64MB Flash), it becomes viabl

  • Watch the "savings" melt away (Score:3, Interesting)

    by duffbeer703 ( 177751 ) on Tuesday May 09, 2006 @10:20PM (#15298311)
    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.
    • 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.

      Definitely. And in my experience (we use a lot of Windows 2003 terminal servers), there are server problems fairly regularly. Some examples:

      - We have to relax security in order to make crappy applications work. A disturbingly large percentage of so-called "enterprise" software vendors still aren't writing their apps to work using the security model that MS has been recommending s

      • 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.

        Definitely. And in my experience (we use a lot of Windows 2003 terminal servers), there are server problems fairly regularly.

        Sure but these days even desktop users rely heavily on the network for things like shared storage etc. If your infrustructure isn't up to snuff you have problems no matter what. I havn't set up a Windows TC in a real production enviornment but uptimes for

        • One thing to note is the way shared memory works on unix/linux compared to windows.

          Windows can do shared memory on DLLs only, and it goes based on the name of the dll.

          Unix does shared memory on libraries and binaries, and it works based on inode...

          If you have apps with a tiny executeable and the rest of the program code is loaded from dlls/libraries then this doesnt make much difference, if your running apps with big executeables then windows will be at a huge disadvantage.

          Also, they way dlls are referenced
    • With most corporate environments, the users are screwed anyway if the network is down. Where I work we depend on a CRM, e-mail, and several internal websites to do our work so if the network is gone we might as well be on thin clients. About the only advantage we have having desktops is it means we can play Solitaire until the network's back.

      Thankfully, total network outages are pretty rare here so far.

  • My school uses thin clients and they're annoying (Score:4, Interesting)

    by nxtw ( 866177 ) on Tuesday May 09, 2006 @10:22PM (#15298321)
    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.
    • 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.
    • 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 t

  • using thin clients at a call center (Score:5, Interesting)

    by Anonymous Coward on Tuesday May 09, 2006 @10:23PM (#15298327)
    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/ [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.
    • Thank you. We appreciate the kind words.

    • Re:using thin clients at a call center (Score:5, Informative)

      by bucketoftruth ( 583696 ) on Tuesday May 09, 2006 @11:19PM (#15298572)
      I have to give props to the parent. I've spent a while searching for a good thin client system and have finally settled on LTSP. Amazingly easy to set up and amazing documentation. The kind of documentation that gives real answers, doesn't just lead you on a wild google chase. I'm impressed how fast it is.

    • Re:using thin clients at a call center (Score:5, Interesting)

      by NefariousAryq ( 896696 ) on Tuesday May 09, 2006 @11:59PM (#15298713)
      We also use LTSP, but in a completely different style. We operate an event photography business, where we go out and photograph all sorts of school events and sports; Soccer tournaments, Baseball tournaments, Show choir competetions, etc. Three years ago, we were printing thumbnails of the images we took, where parents could view them, and place an order on paper of what they wanted. Now, due to LTSP, we have viewing stations. Most weekends we deploy between 12 and 18, depending on the size of the event -- but we have, and have the ability to operate 30 at any one given event. We've done events where all 30 were in use at one time, and everything works perfectly. We have a custom-written web-based application which handles everything for us. We dump the photos into directories, Imagemagick comes in and makes all of the thumbnails for the parents to view. The thin clients run IceWM with Firefox in a customized/trimmed-down full-screen mode, which automatically boots up in that mode, with the application as the home page. Parents can then view the photos right there, on the screen, add images to their shopping cart, and complete the checkout process. We initially looked into Wyse thin clients, using a Windows-based server setup. The cost was going to astronomical, in licensing fees, compared to what we ended up paying using Linux and LTSP. Our server runs Slackware, which we did go ahead and purchase to support Patrick. The server, which I built, is a dual opteron setup with 2gig of ram. It handles everything we can imagine it needing to do. Alright, I've gotten a bit off-topic here, but thanks to LTSP and Slackware/Linux, we're kickin. :) ~~Aryq~~
    • I have also deployed LTSP and PXES at call centers. We deployed using Gnome and CentOS 4 to over 40 desktops. We ran into a few problems with the inital rollout with LTSP which prompted a switch to PXES in one case. Namely, LTSP depends on NFS to load the kernel. For some reason, we couldn't get NFS to work on the network in one office... and we still haven't figured it out, because it works fine at two other installs. It was a headache and a half. Terminals would freeze halfway through the day when they l
      • Running an opteron in 32bit mode is a mistake...
        You could have a 64bit kernel and a 32bit userland, ala solaris... But with a 32bit kernel, you significantly lose performance when you go over 1gig of ram since you have to use nasty kludges like highmem.
    • 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?
  • 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 you
    • And of course hardware costs are the biggest cost in a large IT shop?

      I come from a mainframe/mini background centralised processing is cheaper than distributed.

      The down side is how much It process and procedures get in the way. I'm watching my current IT dept. implode due to management insisting things are done a certain way. We're unable to help users in a timely manner due to the checks and controls management have imposed. This is not good.
      • Oh, of course not. But the issue is whether the same configuration constraints could be imposed with either alternative. On 'nix, yup. As for Windows... eh, not my problem. I do wonder if it is truly impossible to constrain a Windows deployment without the use of thin clients though. Seems unlikely to me.

        On the management side of things, bad decisions lead to bad -- and often costly -- results, regardless of platform.

  • Worked great with Unix (Score:5, Interesting)

    by hazem ( 472289 ) on Tuesday May 09, 2006 @10:31PM (#15298363) Journal
    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.
    • man, it sounds like those thin-clients really SUCKED.

      literally..... I mean, I've never actually heard of computers, let alone thin-clients that had intake fans powerful enough to pick up nearby objects off of the desk and suck them into the machine, nor have I ever heard of a computer sucking up a nearby liquid and commiting suicide by doing so.

      it's definitely sucking [youtube.com]
      • I like the pun...

        The intake vent was on the bottom, and the little spacing feet are only about 1/4 inch tall. So, if a piece of paper slide under there, it didn't take much to pull it up and block the intake vents. It probably would have been better to use a smaller fan and have the vents on the back or sides.

        The cool part was that they used a 12V fan, but actually had it hooked up to the 5V rail to make it run quieter.
  • At my university (Michigan State University [wikipedia.org]) 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.

  • My experience (Score:5, Informative)

    by Devoir ( 973883 ) on Tuesday May 09, 2006 @11:12PM (#15298536)
    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.
  • Comment removed based on user account deletion
    • 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.
      • You did not completely grasp the content of his problem

        ...the clients just weren't up to the task of running AutoCAD, Architectural Desktop and Mechanical Desktop...

        In exploring deployment of thin clients in a University Engineering department, I find the same issues. Regardless of the specifications of the server or infrastructure, if the Engineering Application was specifically designed to function on a single workstation, no amount of configuring, third party packagers, or hacking will make the applica

        • Correct me, if I'm wrong, but isn't the idea behind thin client so that it only displays results of programs running on server? Since most TC I know of don't have hard disks and have only enough functionality to load OS image FROM server, how would they run CAD software? In that case it's still problem with server, not thin client. And yes, I know that there is a multitue of software that simply won't run on server. But as I understand, unless you have a normal PC with OS installed and use Citrix to use onl
        • To second trochej, I don't understand why any program at all would have a single byte of memory on the thin client. I don't have any experience with Citrix, but I've seen terminal server. Above posts indicate that they are the same technology. In terminal server, all the client is doing is displaying a virtual desktop that it receives, in the form of graphics commands, from the server.

          So, regardless of the type of application, the client just paints. It needs no more memory than the size of the screen

    • 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
  • 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 seriousl

  • Give PXES a try (Score:5, Interesting)

    by Lisandro ( 799651 ) on Tuesday May 09, 2006 @11:34PM (#15298617)
    It's not a Windows solution, but PXES [sourceforge.net] 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, conditione
    • I should add that there is a lot of cost savings in maintenance. Control of the user's desktop has an amazing impact on security costs.
    • 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 e
    • Geesh, only 25 users? I guess it's a start and can a huge Windows box really be reliable as a server for even 25 users? I hadn't thought Windows had reached the reliability of *nix yet and THAT was why Microsoft purchased VirtualPC and why VMware was soo popular. You might want to rethink the costs because your prototype system might not match realworld. ie, you'll probably end up having to spawn off a whole bunch of servers so that when one crashes( Windows, not hardware ) not everybody and everything runn

  • well (Score:2, Informative)

    by i_c_andrade ( 795205 )
    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.
    • FYI Quickbooks can be made to work under TS. There are a couple small permissions issues with restricted rights users but you can follow this [quickbooksgroup.com] link to find out what permissions need to be changed.
  • 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.
  • 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.
    • build up some stripped down VMware images and install that problem application and VNCServer on the image. Now, copy this image 4 times and put a loadbalancing router in front of VNC's port 5900. Now, you can have 5 simultaneous users of this application for the cost of some extra memory and disk space on one computer/server.

      And put Linux under those virtual machines( as the host OS ).

      If you're purchasing a new computer for this, the lastest from AMD and Intel support Zen's virtualization of Windows VMs are
  • 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 an
  • 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 [ibm.com] for example (not affiliated, just found them through a google search) low-end models cost >$400ea., have a 400MHz VIA processor, 64MB of
    • 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.
  • 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
  • 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.

    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 .. thin clients really aren't cut out for that.

    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 whe

  • security is critical (Score:2, Informative)

    by datazone ( 5048 )
    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
    • > 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?

      Ummm... Let them connect to the outside world only via proxy to which they need to login?

      Easy one...
    • Citrix 4.0 has a bit of virtualization built into it. It allows you to publish an application in a sandboxed environment. You can, for example, install office 97 and 2003 on the same machine.

      It's pretty cool.
    • Trying to secure msoffice so that users can't use it to execute arbitrary programs is a mammoth task, especially if those users will demand access to macros and such...

      Having done many pentests on citrix/rdp based systems, none of them have been secure, and the ones which give you access to msoffice are by far the easiest ones to break.
  • 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 un

  • Excellent for Managability, Steep Initial Curve (Score:5, Informative)

    by W. Justice Black ( 11445 ) on Wednesday May 10, 2006 @04:48AM (#15299494) Homepage
    Obligatory Background:

    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 :-/ ). 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.
    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
    • 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.
    • Serious but offtopic question:

      I've been using solaris in some capacity since 2.5 or so. While I cut my teeth on SunOS 4.x on a sun 3/60, that's before I really spent more than 4 hours at a time on a regular basis in front of a Sun.

      Does anyone at sun really use CDE or the java environment (or twm?) for their every day stuff? I grant that it may be simply be bad administrators who set up our machines or something else, but the default install set included with many editions of Solaris have been far from conve
  • I recommend phoning you local Sun office and ask for a demo & quote for SunRays. [sun.com] 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).

  • 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 b
  • My suggestion is TEST IT yourself, to help you make your decision on how to do it.
    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 th

  • Don't Do It!!!! (Score:3, Insightful)

    by acvh ( 120205 ) <geek.mscigars@com> on Wednesday May 10, 2006 @06:26AM (#15299703) Homepage
    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.

    • "WIndows thin clients cost MORE than desktop PCs"

      Umm. The ones I bought don't. Admittedly there's still TS licensing to buy, but that costs less than what I saved in hardware. YMMV.
  • 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.
  • When I worked at York (yorku.ca) both Computer Science and Science used labs of X-terminals for teaching. The administration costs were low, and the results were very good.

    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.

  • 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
  • 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.
  • We run ~25 thin clients and 5 PC's. Most people run Outlook, Word, Excel, and iSeries Access (terminal emulation to our AS/400). We are a small office with Windows Server 2003 with 35 Terminal Server License CAL's. Overall positive experience.

    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

  • 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
    • "This is a TRUE thin client, in that the clients don't really run any software."
      Ummm.... No they still really run software.
      Sunrays must have a CPU, probably some flash and some ram.
      They may get updated remotely or even automatically but they still run some kind of software.
  • A hideous number of applications assume you have the whole PC to yourself.

    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 i

  • 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 o
  • 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 (
  • Sorry, looks like most people here either like linux or remember the good ol days.

    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

  • 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 th

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close