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?"

Comments

sun ray's!

[Nova1313]

Check out sunrays. They are dirt cheap and they now have a windows version of the software. I use them at home they are really that easy to setup. We run a windows and a linux sunray server here. 2 Servers that I upgrade every 2 years and then we have about 10 terminals scattered throughout the house. I'm on one right now actually. It's a simple solution and fairly cheap to deploy.

Re:sun ray's!

[apachetoolbox]

I just got done reading the Sun Ray 2 Virtual Display Client FAQ and it didn't even mention what protocols it uses. Can you use this to connect to a regular old windows terminal (RDP) server? Doesn't look like it to me.

Re:sun ray's!

[apachetoolbox]

After a minute or two of googling I think the Wyse S10 are a better choice. They connect to RDP servers and only cost about $280.

Re:sun ray's!

[dorath]

Sun Ray Clients.

Re:sun ray's!

[Nova1313]

no they don't connect to a terminal server. They use a propriatary protocol. You instead run sun's sunray server and then you get sound, usb devices, dual head support and access card use. I login to the main box and terminal server to anywhere else I need to go. I bought 2 of the sunrays brand new and the other 8 off ebay for like 20 bucks a pop. The brand new sunrays are the sunray 2's with dual head support. We originally used them where I went to school for my bachelors and I got into playing with them at the time. But they make it super easy to administer my entire house with them.

Re:sun ray's!

[networkBoy]

Based on your experience how would these work in a cyber cafe setting?
I like the smart card aspect. I assume they are configurable thus admin cards, vs. prepaid user cards? I know these wouldn't be useful for games, but I'm thinking a two tiered pricing? $24/hr for a gaming machine (or bring your own for lan parties) or $12/hr for a thin client. Think they'd do good enough for e-mail, IM, etc? Loving the statelessness for native AV properties...

Likely be useful for the register terminal as well (third class of card perhaps?)
-nB

Re:sun ray's!

[Nova1313]

from my experience I've had 10 users on my home system and it's a crappy dual core server with 2 gigs of ram. It runs ubuntu and everyone on the network was running enlightenment. You can browse, edit, compile all at once without a problem. Graphics intensive stuff such as anything 3d and they started to chug. Flash works well though. Btw thats kinda expensive I know the cafe's by me you can get a gaming machine for 5 bucks an hour with all their games installed. As for the smart cards I've not played around with them too much. I gave one to each family member. Basically I login with the smart card in open some stuff and when I would normally log out I just pull the card out. Now I go to any other sunray in the house and plug it in. You get everything you had open on the previous desktop back. The only exception is it doesn't seem to persist sessions through a server reboot.

Re:sun ray's!

[Kadin2048]

That's a big price bump, though. Sun Ray I's are selling on eBay for $60 + $20 shipping (and that was Buy It Now, I suspect they even go for less via actual auctions). For one or two units, it might be easy enough to justify the difference, but if you were outfitting a lab or cafe, a 3x price difference upfront could be a no-go.

my suggestion

[Anonymous Coward]

I'd suggest some brand of Linux that fires up an X11 session on boot, with a boot script that starts the Citrux client and does whatever you need it to...

Not sure that's the way to go

[countach]

Even 20 years ago, we were using rdist on Solaris (or is it rsync?) to totally automate updating of clients, and then we were NFS mounting the home directories, so that they are on the server and backed up. So you get most of the benefits of local computing with local CPU etc, and the benefits of no client maintenance because it's all automated and the home directories are backed up. Why does Windows make it so hard?

Re:Not sure that's the way to go

[Anonymous Coward]

Most of this can be all automated on windows too. There's countless apps to do this, like WSUS (free, from MS) for Windows patches. Apps can be pushed via GPO, SMS, login scripts or whatever you want (almost too many possibilities here). Mounting home directories and all that has been totally transparent for a while (been doing that since the NT4 days at least).

We hardly have any local maintenance either - it's mostly people that need help to do something with their office suite, or have deleted emails they shouldn't have (then we show them the "recover deleted" option), or when RAM or a PSU goes bad or such (quick swap with another box, a few minutes and they're back in business).

Thin clients often means proprietary and not so cheap clients (compared to the ubiquitous and versatile 500$ x86 box), and extremely expensive apps like Citrix Metaframe, and monster servers that cost more than you could imagine. We've looked at it a few times, and it would have cost a LOT more than cheap Dells! We do have one terminal server for a couple special apps, but for day to day stuff, it just didn't make sense.

Anyhow. I don't see how "Windows makes this hard" for any half decent/qualified admin (i.e. at least knows about Active Directory). Our PCs-per-IT-guy ratio is quite high, and they've still got time to waste...

Thin clients are extremely overhyped.

Re:Not sure that's the way to go

[Greventls]

I agree with the parent. I have limited IT experience, but from what I can thin clients would only really work if you only had a couple base images. But even in the different departments, random people have Visio, Project, Adobe, etc. I don't know how you limit the users for that with a thin client. It doesn't seem like a practical solution unless everything is web based or everyone runs the same stuff.

Re:Not sure that's the way to go

[headkick]

I just finished setting up a Citrix server that addressed just that. Based on group membership, we can restrict what executable you launch with file security, i.e. you have to be a member of the Office Professional group in order to run Power Point or Publisher. With a simple login script, we add the desktop and start menu shortcuts to apps that they have permissions to run, and remove them if they don't have permissions. For the client side, we are using Thinstation to PXE boot the diskless clients and automatically launch a Citrix desktop session.

City of Largo

[Anonymous Coward]

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.

Linux terminal servers

[vinsci]

You're may be looking for the Linux Terminal Server Project.

PXE boot with Thinstation

[smbarbour]

If the desktop computers have network adapters that support booting from the network, you can use PXE to turn the machine into a thin-client.

There is an excellent free utility for setting up the boot image to load from a TFTP server called ThinStation

We have a remote office where I work where everyone connects to a Win2K3 server with Terminal Services. I suggested PXE as a method of connecting rather than having a full-blown copy of Win2K installed just to run the TS client on boot. It worked great but as yet, has not been adopted.

Re:PXE boot with Thinstation

[MikeB0Lton]

Tell me have you ever PXE booted 3500 desktop computers on your network before? Maybe this works in a datacenter on a secondary network, but not on the main client network.

Re:PXE boot with Thinstation

[Curien]

Yes. You do realize you can have multiple TFTP servers, right?

Re:PXE boot with Thinstation

[lukas84]

If these 3500 clients are on the same ethernet segment, you have other problems anyway.

No

[Greyfox]

Thin computing is a buzzword companies throw around when the balance sheet is drifting into the red and the CEO doesn't want to give up the corporate jet. Ultimately the latencies are unacceptable, network outages paralize your entire company, and unless you're doing a lot of stuff that does't require computers in the first place the entire effort will not only fail, it will fail miserably. Look at ANY company that has attempted to deploy graphical thin clients and you will find nothing but failure. The guys at Sun will try to tell you that they have thin clients and it works great but this is not true. All the guys who do real work at the company have either laptops or SunFire machines on their desks.

Here's a suggestion straight from the BOFH that might work though; Spin off a company to test the citrix rollout. After a couple of weeks of using citrix anyone who finds it acceptable gets moved to the new company. Then mismanage the new company into bankruptcy. You'll have gotten rid of most of the deadwood at your company and the citrix rollout will die the ignomious death it so richly deserves.

Re:No

[Anonymous Coward]

because all thin client solutions revolve around citrix.

Re:No

[compupc1]

My company decided to do that, but only for certain people who didn't need the computing power. Developers and graphic artists and people who did stuff like that kept their desktop PCs. I think we used some sort of blade servers, but I don't recall the brand. However, I do know that nearly everyone I've talked to who used them just hated them...there reports of unacceptable latencies, the inability to work when there was a network glitch, etc.

Re:No

[Sea Monkey]

We successful used Sunrays with no issues for 2.5 years doing hardware design. I don't buy your argument. Other than that Citrix sucks.

Re:No

[Rich0]

I dunno. No question that thin clients aren't going to work well for laptops and other offline scenarios. However, in many global companies a huge number of enterprise apps are moving in the direction of Citrix anyway - so they already need to maintain an airtight network or they're out of commission.

Why are they moving to Citrix? Simple - most client-server apps don't handle high latencies like you find in a WAN. All those database round-trips kill performance when you have 250ms latency. The only solutions are to move the front-end closer to the database, or the database closer to the front-end (or rewrite the front-end, which is hard to do when you don't have the source). Moving databases means all kinds of replication issues.

