In a ideal world every piece of client software is either:
- web based, with standards based cross browser development
- portable, developed with a cross platform language / toolkit (Java, Qt, Gtk+, WxWidgets, ...)
In the real world there's people developing fat clients, where a web interface would be the best way. There's people programming in .NET, delivering solutions to the customers that limit their OS choices to Windows. And there are public and private institutions buying without knowing how this may affect them in the future.
However, the situation has improved considerably with the arrival of fast, low-cost servers and virtualization technologies. Whereas Wine / Codeweavers are excellent solutions for popular applications whose upgrade cycle is very long (ex:
MsOffice under Codeweavers) and can thus be certified, the general solution is more complex. In general, one may have to deal with not so popular applications that need frequent updates, or applications that just don't work under Wine.
The 3 key pieces for dealing with such software are:
1) Windows Server - enable remote access to monoplatform Windows applications with a terminal server setup
2) Vmware / Xen / ... - setup the Windows server as a VM on a stable Linux server
3) rdesktop - the wonderful open source terminal services client
The correct interaction of these components will enable transparent access to Windows applications from any Linux workstation without major breaking of a stable setup.
Arquitecture example
Dealing with Windows machines is a troublesome task in many ways . So one may wonder if dealing with a multi-user Windows machine will be a nightmare. It won't if some simple rules are followed:
- no administration privileges for any regular user
- minimal software installation
- automatic startup of the desired applications
The last point is paramount, on preventing users from creating security stability and performance problems. Each user may need a single application or set of several applications. Depending on the case, the application executable or a batch file launching the desired set of applications should be configured on the user properties. With this procedure, the users never get to see the usual windows shell. They only see their applications and each session is terminated when the last window is closed.
Automatic application startup
The session startup can be perfectly integrated with a Linux desktop by creating a shortcut to rdesktop, invoked with the right command line arguments.
Some usage examples:
rdesktop -g 1024x768 -a 16 -k pt 192.168.0.18
Connects to 192.168.0.18 with a window size of 1024x768 pixels, 16 bit color and portuguese keyboard layout.
Server login session
rdesktop -g 1024x768 -a 16 -k pt -u User1 -p MyPassword 192.168.0.18
Same thing but enabling seamless login.
rdesktop -g 1024x768 -a 16 -k pt -u User1 -p MyPassword -r printer:PSC1410='Apple LaserWriter 12/640 PS' 192.168.0.18
Same thing but making the local PSC1410 printer queue available on the terminal server.
This is a great feature of rdesktop: one can forward all locally configured CUPS printer queues without having to install any driver on the Windows machine. That is possible because windows ships with some old postscript drivers, like Apple LaserWriter, and CUPS expects to receive postscript from any application. This can't be done with the Microsoft remote desktop client, which requires the installation on the terminal server of all the windows drivers corresponding to the local printers.
Several printers can be passed on the command line and all of them will be available for the Windows applications. It is also possible to have a local directory available as a Windows share on the server using the right command line arguments.
By using a desktop icon to automate the startup of rdesktop one can seamlessly integrate Windows applications on Linux desktops without even the users noticing that there are two different operating systems in use. With this kind of setup one can benefict from the stability of the Linux desktops without sacrificing access to specific applications that may be needed. Surely the CAL and Terminal Service licences are costly and web / portable applications are the preferred way. However, when using Windows is unavoidable, a terminal server is a much better solution than a network of Windows workstations.
We have used this kind of setup in production with both local machines and VPN clients. The performance and stability are satisfactory.
