Slashdot Mirror


Converting Desktops to Thin Clients?

tfiedler asks: "I manage about 3500 desktop computers and was recently asked by my CIO to begin looking into thin client computing, something like WYSE terminals. I'd like to know, what are some good functional, and more importantly, manageable options to convert existing desktop computers into what would essentially be a Citrix terminal? I was thinking some brand of Linux that starts up an X11 session, starts the Citrix client and connects to our server farm. The user would see a Windows logon, our apps would function as normal and I'd get the benefit of performing a LOT LESS client-side maintenance. Any suggestions?"

8 of 110 comments (clear)

  1. City of Largo by Anonymous Coward · · Score: 2, Interesting

    Dave Richards, sysadmin for the City of Largo, Florida has been documenting some of his work with choosing and setting up thin-clients.

    They have a server for each application (Firefox, OO.org, GNOME, etc) and use HP thin clients (set to be in use for 10 years), and manage to provide a great service, including all the new fancy XGL-like effects.
  2. We use this by phorm · · Score: 5, Interesting

    We use this where I work.

    Essentially we have little sub-1Ghz client boxes with 512MB RAM and no hard drive. They boot off ethernet via PXE, grabbing a kernel and then mounting the root filesystem etc via NFS.

    Newer setups have the client files in a vserver (google util-vserv) which allows for some convenience in seperating the server's components and those for the clients.

    Some apps run locally on the client's processor/RAM, while others are run remotely "ssh -X" with the GUI piped back.

    I'm trying to setup something similar at home, with a server image that should allow friends to connect and use 'nix while at my house (for rounds of frozen bubble, or whatever). You could email me (form on my website) if you want more info.

  3. Really depends on how thin... by Junta · · Score: 2, Interesting

    With the equipment available in this day and age, really thin computing where the desk local equipment does nothing but citrix/rdp/vnc/x forward from a server doing all the work doesn't usually make sense. As you say, doing all that stuff in a centralized way will be suboptimal and latencies annoying. You may be able to get the work done, but do not think for a minute your overall productivity and expense will go as you want them to.

    The other end of the spectrum, everyone installing local applications and keeping most of their useful data offline on their disk all the time is also a nightmare in terms of maintenance and data reliability. You can address these, but at significant pain...

    What I'd advocate is somewher in the middle. Essentially, disposable interchangeable workstations. Networking infrastructures can serve up filesystem access pretty well, and with the right set up, a client system's install can contain no data worth backing up. I.e. my home directory is nfs mounted on my workstation, and my mail and calendar stay on the imap/caldav servers. In my case, the workstation is linux and the company has an apt repo setup with all the important applications. The other day to test whether my setup allowed me to migrate freely, I got a different system, hooked it in, and within an hour I had my full setup on another system.

    I don't have to endure the pain of high latency display nor do I put a huge memory/processing load at a place where the company has a hard time managing it, but at the same time my data does go right to a place they can easily manage and backup. The file access is slower a bit, but the company has a fairly beefy and robust setup that doesn't bother me too much.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  4. Re:No by Demon10000 · · Score: 3, Interesting

    I'm going to call shenanigans on this.

    I'm employed by a company that has approximately 5000 users. A few years ago, we had about 80% Desktops and 20% thin clients. These days, we're about 20% Desktops and 80% thin clients, and both the Technicians and our users couldn't be happier.

    The difference between a Citrix implementation failing, and working successfully is knowing the technology that you're working with. You can't have an application thats going to go rouge and take down your server with 50 users on it -- and that is where most implementations fail. Every application can not be made to work in a thin environment.

    Looking back, I can't imagine supporting all those users on Desktops. We have a 40 server citrix farm and 5 techs to support both the users and the servers. A good implementation goes a LONG way!

  5. Some Warnings, Some Advice and Softricity by SixArmedJesus · · Score: 2, Interesting

    First warning... end users that these terminals are targeted towards typically HATE having to use a terminal like this where the software is served remotely. Unless if you have enough server bandwidth and they are local enough to be able to deliver the needed software at a speed similar to using it locally on a PC, you're going to be doing nothing but frustrating the end users. For people that really need to do the work, they want their software to run as quickly as possible so they can get their job done as quickly as possible. Running it remotely is only going to slow things down.

    Second warning... if you're going to do something like this, PLEASE understand that each person has a different function that may require different software. You have to make sure that each person has the software required to do their job, and to do it well. If they don't have the required software, you have to make it an easy/seamless process to get that software. Nothing makes a job suck more than upgrading the local hardware only to find out that the software one needs to do the job has not been made available and they have to wait while IT figures out how to make it available to you over the coming weeks.

    The company I work for (a major luxury car manufacturer) is trying something like this where we're basically running on dummy terminals, but they never bothered to find out what each of us really needs for our jobs. We've had these new terminals sitting around for months not getting touched because the basic software we need to run the warehouse (yes, I'm on the warehouse side of things) is either not available through that terminal, or once it is, it is EXTREMELY slow. You don't mention whether or not those 3500 PCs are in a single building or location or not. If not, serving software from a remote location is going to be extremely slow, and as I said, it will really frustrate the end users.

    If it were me, here is what I'd do (note: I'm not an IT specialist at all, but I'm an end user with more computing experience than most in my company):

    1) Don't do dummy terminals. Go with real PCs. The users will be much happier in the end if you do.

    2) Do a survey. Survey EVERYONE. Find out what people use. People in a single department are LIKELY to use very similar software. Some may use one or two things more than others, but it will still give you a baseline. It's better to have someone with two extra programs installed that they don't use than have a user that doesn't have the software they require.

    3) Build a series of disk images based on people's needs. These are your backups. If something needs to be seriously fixed or upgraded, do it on the disk image first. Then put it on a test PC. Let them try it. Let them give you feedback and let you know how it works for them. Make sure that everyone that is getting upgraded has a chance to mess with it.

    4) You want do so some storage remotely? Give the users remote storage space, and stress to them that this is to be their primary storage. Save their files there. If possible, save their settings there. If you're going to be doing Windows, if I recall correctly, there is a key that can be changed to make any location the default "Save" location. Make it this remote "drive" or "directory" to help encourage saving to the remote storage. This way when there are software updates and a PC gets re-imaged, their files are safe. Along with this, you have to also make people aware of company policy regarding the software they have available to them and what they can use. Basically boil it down to this: If there's something they need to get your job done that the company hasn't licensed, then they need to work with the company to see about licensing it. Otherwise, each re-imaging is going to wipe it out because it's not sanctioned.

    5) Image the PCs with those disk images according to your surveyed results.

    This way you kinda-sorta have the best of both worlds. The users have software running locally on the PC a

    --

    *slight crashing sound*
  6. Don't Do It by Blackknight · · Score: 2, Interesting

    As other people on here have said, this isn't a good idea. You're going to need to spend money on upgrading your network, buying new terminals when you already have perfectly good PCs, and you're going to need to build a server cluster to ensure that there is no down time. With 3500 users 5 nines isn't good enough, even a few minutes of down time is going to cost you $TEXAS.

    You're much better off setting up some Unattended install scripts and then setting everybody to use a network share for their documents directory, a SAN or NAS would be fine for this. With the proper security settings and group policies you shouldn't be spending that much time on fixing desktops, unless you have a lot of hardware failures.

    You also don't want to introduce a single point of failure, which is what running everything off a central server would do.

  7. Windows is a single point of failure by pogson · · Score: 3, Interesting
    I worked at a place one year where MSFT decided to override our settings to "upgrade" to SP2 and our whole system needed reinstallation. We did not have enough storage to back up every client so I had to go through the whole system customizing clients. It made my day. In systems I design there will be no Windows.

    The last system I designed had 130 seats as Linux thin clients and I could tweak the whole system without leaving my chair in seconds. I had redundant servers ($1500 each) instead of redundant clients and it took only minutes a day to verify that everything was OK and it was for months. Not one incident of malware disrupting anything. The users migrated from needing a full time geek to re-install that other OS several times each year on each client to having machines as reliable as telephones.

    --
    A problem is an opportunity http://mrpogson.com
  8. We're actually doing it now... by ErichTheRed · · Score: 2, Interesting
    I can't say where we're doing this, but we're trying out the idea of thin clients for some of our desktop positions. We found that we can get lots of quick wins for the positions that are mostly dumb terminals anyway. As long as the emulation software runs properly in Citrix, users don't know the difference. We're a Windows shop, so we went with Citrix. Native terminal services just doesn't have enough features.

    Here's what we've found so far:
    • Desktop support guys are not going to like this until you explain it to them. They're going to feel that you're taking their jobs away. Unless you give them better career choices to move into, they'll be very unhappy.
    • Your desktop environment will become a mainframe-like environment overnight. App changes now affect thousands of users at once. You need to have testing, integration and all that stuff dialed in before you even think about moving people to Citrix. If you're still doing "one-off" desktop support and don't have a well-managed environment, you may run into trouble.
    • All of your apps must at least support being run in terminal services mode. Manually tweaking all those in-house apps to store their settings correctly is a huge pain.
    • Citrix can be expensive, and once you're on it you will never get off. Remember, once you replace PCs, you now have a machine on everyone's desk that is useless without the back-end environment.
    • Don't skimp on the server hardware. Max out everything; you're going to need it.
    • We're forced to use IE because of ActiveX dependencies in our core applications. IE takes up almost 30 MB of RAM, per window, per user just sitting idle. If you can, you might want to consider limiting the number of open IE windows to one.

    We're actually doing pretty well with this, but don't forget that some positions in the enterprise just can't function without full-blown PCs. Hosting things like engineering or CAD apps is not worth the effort.