Would You Move to Windows Thin Clients?

mcck asks: "My workplace is getting ready to study this problem in depth. From my preliminary research, there is very little savings when moving to a thin client environment that isn't based on Linux. Current thinking is that we will have to stick with Windows, so Linux is out for now. Citrix maxes out at around 10-25 users per server. I haven't studied Windows Terminal Server as deeply, but it looks to be about the same. Once we buy the 100 servers we would need to support 1000 or so of our users that would be migrated, plus increase our system administration staff to adequately support those servers, it looks doubtful that we would save much money at all, if any. Plus, if we upgrade all of the related desktop hardware to snazzy new official thin client boxes instead of trying to get more life out of old hardware (which is what they want to do right now), costs go up even more. So here's a question for anyone who has studied this issue, or seen its consequences at their workplace: Is thin client really a cost-saving approach to a large user environment?"

"Most users will be running basic MS Office apps, Groupwise for e-mail, and accessing some Oracle databases. A consultant hired for preliminary recommendations is saying that we should run Windows XP on the thin client boxes, not even the embedded version but the full one. Additionally, some of our users have more powerful applications like AutoCAD and ArcMap. We have already determined that those users will not be moving to the thin client machines.

Our department has spoken with a Citrix support/sales person who claims you can support up to 1000 clients on a single Citrix server. That seems so far from what I have generally read that I have a hard time buying it. Can anyone corroborate that claim? Again, most users will be using Office, Groupwise, and accessing Oracle DBs.

Does anyone have any experience with a workplace making this sort of migration? I would love to find a way to make it work, but from the research I have done so far, it doesn't look like we are going to get any cost-savings (unless they miraculously decide to go with Linux)."

Comments

I'm going to keep this short and simple.

[torpor]

Okay, no I'm not.

Why change?

What do you need to 'fix' in the existing system?

Continue to use per-desk PC's, albeit cheaper/better/easier to administer, and continue to utilize 'upgrade' licensing schemes - the cheapest you can possibly get from Microsoft, is, probably, very cheap - to maintain the OS upgrade/fix end of things, and you can probably do this all very cheap.

"Thin-client" is just another word for extremely small/light/cheap PC-in-a-box. So maybe the simpler option to 'considering remote client solutions' is simply, put it all into better hardware (new CPU/more RAM/*standard* video for all systems/etc.) and don't change your existing software standards ... or at least, don't change it much. Maybe re-think your use of networking and other such things, but still within the framework of your existing OS setup.

If you maintain your existing stance with regard to how well your business problems are solved by your software systems, and give it a 'boost' with periodical hardware upgrades for key areas/servers every now and then, there is little reason to drastically change everything at all.

When the PC is akin to the size/heft of a block of printer paper, 'administration' becomes relatively trivial - particularly in an organization of 2,000 people or so... if you've got your software worked out.

Just get smaller, lighter, cheaper PC's, and refresh them every now and then. Convert as much as possible to cheap laptops and monitors, even.

They are out there.

I know Linux is "out", but...

[Yonder Way]

...at $WORK I have a Linux box that handles ~25 full screen X sessions all day long, and hovers around .10 load average. The box is an old dual PIII 500MHz with 2GB RAM, 36GB RAID 0+1 volume. All of the client machines are Windows XP desktops using VNC viewer locally to attach to Xvnc sessions on the Linux box (which is kicked off in xinetd on-demand).

The server itself was considered too slow to run Windows. It had been retired from the Windows domain, and the bean counters have written it off the books. Yet there it is, serving a vital business function to my users that is about to scale up to another ~30 users in the next couple of weeks.

Every bit of software involved in making this happen was free. The hardware was, effectively, free. And I'm already handling more users than the newfangled expensive Windows 2000 Terminal Server that is parked in the same rack.

This move was made to stave off the sudden onslaught of requests for a second machine (linux) at every desk. The corporate standard desktop has been and will be Windows for some time to come. But setting up a Linux box with lots of RAM, fast disk and Xvnc has already saved us over $45,000 that would have otherwise been spent on dedicated Linux machines at every desk.

Re:A couple of considerations

[innosent]

As an extra note, if you can do this with Linux, OpenMosix becomes an option. This way, the users can all use (to them) a single server which you administer, and the load is distributed fairly evenly throughout the cluster. SSI clusters and centralized management can really eliminate a lot of headaches and provide the most performance benefit (since *Mosix automatically tries to get the best performance for a process) when you have 1000 users to support.

Cost savings

[DarkDust]

Is thin client really a cost-saving approach to a large user environment?

In my experience, yes. Look at this:

At a customer site we have the following implementation, fully Linux: every location has one or more application servers where people log in with their thin clients. There is a master application server. At every location on application master is promoted to be a local master. Every night the local masters synchronize with the global master, and later the remaining application servers synchronize with their local masters.

This means that you have to install an application server only on the global master, the next day all other servers have that application as well. Zero point of administration when it comes to that. The configuration files are not synch'ed from the global master, but at every location the application servers synchronize their configuration (/etc directory with a few exceptions) with their local masters, which means for example that configuring a new printer just has to be done on the local master, the next day all servers at that location know about that new printer.

Users' home directories are mounted via NFS from another server.

And now for the Windows part in this picture: we use VMWare and their persistent disk images (I think they're called like that; they throw away all changes and remain constant). On these VMWares we run Windows 2000 servers to which people can connect via rdesktop (RDP). We are now able to administrate just the Windows image of the global master (by temporarily switching off the persistance option), and the next day all other Windows images are the same. That's also pretty resistant to viruses and worms: just reboot in case of infection :-)

This saves money, since the only points to administrate are the global master and sometimes the local masters (site specific configuration stuff like printers).