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)

Re:Windows Terminal Server

[spooky_nerd]

Yes, licensing is expensive. But the cost of TS CAL is about the same as an XP license. As long as you only use the server for terminal services, and nothing else, e.g. file server, you should only need a TS CAL for each client. The cost of licensing the app should be the same. That is, most companies will say that 50 licenses on 50 computers is equivalent to 50 licenses on 1 computer. The advantage is that you don't have to upgrade the hardware on the desktops to support Windows.

The perfect solution

[treff89]

VMware is always a useful app, however your comps may be too slow. CITRIX!! Citrix would be _the_ best solution in this situation. Works great on that speed hardware, doesn't require a great amount of bandwidth, and runs with all applications EXTREMELY well. Clients available for Linux. I'd say, the perfect solution.

winframe servers and rdesktop

[rusty0101]

Possibly the easiest would be to set up a collection of winframe servers in your server farm, and attach to them as needed via rdesktop from your Linux desktops.

Then again, I have not implemented this, so your experience may differ.

-Rusty

Re:winframe servers and rdesktop

[chris_mahan]

Rdesktop works fine. Just be aware you're still going to have to pay for terminal server connection licences.

Depends on the applications

[mangu]

Where I work we have some Linux desktops. At first we used VMware with good results, but on my own machine I use wine. I found that the only windows application I really need to use is Lotus Notes, and it runs very well on wine. However, some people here have excel macros that they can't run on OpenOffice, so they are still running VMware.

Re:Depends on the applications

[mangu]

why the overhead still of VMWare

Just habit. As we said, we started with VMware on all machines, some people keep using it out of habit. I don't like it for two reasons: first, it's somewhat unstable and freezes from time to time; second, it allocates a fixed CPU share for each VM. Typically, this would be 49% of the CPU for Linux, 49% for windows, 2% overhead. Even if nothing is running on the other VM, you only get half of the CPU ofr each process.

Re:Your company's priorities

[NitsujTPU]

Yes, I did... ...and then I realized that even as a graduate student, if they had a 250 seat installation, I could afford to replace the whole thing.

Upgrading would probably get them the Windows licenses they need as well as a throw in.

Honestly, much of the time, the workers do need better desktops... but if it's an arms race to keep management in better machinery than the workers... the workers have to have shitty machines to prove the point. Lame.

It would help....

[numbski]

...if we knew what the software was. Is it a software publisher that is approachable? Would they be willing to consider doing a compile of the application using winelib?

That is make a win32 exe that runs on linux natively.

The more I look at migrating some office to OSS, there is always, ALWAYS that one application that the office can't part with for whatever reason. Or there are excel/word macros that don't work in OOo and they can't/won't re-write them to work in OOo.

If the office is commited to it, then I'd try getting it to compile with Winelib.

Another option is that if it runs under wine, but runs slowly on those dinky machines, get the company to consider setting up a powerful multi-cpu machine to use as a terminal server of sorts, load linux on it, install wine, then the application. Set it up to allow X11 forwarding via ssh. Make sure each user has a shared key with the server for ssh. Now set up a shortcut/script or whatever that does this:

ssh -X user@server 'wine app.exe'

The application will display locally, but the cpu cycles will be on the server.

Will that work for you?

Those with more experience with Wine and winelib, what kind of difficulties should a developer expect if a client makes this request and the devloper in question decides to attempt to comply. Say the app is written in Visual C++ for example...

Another remote solution

[pyrrhonist]

If you're unwilling to purchase a Windows 2003 Server and a Microsoft Terminal Services license set, but still would like to run the troublesome application remotely, here is another solution.

All you need is a Windows XP Professional machine with your software on it, and then you can run WinConnect Server XP. It is inexpensive, uses regular Windows RDP, includes a fairly decent admin tool, and you can try it out for free. ThinSoft also makes a Linux client, but you can use rdesktop. The bad news is that it only allows 21 clients concurrently.

No, I don't work for them, but I have used their software quite a bit. Their site leads you to believe that they only sell licenses in groups of three, but in fact, they are more than willing to sell you individual licenses. All in all, their system works rather well.

Re:Don't defeat your main purpose!

[bluGill]

CodeWeavers is a company that is looking for some more people to buy their product. They will make the tweaks needed to get your software to work - for a fee of course. There are two advantages of buying Wine from Codeweavers, one is they will make the tweaks you need to make your stuff work, and the other is it supports Wine development, which supports linux.

CodeWeavers is not such a large company that they can afford to turn down money. They will be happy to discuss terms to get any application supported. And they will be honest about it - some things are a matter of the program is the only one so far using some API, so it hasn't been implemented, but once asked for they can do it in a day. Others require a few years of work yet, but they will tell you that it isn't worth the cost. (Unless it really is worth the cost to you...)

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) ;-)