I actually consider the idea of thin-client computing fairly tempting. If I didn't have very-low-cost PC hardware available at home (hand-me-downs) I'd probably use thin-clients around the house for most of our systems...

Re:No

[Greyfox]

Sun's solution uses X11. Same difference.

Re:No

[blincoln]

Simple - most client-server apps don't handle high latencies like you find in a WAN. All those database round-trips kill performance when you have 250ms latency.

I would argue that that's only true if qualified as "most poorly-written client-server apps". There is a plague of "enterprise" software vendors out there who can't be bothered to develop decent software and use Citrix or terminal services in general as a magic bullet to make up for their incompetent application design. I am looking at you, Merant or whatever you're calling yourselves these days. I am looking at the companies that sell "database" "applications" which are really just complicated Excel macros.

You know what the solution is? It's not thin clients or some other buzzword. It's for big corporations to stop buying shitty software. Microsoft gets a bad rap sometimes, but they are a billion times better than "enterprise" software companies that don't make or sell consumer products, but leech exclusively off of large businesses.

Re:No

[Demon10000]

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!

Re:No

[Anonymous Coward]

"Ultimately the latencies are unacceptable, network outages paralize your entire company, "

We're already paralyzed when we have a network outage. Even the laptops become expensive bricks without a connection of some kind.

Don't take my word for it. Do the math. How many apps at your work need a network? I'll give you a starter list.

any corporate database
email
time sheets
booking travel
instant messaging
phones (got VOIP?)
payroll
every other accounting function
CRM
everything you do collaboratively
file sharing (no, not that kind, your network drives)
getting technical info
patches
AV updates

I hear people say, "if the network goes down, at least you can limp along if you have a local computer." Sure. You'll be limping like that knight in "The Holy Grail" who only had a "flesh wound." Using the network down issue as a reason not to go thin is idiotic. If your network goes down, you're screwed in either case.

Re:No

[Rich0]

I would argue that that's only true if qualified as "most poorly-written client-server apps".

I would argue that "most poorly-written client-server apps" == "most client-server apps", so I both agree and disagree with you... :)

You know what the solution is? It's not thin clients or some other buzzword. It's for big corporations to stop buying shitty software.

Go ahead and start writing it and I'm sure we'll all flock to buy it. :)

Microsoft gets a bad rap sometimes, but they are a billion times better than "enterprise" software companies that don't make or sell consumer products, but leech exclusively off of large businesses.

Alas, MS doesn't sell anything that does the stuff our Citrix-based apps do - which is very industry-specific. In any industry you'll find a number of VERY-CRITICAL enterprise-scale apps that are specific to that industry. They sell at most hundreds of licenses per year, with costs in the 6-7 figures easily per large customer. I don't really call this leaching - I'd call it meeting a market need. I'd be the first to argue for an open-source solution/etc, but there aren't any out there now. Whenever a more agile vendor comes along I'm the first to argue for a migration when it makes sense. Things have progressed by leaps and bounds, but in general this software tends to lag about 5-10 years behind mainstream consumer software. Just look at how much software still runs on VMS, CICS, etc.

The problem with this sort of software is that features matter more than backend performance, customers are more interested in whether it works than whether it can be sold in volume, it will never sell in volume anyway, and it requires all kinds of industry-specific knowledge to make the software in the first place. That means high price tags for the software. If you're paying a million dollars for a software license, would you rather get more features that make it work the way you want it to, or ask for a total redesign that will probably introduce bugs and only save you maybe $10-20k on server costs. When hardware is a one-time expense sometimes it makes sense to just throw money at hardware. Not a good solution for consumer software, but it is often a good tradeoff for industry-specific software.

Re:No

[Kadin2048]

Mod parent up. A while ago, I was at work when The Network Went Out. It really drove home how useless we all were without data service. People stood around at their desks, rebooted, etc., for the first five minutes, and then proceeded to take coffee breaks / mill around the water cooler / shuffle dead-tree papers. Eventually, people went out to lunch. When it became evident that things weren't coming up again soon, everyone just packed up and went home.

Without the network, everything just stopped. No email, no file sharing, no printing ... heck, you couldn't even use the photocopiers, because they require logins and authenticate against a single-sign-on server. Everything just stopped. The only difference between it and a power+generator outage was that the lights and the microwave still worked, but lights and a microwave make a 7-Eleven, not an IT company.

I never did hear what caused the network outage. I can only assume that someone was fired, or perhaps impaled, for it, though.

Re:No

[pnutjam]

I beg to differ with you. I work for a Mental Health company with about 250 employees. We have one site with about 100 users, 5 sites w/ 20+/- users, and over a dozen sites with less then 3 users. We have a three person IT department.

There is no way this would work without thin client. Most of our locations use either a direct T1 or residential internet service w/ an IPsec VPN. Some of our sites need computers to handle a dynamic VPN. These sites are way more trouble then the sites with thin client terminals. Our machines are configured to be easily switched out with no data stored locally, but administering windows locally is still a pain.

I have tried linux as the thin client OS, but VPNC only runs under root, I've managed to get it to connect w/ scripts and sudo, but it's unstable.

We use this

[phorm]

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.

Citrix

[celardore]

My old employer decided to update from 486s to thin client, this was a few years ago. I remember there being some serious problems initially. They ran a Windows 2000 server which the thin clients would connect to, but one day they got a worm... This rendered every single PC unusable, we couldn't type letters, work on spreadsheets etc. We couldn't even access the accounts, which is very bad for a finance department answering calls from customers.

It was fixed, but the downtime was costly, we could only really do filing. If your server goes down, then everybody is screwed. If everyone has standalone machines at least they can still do basic tasks.

Re:Citrix

[alienw]

It's a lot easier and faster to repair one server than it is to reformat and clear a few thousand client machines. You think you would have done much if all of the client machines got infected with a worm?

Re:Citrix

[pasamio]

