At the tail end of the 20th century, the likes of NCD and Oracle/Acorn were telling the world that they ought to throw away their PCs and move to "thin client" computing. No more complex PCs on desks just run the applications over the network and have the most basic, solid-state device at each user's workstation to provide the interface to the keyboard and screen.
The idea, although it didn't really catch on at the time, has been a profitable one for companies like Citrix, Wyse and even Microsoft. Although most organisations have stuck with good old desktop PCs that go wrong far too often, there are serious users of thin clients out there who are more than happy that they rarely have to visit users and fix broken computers.
Although the transition to thin client computing is not a particularly painful one, there are some common compatibility problems that organisations come across when dipping a toe in the water of thin client computing. We'll go through the key ones in this RTFM.
Although not strictly a compatibility issue, the resilience of the servers and the network are key to the performance of a thin client setup. You should always, always consider resilience first, since to concentrate your program execution on a single server or to rely on a single network switch is far from a sensible idea.
Many software packages, usually home-made ones but sometimes commercial offerings, are written in such a way that they are unable to work on an application server. Say, for example, that a program has been told to use a specific file (e.g. C:\TEMP\PROG.TMP) as its' temporary storage space; this is fine when you're running one copy per desktop, but it's likely to break when the second person tries to run it on the terminal server, as the file will be marked as "in use" by the first person's copy. Similarly if a program doesn't do as much error checking as it would like when it tries to grab the modem, or the printer port. Investigate what common resources your programs use, and verify whether they deal gracefully with the instances when those resources aren't available.
Known issues with software
A related issue, but one you can check up on very easily, is where commercial software (even some of Microsoft's own applications) is known to have issues when working with thin client computing. A web search will quickly elicit the world's collective knowledge regarding your particular applications, but you should also check with the thin client server software company's compatibility lists, as they can save you a lot of digging. Microsoft's compatibility summary for Terminal Services can be found at www.microsoft.com/windows2000/docs/W2kTSApCmpt.doc, for example, but you should check the website of the vendor whose application server you're considering buying for their equivalent.
The busier the screen is by which we mean the amount the display changes the less suited to operation in a thin client an application will be. This is particularly true if the client machines are at the other end of a slow link, such as a VPN or WAN connection. This is because the vast majority of the traffic in a thin client setup is what's telling the client how to change the screen display so if there are animated items, video streams, dozens of windows popping up all over, or anything so visually complex, think twice before trying to move to a thin client setup.
Removable media are always a problem with thin clients, although the absence of a floppy or CD-ROM drive, or a USB port, on most thin client computers brings an added level of security and virus protection to the organisation. If you do have users who really need to use removable media, you can either consider providing a PC at some central location that they can walk to in order to upload or download data to removable disks, or you can decide that those users actually deserve to have full-blown PCs that simply run the thin client application in a window. The same applies to laptop users who are out on the road a lot, and for whom it would be impractical to have to connect to the office every time they need to run an application.
Of course, the more users for whom you relent and allow to have PCs, the less benefit you're getting from the thin client setup, so you need to err on the side of strictness.
Although strictly a subset of the issues mentioned earlier under "resource sharing", any programs that sit and listen for network traffic are likely to break under Terminal Services. Say, for instance, you have a CTI application that sits on the PBX and, each time a call comes in for a particular person, opens a TCP connection to that person's machine in order to instruct an application to pop up the caller's information. As with the earlier example of a program grabbing the serial port, any TCP application that's expecting to receive an incoming connection will listen on a predetermined TCP port, and so the second instance of the program to attempt to grab that port will be told: "Resource in use". There are ways around this issue, most of which will be application-dependent, but it can cost time and money to resolve such problems.
If you're serious about thin client computing, these issues can all be worked around or avoided though in cases where you're using third party software that's causing the incompatibility, there will be a cost in terms of time and probably money to persuade the vendor to make the changes that are needed to their packages in order to make them comply with the requirements of the thin client server.
In fact, all of these issues are nothing new to Unix system managers and application programmers, since Unix has always been designed to run multiple instances of any given application. The situation is different with Windows, though: thin client computing and the concept of an application server are relatively new concepts, and although there are documented "official" ways to write programs that are designed to avoid the types of problem outlined here, not all programmers are aware of them (or bother to follow them).