Distributing Windows Programs to Linux Desktops?

prell asks: "Our company has approximately 250 Linux desktops, and an array of Linux servers. Recently, we've been presented with the possibility of migrating all or most of these machines to Windows to support one industry-specific application, and we do not want this to happen. Coming to mind immediately were: Wine and CrossOver Office; some sort of multi-user VNC setup; Ndiyo; and VMWare. Keeping in mind that the desktop machines are low-spec (~350MHz CPUs on average), what are our options? How can we preserve our Linux install-base in the presence of a non-canonical Windows program?"

Comments

Windows Terminal Server

[Kalak]

Windows Terminal server with the Linux desktops connecting via rdesktop is another way (assuming the app runs on TS).

(First Post)

consider porting it

[cahiha]

For the amount of money that it's going to cost you to do this (easily $500k), you may be able to create your own version of the application. Of course, I realize that that may not always be possible, but it is worth considering.

There may be a web-based version of the application.

You may be able to outsource the application and have your users access it through rdesktop.

If you only have a few users using it at a time, then accessing a bank of Windows machines through VNC should be enough.

If it's a high-powered application that can't be ported, then you're in trouble. If you are really, really lucky, you can run it under an old version of NT on VMware on your current hardware and under Linux. If it requires a new version of Windows and/or significant resources, you need to upgrade all your hardware, no matter what you do. I'd still get a site license for VMware and run Windows under Linux--that way, at least you more easily avoid the costs of downgrading to an all Windows server infrastructure and retraining everybody, and you can more easily distribute and lock down the (virtual) Windows desktops.

Don't blame your decision of using Linux up to now for your predicament--consider yourself lucky that you have been able to save money so far. The cost of dealing with Windows now (hardware upgrades, licenses, installation, system management, etc.) is the cost you would otherwise have been paying roughly every two years as the cost of doing business.

Real world example

[DarkDust]

I can give a concrete example on how we solved a few problems with Windows applications in a Linux-only environment.

I worked on a big migration project here in Bavaria, where the complete Blood Donation Service Of The Bavarian Red Cross switched from individual Windows desktops to a centralized application server/thin client system. I estimate this are about 1000 users affected. The migration was done about two years ago.

A short overview: The users are using Linux based thin clients which I've developed to connect to an array of application servers on which I've worked as well. Every site has its own application servers, in Munich we currently have three or four of them (Dual PIII 1.4GHz, 2GB RAM) and IIRC about 200 people do their daily work on them... no performance problems, but if we had we just would add another server. The thin clients connect to the servers through DNS round robin which is enough load balancing in this case. The application servers are just normal SuSE 8.0 servers with KDE 3.1 where I've configured KDE to restrict what users may do (e.g. they are not allowed to move the Kicker bar... we did things like this to prevent support calls like "My start bar is now on the right, help !" ;-).

Now, the Blood Donation Service people who are working in the areas where the donated blood is prepared and checked for diseases rely on a specific application which only runs on Windows. We evaluated running this application with Wine but it wasn't good enough for this application back then. To make a long story short, this is how we're doing it:

We have a few Linux servers on which we're running Windows terminal servers (I don't know which Windows) in VMWares. I explain the reason for this later. Clients who are working on the application servers connect to the Windows servers with rdesktop. The users' home directories are on NFS servers which means they get their home directory on every application server and on the Windows servers as well. This works very well. Only a few dozen people need to access Windows servers because of this and another industry-specific application.

We needed to identify which thin client is accessing the Windows application. Because rdesktop runs on the application server we needed to do a trick: I've enhanced our thin clients to include a finger server which tells finger clients the MAC address of the thin client. When the users log in to the application server the MAC address is finger'ed from the thin client and stored in an environment variable. And when the users then start their rdesktop the MAC address is passed as host name ;-) So Windows thinks the user is connecting from, say, a computer called 00AB12CD34EF and this can be evaluated on the Windows side :-)

Now for the reason why we run Windows in VMWares: the whole point of our architecture is that we have a master site where all bavarian application servers are configured (new applications get installed there, for example) and they synchronize through rsync to all sites. This means all application servers are in sync and changes are only done on exactly one server. We wanted to do the same with Windows. In short: it's not possible with Windows-only methods and applications because of some limitations of Windows. The best solution is to run Windows in a Linux VMWare and rsync the VMWare disk from the master server to all site servers :-)

This setup is running full-scale (i.e. in the complete Blood Donation Service of Bavaria) for about one and a half years, and it's running very well. No major problems. Even the 50+ secretaries didn't have any major problems (except for a bug in the Linux version of Acrobat Reader 5.0.x and PDF forms) ;-)