I rmeember trying this onea few years ago. Someone opened a worm infected email 10 minutes before the scheduled antivirus update at 9am. It only took that ten minutes to take down the entire head office of the organisation with thousands of desktops infected. Funnily enough in some places Linux boxes were used as routers on some gigabit networks. One of the techs told me afterwards that it was laggy connecting to the computers because the gigabit links were full of this worm attacking the entire network. My mates got home at 9pm that day after disinfecting the entire network. So yes, whilst in client-server if the server goes down you can't work, but its still easy to fix one server than thousands of desktops. Plus the one (or more) servers are typically in one location physically, which makes things that require physically rebooting the machine easier (keeping in mind that your network is now shot with computers trying to infect each other and the rest of the internet).

Try pxes

[sfire]

Try PXES. I used it at a high school to netboot old desktops ( I think I used etherboot, with all nics embedded, so it didn't matter what nic was in the desktop), to download pxes, which would then connect to the X11 box to run all the applications. It features RDP, X11, NX, and others perhaps.Download here.

Re:Try pxes

[brent_linux]

A smarter way to do it if you are going to run PXES is to just put RDP or Citrix support in your TFTP image and connect straight through. There is no reason to connect X11 to a machine and then RDP to a windows machine. That is a common mistake people make when setting this up.

We use PXES .9 I think (not the X2 version) and it works great. I can't comment on X2 as I have never used it, but I setup .8 about 3 years ago and upgraded it to .9 whenever it came out. I haven't touched it since. We just add new terminals to it with Etherboot .com's on small hard drives and walk away. No external drives for the students to tear up and it is tougher for them to mess up the server than it is a local machine.

Really depends on how thin...

[Junta]

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.

Concur fullheartedly

[Junta]

Disposable clients not thin clients are the answer for manageability. The cost savings of opting for a truly non-capable display-only device over a competent computer is essentially non-existent. Trying to pack all your processing overhead and memory into a centralized place will more than offset any perceived client-side savings. If you plan for it and can use the right tools, you should be able to go from an unconfigured blank system to a fully functional system with access to any arbitrary users data in under an hour. If you want to cut down workstation outages, you could do diskless with more RAM to have ramroot (if your OS allows), or switch to solid state storage. Fans of course will remain an item to service, but should be exceptionally painless to swap out that.

Re:Concur fullheartedly

[pogson]

I disagree strongly with this statement:"The cost savings of opting for a truly non-capable display-only device over a competent computer is essentially non-existent."

With Windows it is true, because Bill charges per-seat. With Linux you get about 66% discount per seat. The cheap thin client box may cost only $150 USD. You pay Bill more than that in licences.

I recently equipped a whole school with thin clients in every room and we got twices as many seats as we could have afforded with that other OS and the cost of maintaining the thin client is almost zero. Over ten years, they will save their own cost in power savings, so they cost almost nothing. On the other hand, a thick client costs over and over again and is a burden rather than a blessing. There are a few things a thick client can do that a thin client cannot, but that can be worked around: go thick for the few individuals who need thick. Why pay big bucks to have thick clients idling all over the building? Pay big bucks for servers working hard.

Options?!

[uradu]

Basically you're talking about running tsclient on some Linux distro. Since you don't care about local capabilities, pick the lightest and fastest booting distro using the lightest window manager, or no window manager at all. Tsclient will run in full screen mode, so on a LAN it will feel pretty much like Windows.

Awkwardness will set in at the intersection of the remote world and local resources: while local storage (e.g. USB flash drives to take out/bring in data) may not be a big issue, printers sooner or later end up being a real PITA. Networked printers can work well enough (even though you tend to see all the company printers available, which in a larger installation can be A LOT), but local printers can be a pain and get you back into the customized client situation. It gets even worse with other peripherals like scanners, which can lead to a lot of compatibility issues with remote software trying to access a local scanner.

I have kind of the inverse problem?

[hurfy]

Our problem here is that our main accounting app is on a unix box and we use a terminal emulator to access. However our vendors have the purchasing info/programs on the web, and pretty sure AT LEAST one requires IE. Thus we need windows underneath. It was pretty disturbing to realize we need a Hyperthreading Pentium 4 or better to efficiantly emulate a DUMB terminal under windows or the firewall/AV chokes the response rate too much :(

We use a web browser, a DOS billing program(that requires Windows installer to load!!...i was gonna build a DOS network with old computers for this part since they are isolated and the program came from a 386-25, damnit), a simple windows billing program and some basic Word and Excel stuff, nothing that requires more than a P3...except for the security software :/

Nothing like finding out a Dumb terminal emulator is a dog on a 1.6gHz box, shesh :(

Anyway, sorry for so offtrack thats been bugging me to no end ;)
Everything i thought of always had at least one good gotcha in it, best of luck. Watch out for what will trip you up several steps ahead.

Never did come up with a better plan than faster boxes....anyone need a pentium 3 ?

Re:I have kind of the inverse problem?

[shawngarringer]

We use a web browser, a DOS billing program(that requires Windows installer to load!!...i was gonna build a DOS network with old computers for this part since they are isolated and the program came from a 386-25, damnit)

Nothing like setting up a network of (probably) outdated crap, on an OS thats not supported and that virtually none of the entry level desktop techs that your company would be hiring can support... sounds like its gotten "success story" written all over it.

Nothing like finding out a Dumb terminal emulator is a dog on a 1.6gHz box, shesh :(

I also call BS on this one. We have many Dell GX1s (P3 500-800MHz) working on production lines running 4 sessions of either QWS3270 or IBM PC3270 with McAfee 8.0i running and the machines aren't slow. If you can't get a terminal emulator to work on anything besides a P4 your either using some (nameless, crappy and free) Virus scanner or don't know how to set up Windows. And judging from your desire to setup a network running on DOS, I'd assume its both.

Re:I have kind of the inverse problem?

[tomhudson]

"However our vendors have the purchasing info/programs on the web, and pretty sure AT LEAST one requires IE. Thus we need windows underneath."

You no longer need Windows to run Internet Explorer - it runs fine under linux .

What is IEs4Linux?

IEs4Linux is the simpler way to have Microsoft Internet Explorer running on Linux (or any OS running Wine).

No clicks needed. No boring setup processes. No Wine complications. Just one easy script and you'll get three IE versions to test your Sites. And it's free and open source.

Who is the target public?

• WebDesigners that want to move to Linux but still need to test their sites on IE.
• People who have to open IE-only sites

The IEs installations are smaller than usual because they include only the necessary files to have a good test browser (there is no Outlook, Media Player etc).

It really works. Complete with all the IE-specific javascript/dom/css bugs.

Re:I have kind of the inverse problem?

[Anonymous Coward]

Everything i thought of always had at least one good gotcha in it

How about this one: quit, and then it's someone else's problem.

Re:I have kind of the inverse problem?

[Scoth]

My company runs an ActiveX IE Only ickified CRM (Siebel 7.7 thin client). I've spent quite a bit of time experimenting with ies4linux, Crossover, winetools, and a couple other IE in Linux setups. It mostly works - probably 90-95% of it. But that last 5-10% is the problem. It tends to randomly freeze up, crash, or otherwise malfunction. And, unfortunately, without 100% compatibility, there's no hope of ever having Linux replace Windows for good. It's a shame too, I've gotten a couple other apps we use to work in wine or natively; it's pretty much the only thing holding me back. And it's a biggie, sadly.

Re:I have kind of the inverse problem?

[the_womble]

And let that be a warning to anyone considering buying anything that only works on one platform.

Organisations that would never even consider allowing themselves to be locked into a single vendor for anything else, happily do so with IT.

You don't need to convert anything

[Anonymous Coward]

If you are moving over to Citrix, there is no need to 'convert' anything. Just load the appropriate OS client [windows 95/98/NT/2000/XP/linux/mac] and be done with it. Or even simpler, just load your favorite browser on the machine, and use the built in java client that comes with Citrix. There's nothing to load. Now, for simplicity sake, remove all the old apps off the workstations when you have time, and have the Citrix Program Neighborhood load upon bootup, and you are ready to go.

If you are looking to switch to thin clients devices, the Wyse setup is very smooth, but if you want dirt cheap, go ahead and look at places like NeoWare.

But, you don't need to throw away any of the current machines in place, just load the client and go home happy.

Boot from SAN

[statemachine]

Admittedly, this is the higher-end solution, but since you have 3500 desktops, I don't think it's unreasonable to think you already have or can get the infrastructure.

Using iSCSI or fibre channel, configure the NIC or HBA to boot from a pre-assigned lun. All of your backup worries vanish, because you are already backing up your storage arrays, and there's no local disk to fail. At the very least, there's disk redundancy.

Taking it even further, make all these desktops 1Us in a data center and use an Avocent system (or similar) for a KVM console at the user's desk. Now you have the best of both worlds: a computer dedicated to your user, but physically untouchable; and centralized backup, control, and troubleshooting for the admin.

Re:Boot from SAN

[Anonymous Coward]

Why would your backup needs vanish? My understanding, which could easily be incorrect, is that iSCSI doesn't allow you to share the raw device -- it just allows you to keep all the raw devices in one central location. After all, iSCSI is just like scsi or firewire -- I could plug 2 computers into one disk but the two computers can't share one common lun / partition without extra special care to avoid corruption. Or, are you saying you'd just block-level dumps of each lun? Those sorts of backups don't seem like they'd be all that useful. More useful than a sharp stick in the eye, but nothing like a real file by file backup.

Or am I wrong?

Re:Boot from SAN

[statemachine]

All of your backup *worries* vanish, I said. If you have a storage array, you're likely already backing up all of the LUNs to tape.

With iSCSI or FC you can always mount the LUN read-only, whether clone or not. File-by-file backups only work when the file isn't open read/write anyway -- so I think you'd have the same problem with data integrity at that point.

But my main point is that this can all be off-loaded somewhere else, and doesn't need to be on the user's desktop.

One Crash can bring down the hole system

[Joe The Dragon]

Look at the Crashing an In-Flight Entertainment System story that seem like it is run on some kind of thin client system.

VDI

[Natales]

Actually, what you describe seems to be gaining a lot of popularity lately. CIOs already got the picture that managing PC endpoints is a nightmare, so I guess it makes sense to put them back in the datacenter, either by using physical PC Blades (still expensive), or a shared solution (such as Citrix or X-based desktop sessions).

The latest move, and the one I really like, is using virtual machines hosted in the datacenter. In that way, you can have a single VMware ESX server for example with let's say 40-60 desktop VMs running, each one of them with their own single-session ICA or RDP connection (for Windows) or X, NX, Go-Global, VNC, or whatever else you want to use, traditionally using a front-end connection broker (Citrix, Propero, Wyse, etc).

This approach is called VDI or Virtual Desktop Initiative, and it can leverage Wyse terminals, LTSP, Sun Rays, old PCs, you name it. The point is that the VM is yours. You can do whatever you want with it and that can't affect other users like a shared session would. You don't need to deal with application-level conflicts either, as each VM is completely independent from each other.

I've seen this solution installed in several large organizations with off-shore development teams, where the VMs are hosted in the US while the remote users just establish sessions against it.

Disclaimer: I work for VMware.

Re:VDI

[Anonymous Coward]

Wow that is exactly what I'm trying to do - see my comment (starts off with 'k12ltsp') below. Wrote it before reading this one. VMware is some slick stuff. Hope you get paid a lot and the company stays profitable and cool ;-)

Re:VDI

[Locutus]

atleast this setup will make it easier for the BSA to audit your software since they won't have to walk around the building to each PC for the audit. Other than that, I don't see how this is a cheaper way to manage the system since you end up with all unique installations of both OS and applications in every VM. And with a VM for each desktop, that's alot of licenses, disk space, and dare I say, MS Windows registry settings.

Now I've seen this work small scale, 5 VMs, but 40-60 would probably still be tough to manage. Probably better off with a terminal server setup of some sort.

LoB

Convert to thin, eh?

[mkoko]

I would suggest a hacksaw, a dremel, and some duct tape. Those should be able to make any desktop thinner.

I am intrigued....

[Anonymous Coward]

I am intrigued by this 'hole system' of which you speak...and I would like to subscribe to your newsletter.

Call your local citrix partner

[batkiwi]

What you're asking for is what the citrix-loaded WYSE terminals do automatically. You choose which model terminal (and which OS, they have both linux and windows based ones) and then set the level of local access (allow local apps, allow local USB drives, allow local streaming media, etc).

You then set up your citrix farm and away it goes. You can either have a full session, so that the user thinks they're using windows on a workstation, or you can have each app running 1 by 1 as the user launches them from the terminal.

Last I checked the terminals were about $200 each if you go with the linux ones since you skip having a windows license for the local box.

Re:Call your local citrix partner

[Braedley]

I wouldn't go with the full session, as you're going to need the same amount of memory as you would for a local OS (if not more). Piping back and forth between the server and client diminishes the user experience when the local memory starts to fill up. You can avoid this with a local hard drive, but if you're going to put a hard drive in anyways, why not include the local OS? Piping the apps individually is a good idea (and is what is done at my university), and can allow for a huge number of apps without taking up client hard drive space. However there are some apps that probably shouldn't be piped, namely internet browsers and text editors, partly because they are small and because you don't want your workstations completely dead when the server goes down.

HD ray's!

[Anonymous Coward]

Now all we need is the HDTV version.

MIcrosoft are working on this.

[The Dodger]

Their biggest customers (i.e the Fortune 500 companies) are sick and tired of the cost of supporting locally-installed operating systems that they've put serious pressure on Microsoft to come up with a solution. In the not-too-distant future, there will be an "enterprise" version of Windows, where nothing is installed locally. Basically, you'll be able to sit down at any PC on your company's network, log in and your "profile" will be downloaded to the PC you're sat in front of - not just your desktop preferences and IE shortcuts - all the software you regularly use will be "installed" and ready to use.

D.

Re:MIcrosoft are working on this.

[unDees]

Wow, just like the old Sun workstations at school. The more things change....

Re:MIcrosoft are working on this.

[pogson]

Yes, XP/2003 does this kind of thing. A power user like me with gigabytes of files does not enjoy moving around in such a system. Synchronizing ...

Give me LTSP or even a remote X session any day. My files stay on the server. Only pictures of their contents and my desktop follow me around. Makes a lot more sense.

Moore's law increases the power you can put in boxes in the server room so rapidly that you do not even have to increase the size of the server room. Just keep upgrading the servers. A few years ago we jumped to AMD64. Computing MFLOPS did not increase much but throughput sure did. Now we have higher clock speeds and multicore chips. Server-centric computing just makes sense. There is no need to upgrade the thin clients for many years and yet we can constantly redouble our computing power in the server room. So what if we have to water cool them? I like to keep all that noise and heat away from my desk.

Desk top Boxes and old Cirix CLients

[problemchild]

I've been looking at some Mini ITX based Set top boxes been sold for £40 in odds and sods. Failing that you can get a very good solution using old Citrix Clients thrown out or sold for bugger all on Ebay. Neglecting the monitor my last Semperon 3000+ box was £80 all up with out the HDD. Basically the choices are legion.

Re:Desk top Boxes and old Cirix CLients

[Anonymous Coward]

Please speak either American English or Slashdot (not Birmingham) Slang --and always, always use US dollars (for those of us who can't multiply by 2) /ducks

Options

[Anonymous Coward]

Thin clients are supposed to lessen the management of PCs. All apps would reside on a central location and depending on your implementation, either run on a beefy central server or on local machines. The problem with the former is that you have a very expensive central server that's usually completely inadequate for desktop applications. Now this may work for the subset of users that don't need the traditional desktop tools. But in this case it would likely be cheaper to web-enable those critical apps or look at some of the web application suites (I think Google just released one).

The problem with the latter (run on local machines) is that this is taking a PC and crippling its functionality. If your users' PCs are just glorified terminals then this is easy. If not you'll get all the cost of a PC and little of its benefits.

If your boss insists on thin clients there are a few things you can try:

1) Set up a fairly powerful server with vncserver instances with locked configurations.
2) If you're trying to reduce PC maintenance, try running applications from a central server. This works for almost 6 different applications that don't require local registry settings.
3) Take the PCs and throttle down the speed to 800MhZ to simulate running apps remotely. To be fair, only some apps will slowdown. These apps include those that require graphical output or user interaction.
4) Replace your network. RFB is chatty and puts a tremendous load on your network. Simulate it by running all NICs at 10Mbit/half.

PXE boot with Multicast.

[Anonymous Coward]

One of these days someone will invent a technology that allows the efficient distribution of one to many.

Why not?

[Anonymous Coward]

I'm not in IT, but why not use thin computing, and keep a rack of backup laptops for network downs? Have all user data backed up to a dedicated external hard drive with upload, but not delete privledges given to the thin computing server. The external hard drive server could do routine clean up of the external hard drive weekly by deleting files that were deleted on the thin server a month or more ago. Then, when the thin server has problems, copy the user data over to the laptops and hand them out for the duration of the system down time. Once the network is back up, and the new work from the laptops has been safely transfered back to the thin server, system restore the laptops, and you're back to normal.

commodity hardware is cheaper.

[Anonymous Coward]

You say thin client, I say Asus C3 Terminator w/ just a stick of RAM and a memory stick (if only there where cheap compact flash to IDE adapters). It's only $80 on newegg.

If you need IE, might I recommend IEs4Linux. Run IE in linux without the hassle!

WAN or LAN?

[Steinfiend]

You don't specify in your question if all 3500 current PCs are local or distributed. As someone who currently supports multiple remote locations, furthest being about 3000 miles from our main data center, I would say this is a VERY important distinction. We use Windows Terminal Services hosted on multiple Windows 2003 servers to give access to some fairly basic but unique CRM functionality. We have more than enough horse-power for each user, and my local users love it. However, remote users who have high-speed, high cost WAN connections, with pings between 8ms and 90ms, hate it.

Even with a ping time like that, it can get frustrating. A slight lag in a mouse movement or key stroke can have a huge effect on productivity. Even a slight drop in the connection, which seems to be happening WAAAY to frequently for the price we pay for our T's (damn Global Crossing...), destroys productivity. Of course, if the WAN connection goes down for any length of time, an entire office of people has zero productivity. We have back up connections, but usually if someone chops the fiber that supplies the T, the DSL goes down as well.

It's wonderful to be able to buy cheap hardware, and know it's going to run everything I need. It's wonderful being able to install an application once and know all my users have it. It's wonderful to update one config file, and know all my users have the new setting. However, it's horrible to get phone calls 24/7, from frustrated users because a thunderstorm in Texas is bouncing a WAN connection. I would think seriously before making a move like this, be sure the saving in time, energy and money supporting and running thin clients, make up for the increased user frustration and potential loss of productivity.

Re:WAN or LAN?

[norkakn]

Why don't you go to fibre? (disclaimer: I'm not the netadmin and I may be full of shit) I think we just negotiated with Time Warner Telecom for 25Mb at about $1000 a month. Prices have gone down a lot, maybe you can get a better deal?

Re:WAN or LAN?

[Anonymous Coward]

Or local servers for the WAN users.
Not possible with RoadWarriors, but they should have fat clients.

Re:WAN or LAN?

[Anonymous Coward]

I thought that's what WAN optimizers or application accelerators are for. They're supposed to cache a great deal of what goes between the offices, reducing latency and making more effective use of bandwidth. You may even be able to downgrade some of your expensive WAN connections to highly reliable varieties of DSL.

Of course, they're pretty much just standard computers with proprietary software, locking you into a single vendor with $thousands per office costs, but what can you do?

Maybe with bad design...

[meosborne]

I have planned and deployed thin clients across local and wide area networks and all have been successful. While the situations you describe can happen, they can be easily avoided with proper planning.

Citrix is a last resort

[Anonymous Coward]

Citrix's main (and some would argue only) benefit is the ability to minimize the hassle of dealing with poorly written, bloated "enterprise" software.

I work for a company that just rolled out a new piece of software to 9000 workstations . The software was well over a gigabyte in hard disk space, required us to upgrade almost half our workstations, needs to be patched at least twice a month, and has serious issues with anything but a pristine network connection to the database (they require less than 40 ms latency and the software refuses to run on a wireless connection). We're looking at using Citrix JUST to handle this software. The downside is: Citrix is incredibly expensive. Last I heard, Citrix client licenses were somewhere in the neighborhood for 450 bucks a seat, in addition to TS cals, server licensing, and windows licensing. We ran a pilot Citrix farm with our nameless software and got 25 users per server. Each server had 4 gigs of memory and a pair of new dual core Xeons and cost about 6000 dollars apiece. If you're running reasonably well written software, Citrix isn't worth it.

Thinstation: Cytrix, RDP, NX, X, SSH, more

[davidwr]

ThinStation is a Linux-based very thin client that does little more than set up a remote terminal connection. It boots off CD, Network, or even a HD if you like. You can store config info on a floppy or network if you want.

From the web page: Thinstation is a thin client Linux distribution that makes a PC a full-featured thin client supporting all major connectivity protocols: Citrix ICA, NoMachine NX, 2X ThinClient, MS Windows terminal services (RDP), Cendio ThinLinc, Tarantella, X, telnet, tn5250, VMS term and SSH.

Using the CD-boot option it's a great way to recycle old PCs today, without waiting for a PXE server to be set up. Just make sure all your network cards and video cards are supported.

Larry, is that you?

[raftpeople]

Always selling!

Re:Larry, is that you?

[Nova1313]

haha no im just a recent grad who happened to go to a school (moravian.edu) which features a 98ish percent sun lab. Of which about 30 of the systems were sunrays. I was a big fan of the idea and we had entire classes pounding away on them. They do just fine for my home work. If you have people running cpu intensive applications all day I'm not so sure.. Most people in my house email and web browse and use open office. It works fine for that. So no I'm not Larry ^^

Why? Why would you do this?!?

[X-treme-LLama]

No! NO NO NO NO NO!!!

It's going to cost nearly as much money to deploy this, perhaps a lot more (factor in server cost, and perhaps some network upgrades, along with the client itself). Your workforce will be terribly unhappy (latency, inability to use a REAL bloody computer), your support staff will have just as much to do trying to coax 99.999% uptime out of your servers/network, and there is a long history of implementations like these that were quickly reversed.

If you (or your PHB) *really* must do this. Roll it out to one department or a "test" group of 5-10% of your userbase. You'll quickly realize troubleshooting your network/servers takes nearly as much time as troubleshooting PC problems, and when it goes down (and it will go down) you can watch that 5-10% play card games for two hours while you run around like a madman in an attempt to fix it. All while their manager is screaming in your bloody ear about a deadline or some such. Heck if you want to squash it even faster, roll it out to upper-management first as your "test" base (latest and greatest guys, it was all Bob's idea too, I can't take ANY credit...). It will be quickly rejected (and the original proponent possibly looking for work..) If you're really against the idea, you could even cause the network errors yourself (not too many, don't want YOU to look incompetent). :)

There can be cost savings with an approach like this, after the roll-out phase. As well as manageability of software updates, new software etc. However most people who tried this switched back (at an even greater cost) because of the aforementioned (and other) issues. There are only a few situations where implementations like this make *any* sense, and I suspect you're not in one of them.

Re:Why? Why would you do this?!?

[LDoggg_]

It's going to cost nearly as much money to deploy this, perhaps a lot more (factor in server cost, and perhaps some network upgrades, along with the client itself). Your workforce will be terribly unhappy (latency, inability to use a REAL bloody computer), your support staff will have just as much to do trying to coax 99.999% uptime out of your servers/network, and there is a long history of implementations like these that were quickly reversed.

Do you have any real world experience with this? I do.

I volunteer for a school where I've built a network of 2 linux terminal servers, 1 LDAP/Samba server, and 65 thin clients.
I'm a software engineer by day, so I'm only able to help out the school an hour here or there on a day off. 65 hard drives out in a lab and classrooms would be a nightmare for me to maintain.
Thin clients typically have few moving parts, so they last forever, and they can be made from basically junk+ a 15 dollar bootable NIC.
All I have to do is ssh into the servers and do upgrades or software installs.

Just make sure you use decent server hardware and backup power supplies on them. You can buy a good server for the cost of only two full workstations these days.

Overall the savings on the TCO is enormous.

terminals + cluster

[AeiwiMaster]

Install the clients as linux terminals. http://www.ltsp.org/

Connect them to a mosix cluster http://www.mosix.org/

Use rdesktop for those apps which still need windows. http://www.rdesktop.org/

A terminal you say?

[Anonymous Coward]

That gives me the urge to haul my QVT-102 out of the basement and hook it to my 4x4" ARM9 Linux card. Mind you, I'd have to tweak one of the serial ports to slow down to 19200 bps and use handshaking or it'll overrun. And I'd have to replace Busybox which doesn't support curses and termcaps with something larger. (Except that the termcaps always sucked for the QVT102 and my own tweaked version is lost in the mists of time.)

Yeah, I could get used to 80x24 green characters (in a nice sans serif font--that's one thing that's been lost) and play the old games like TREK73, Zork, Nethack (if the curses are working), maybe even STTR1... Or I could just telnet in.

Hey you kids, get off my LAN!

Mixed Bag so a Blended Approach

[4pins]

I've been on all sides of this. Sometimes it's good. Most of the time it isn't adequate.

Many applications don't work well in a Terminal server environment. So we need (you guessed it) Windows on the client.
Other applications' licenses don't allow use on a Terminal server. So we need (yet again) Windows on the client.
Today remote users (for some reason) have latency that is too high to be productive on the Terminal server. So we'd better have Windows on the client.
The secretary who only ever uses Word and Outlook is now required to watch a training video on her computer. So we need Windows on the client.

At the same time a P3 can usually (depending on your "security" software) run a terminal server client and those one or two other things that need to be local. However, then you have to manage all those clients. You would be amazed at how much less work it is to manage Windows when all you have on a computer is a terminal server client and a few other applications. Especially if you lock them down well. To ease the management of these thick clients (for literally this situation) my employer had me create Tiotha (http://tiotha.sourceforge.net/).

Warning: The 0.15st version of Tiotha on the website has a horrible memory leak. I hope to release the update very soon!

Actually working on this right now... (Unique)

[Anonymous Coward]

K12LTSP + rdesktop + VMWare Server (Host: Linux, VMs: XP). The clients (any old machine or HP t5515 [$140] or equiv) boot via the network off the LTSP linux server. You manage everything based on MAC, which you keep track of very well - a map is nice, but having labels on the thin clients themselves goes a long way when you are on the phone with the user. If the user does not have any pressing reason to run XP, they get a Linux logon, and Evolution connects to the Exchange server (I know, I know, but one day it will go away). They have access to basic apps. If they need XP, LTSP takes care of booting their client straight into an rdesktop script, straight to their Virtual XP Machine. I'm all about the Free. Haven't explored Citrix yet, but you should also check out www.2x.com. Same premise as Citrix I believe, publishing apps or whole desktops.

DREAM THIN CLIENT:
PoE based (Jack PC from chippc.com style, I have three but they DO NOT run linux, 5 watts), not embedded in the wall, with an NVIDIA chipset so we can finally get some freaking decent video performance from these thin clients. Some users have to watch training videos (flash or wmv/avi/mpg), and whether in Linux or Windows, if the display is remote via RDP or X11, the frames are too choppy unless at 1/4 size or so... All USB is fine, as long as the LTSP kernels allow USB serial, floppy, etc whatever you have to add on the system.
The users that use XP do not have a way to reboot their own [virtualized] system. I put a reboot icon on the desktops that run 'shutdown -r -t 30 -f' when double clicked. Still trying to make a good way to reboot all systems once a week. But Power over Ethernet is really cool for thin clients - remote reboot a thin client, even if you can't ssh to it, though this never seems to be an issue. It's those VM's I'm always having to reboot.

I set this up then they didn't use it

[shrike_love]

I created a custom Gentoo install that used a custom GDM 'faces' theme to display icons for each Citrix 'app' (these were really one user account per application with the .xinitrc and .icaclient ini files setting the app/login when the user clicks the icon--no password necessary since they get prompted by Windows to login). This is actually a great way to do it when your unix skills are where mine are (not a guru!) because when the Citrix app closes, bam, the user's back at the GDM login screen. I'm sure one could whip something up in python or tcl/tk, but I don't have time to learn that.

Anyway, Citrix is the way to go because the Linux ICA Client lets you make the local floppy and optical drive or even local USB devices available to the user's session on the server. (For this you'll need to learn a bit about udev to make sure the usb devices are always mounted at a specific mount point that you can configure in the Citrix client.) It really worked like a charm and the user could plug in a flash drive or insert a CD/DVD and voila, it's right there on the Citrix server for them. You can even get the audio to work.

I created a boot CD (two CDs) that would let me install the setup to any PC with a CD drive. Thankfully we are standardized on NVidia video cards, so I didn't even have to worry about autodetection for that.

Before you go to all this work though, make sure they've already deployed some kind of thin client in a pilot that can do everything I've described. If it's missing any of that, the users are gonna hate it. /djs/

LiveCD with vmware player

[GuyverDH]

Build your config, save it, then burn it to a livecd - boots into vmware player, loads image and boom - online - totally stateless, to un-futz, just reboot.

Can your infrastructure handle it?

[nologin]

A lot of problems associated with thin client computing have little to do with the computers and terminals themselves; if you ignore the fact that your dependancy on the network is going to be an important part of keeping your thin clients working properly, it will likely cause more problems than solve them.

Redundant switches and network cards in servers will help increase the available bandwidth and avoid leaving possible single points of failure. Also, if your budget allows, try to seperate the network the users access the servers on from the one that serves file shares, backups and administrator access. It will go a long way to improve the service available to users of the thin clients.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Except he already has 3000 desktops

[Colin Smith]

And wouldn't it be nice to just install a CD and have them boot up as Xterms. The cost of 3000 CDs rather than 3000 new Wyse terminals.

Some Warnings, Some Advice and Softricity

[SixArmedJesus]

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

Re:Some Warnings, Some Advice and Softricity

[Provocateur]

...running on dummy terminals...

That's dumb terminals, you insensitive clod!

Oh, wait...

Re:Some Warnings, Some Advice and Softricity

[SixArmedJesus]

hahaha... thanks for pointing that out. My mistake. But really, around our place, it's dummy. :)

LTSP

[tacocat]

Use LTSP and you can convert all 3500 existing desktops into terminals without purchasing new hardware. Perhaps you can convince your boss to let you have 10% of the savings.

Fat clients are a bad ideia

[Anonymous Coward]

What is your fuss all about?

Fat Clients and Windows OS and Software are worst thing that came to computing. I know this I am the CIO!

Last year, when some upgrades where needed, I converted 10 Desktop PC to ELux Thin-Clients for a trial to evaluate this path. After some initial resistance from some users they stopped complaining. Everyone knows admits it was excellent move. All new workstation will be either Thin-clients or laptops. There won't be any new upgrade to Windows Vista crap!

Terminal server alternative

[netless]

my company was recently looking for a terminal service solution. Because we sell our software to mostly small companies, it is sometimes too expensive for them to buy MS Server 2003 just to have 5-6 simultanous rdp connections, so we were looking for alternative and we found http://www.xpunlimited.com/where they state
that their product
'XP Unlimited turns your Windows XP Professional System into a full blown Terminal Server, without any limit.'

we found them just last week so haven't deployed their software yet, but probably we'll go out and acquire.
Price can't be beat; unlimited connection terminal server on plain old winxp for just 125$

from my undertanding, they found a way to expand already present RDP in winxp pro.

Re:Terminal server alternative

[yuna49]

Before you run out and buy this, I suggest you read the EULA for Windows XP Professional:

You may install, use, access, display and run one copy of the Product on a single computer, such as a workstation, terminal or other device ("Workstation Computer"). The Product may not be used by more than two (2) processors at any one time on any single Workstation Computer. You may permit a maximum of ten (10) computers or other electronic devices (each a "Device") to connect to the Workstation Computer to utilize the services of the Product solely for File and Print services, Internet Information Services, and remote access (including connection sharing and telephony services). The ten connection maximum includes any indirect connections made through "multiplexing" or other software or hardware which pools or aggregates connections. Except as otherwise permitted by the NetMeeting, Remote Assistance, and Remote Desktop features described below, you may not use the Product to permit any Device to use, access, display or run other executable software residing on the Workstation Computer, nor may you permit any Device to use, access, display, or run the Product or Product's user interface, unless the Device has a separate license for the Product.

I'd be curious how xpunlimited.com explains that their software conforms to the Windows EULA.

Actually I did this... almost...

[Anonymous Coward]

Except we bought new thin clients.

1. Make sure you have the bandwidth: this is the sole most important factor.

Usually if you're in a single building, it's 100 Mbps Ethernet all over and you won't have any problem. But if you have remote offices with lousy connections (say 256kbps) you might be in trouble.

Each user can be tuned to use about 20 kbps. Each application server (3Ghz, 2GB RAM, 100 MB SCSI disks) can handle tipically 50 to 80 users (depending on many variables, mostly CPU, almost never memory). If you got the machines, Citrix can distribute users following previously set criteria (no connection to them, I'm just a satisfied customer). Linux desktops can use a free Citrix ICA client to connect to Windows servers, but you will have to pay client-access-licenses (CALs) to Microsoft -- as I understand, you don't own the software, Microsoft lends it to you via a contract -- the license. If they so choose you cannot use without phoning first, they can put it on the license. IANAL. Check your rights. Good luck and avoid the Bull Shit Association.

2. Real troubles you'll find:

a. Applications must be adapted: the C: drive is no longer available to the user (because it's used by the application server). Defaults like writing templates to C:\something need to be changed. We succesfully set individual user areas on our fileserver (e.g., on which to put mail files). But developers usually aren't willing to make changes (they already have much trouble, software development is a royal PITA). Adopting a "web access for all apps" policy well help, but legacy unchangeable apps will force you to keep a PC in every other room. As I see, this is not caused by thin clients, but by poor PC programming.

b. Windows 2003 is better, 2000 will do. Office 97 will give you white hair (files lost etc.), go for Office 2000 -- at least.

c. High throughput graphics is a no-no: AutoCAD, Flash films, any film in fact. Citrix has ways to downgrade the Flash experience somewhat gracefully, so that you can browse Flash based sites (they get jumpy, not slow).

d. Maybe you'll need an admin just for the thin client environment. This guy will want to save a lot, starting with no personal wallpapers, a lot of forbidden options (some must really be disabled). Over time, users will despise the thin clients because thy can't install games, their own beloved odd apps etc. This, despite everybody recognizing thin clients work a lot better than PCs. Its akin to bashing public transportation.

-----------------------

Now, for some personal opinion. Feel free to disregard it.

If you can, dump Windows. Or make two environments, a Windows one and a Linux one. Free apps like OpenOffice and the Gimp really make an user's life easier. They're not just free, they're easier than their proprietary counterparts.

Linux / Unix has a longer multiuser tradition. Some things which are difficult on Windows are usually already done for you in Linux environments.

There's an equivalent to Citrix in Linux, look for NX/FreeNX. I haven't used it yet, but people claim it's even faster than Citrix. Forget VNCs, they aren't good enough in Linux and a lot worse on Windows. Windows Terminal Services might do, but people say it works only up to 500 users. I don't use it, so I have no proof; it's all hearsay. Nor do I know if it is a total of 500 users or that number of concurrent users.

Some users who just use a few apps will be ok with the thin client; more advanced ones will undoubtedly hate you; be prepared to keep VIPs on PCs; as these are way costlier, try to minimize them. Many virtues of the thin client solution come from their homogeneity, using different PCs will increase maintenance costs, for instance.

If you use old PCs as thin clients, maybe it's better to remove unnecessary parts. HDs can be removed and PCs can boot from pendrives or even from the network. The LTSP project has info on this.

Don't Do It

[Blackknight]

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.

We run lots of TC

[terminal.dk]

We run lots of thin clients. We started with some HP/Compaq units, running a Windows CE version. But we are replacing them with a Linux based TC from Neoware. The neoware advantage is centralized management, and an OK easy way to push new software out. Look for a client management software as oart of the solution

Currently the workstations runs a Citrix Client and in many locations a 3270 terminal emulation software.

The Citrix servers needs all the RAM they can get, this is usually the bottleneck for number of users

Windows is a single point of failure

[pogson]

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.

It's all about CPU load, not bandwidth.

[pogson]

Quoting the parent:

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.

If it is done right, the user of a thin client does not even know his programme is running on a distant server. Normally, a user will have something like a P4 on his thick client and a single hard drive. When he loads a file, it takes a few ms to seek and a few more to transfer. With server-centric computing, files like the browser executable, common webpages, and parts of the databases are already in RAM taking microseconds to activate. Things just flash on the screen! On my personal terminal server, now two years old and rickety, the first time I load OpenOffice (my biggest, ugliest app) it can take 7s. When someone logs in after me and runs OO, it takes 2s to get going. You tell me users hate that?

The truth is the typical thick client is idling at a small percentage of CPU load waiting for a mere human to read and click. The idea of server centric computing is to give such unused power to the next guy. My AMD64 3000 (1.8 gHz clock) can please a whole room full of people (I have run 30 simultaneous users) on this basis alone. If you add to this caching of files, huge buffers, and RAID storage, you should ask, "Why would anyone want a pokey thick client that needs software and hardware maintenance and replacement every few years?" My server cost $1200 to build (about $50/client). Programme loading and file serving uses no bandwidth. I have everything on the server. I have gigabit/s bandwidth and 30 megabits/s is plenty for one client.

For 3500 clients, you could install 120 servers like mine of 30 quad core machines or 20 quad machines with faster clocks. The multi-opterons do cost more but you can put way more than 4gB RAM on them.

In case anyone is wondering, I run Linux, not stuff designed to run a single user.

Re:It's all about CPU load, not bandwidth.

[SixArmedJesus]

If it is done right, the user of a thin client does not even know his programme is running on a distant server. Normally, a user will have something like a P4 on his thick client and a single hard drive. When he loads a file, it takes a few ms to seek and a few more to transfer. With server-centric computing, files like the browser executable, common webpages, and parts of the databases are already in RAM taking microseconds to activate. Things just flash on the screen! On my personal terminal server, now two years old and rickety, the first time I load OpenOffice (my biggest, ugliest app) it can take 7s. When someone logs in after me and runs OO, it takes 2s to get going. You tell me users hate that? No, if it would work the way you seem to be able to make it work, then I'm sure it would be a great experience as long as the right programs were also served to the right people. You said it your self: "If it is done right"... From what I hear, too often that's not the case.

But in all fairness, I understand your point. Doing it right would make for a good experience. My point was that my company does it very poorly. Who honestly thinks that running a terminal and a server in the same building in Texas needs to have all data routed through New Jersey first? With 3500 employees in the original post, my thinking was that there is a good chance that they MAY not all be sitting in the same building, or even the same town.

Maybe you should be hired to come kick our IT into gear... I'd love to see it done right, and run Linux to do it to boot! Hell, getting our IT to respond quicker than a three-week time period to a simple "Please reset my password" request would be nice.

Re:It's all about CPU load, not bandwidth.

[pogson]

Parent quote:

"Hell, getting our IT to respond quicker than a three-week time period to a simple "Please reset my password" request would be nice."

Sounds like "Inactive Directory" at work. On my last system, after a few requests from folks who needed to change their passwords but did not know how, I typed a single line command that put an "apple" icon on every desktop with the words "change my password" underneath. That change went out to four servers on encrypted connections and it was so, just like God at Creation. Those who came to me in person had their passwords reset and they sat down at a chair next to my terminal and logged into their own configuration and changed their password to suit them. With folks in a WAN, that would not be possible and there would have to be some levels of filtering to prevent hackers from phoning up and asking for Joe's password to be reset... I created 700 accounts in a few minutes on my system with random passwords and usernames and handed books of coupons to managers who issued them to underlings and recorded the transactions. The whole user system was set up in an hour at my end. I detected two of those accounts being misused and suspended privileges instantly. No sweat.

Linux is the right way to go. With simple scripting one admin can control/monitor hundreds of servers with similar configurations. Of course, he can futz it up pretty quickly, too, but that is why Linux sysadmins draw top dollar.

I think the naysayers are thinking that other OS

[pogson]

Exactly. With Linux, you set it up and it just runs. There are none of the problems you encounter frequently with that other OS. Linux is the key. It works for us not Bill G.

I switched to Linux when I had just five Windows machines that crashed daily just when someone needed them to perform. I put Linux on out of desperation and the same hardware ran six months without downtime. People who use that other OS just cannot get their minds around a system that works, has few bugs, costs little, and is flexible enough to do whatever we wish.

Many cannot imagine watching a programme run on one machine from another machine. In the Windows world, that is two points of failure. In Linux, it is the way the display system works. You can have as many displays as you have resources and they do not have to be on the same machine. Bandwidth is only an issue if everyone is watching movies instead of working...

We're actually doing it now...

[ErichTheRed]

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.

LTSP preserves your current capital investment

[billstewart]

You've already spent money on PCs for everybody. At least for desktop users, LTSP gives you a way to keep using those machines for a long time, after you would have otherwise junked them. It wouldn't work in my environment - 98% of my organization uses laptops, because we work in the field and from home as well as from our offices - but if you're working from a desk, it's fine.

You'll still need servers, of course, and your servers will need upgrading, but it's a lot more concentrated and efficient.

Ardence for "thick" clients

[Anonymous Coward]

We use a product from Ardence (http://www.ardence.com) for our "thick" clients...essentially standard desktop PCs (high-end video cards, sound cards, devices, etc.) that lack only a hard drive. They have two primary flavors of their software streaming application...one that uses PXE, DHCP, and TFTP to do a diskless boot; the other, called Ardence Secure, which is what we use, uses an SDOM (Secure Disk On Module...basically some chips with an IDE interface...really small). The Secure product has some security advantages which our organization requires. In a nutshell, Ardence boots via PXE (Standard) or SDOM (Secure) from an IO server, which holds images of your system drive (C: drive). Enough of the disk image is loaded to run the OS and when additional files are needed it is pulled from the server. This is software streaming, similar to something like Softricity or Altiris SVS, but for the Operating System. The OS'es could be Windows or Linux, and the images can be put in one of several modes, including Private (read/write), Shared (read-only), or the entire image can be loaded into memory, size permitting. As I mentioned, we're running WinXP using the SDOMs with the Secure product and it works great. I'm not a company employee or shill, but I'm a big fan of the product and it definitely makes administration easier for us. There are more benefits, but if I keep going I'll definitely sound like a fanboy. One last thing...using this with an application streaming product like Altiris SVS really makes admin nice. We have a single server that houses user data and another with apps, and use folder redirection to point to the servers.

Diskless thin clients from Symbio Technologies

[Anonymous Coward]

Check out diskless thin clients from Symbio Technologies (http://www.symbio-technologies.com). They have no embedded software, so there's nothing to become outdated or need patching. They have no internal moving parts, so there's nothing to break. They're small (6 inches high), sturdy, and designed to work with LTSP. And their list price is $229.