One of the ways to reduce maintenance issues with remote users is to simplify the hardware and software the users are given. After all, the more complex the machinery, the more tricky the task of fixing problems from afar. The most extreme answer is to go for the simplest possible computer at the user's end a thin client; in this how to, we'll look at the considerations you have to make if this is to be a painless process.
The first ingredient for a thin client operation is a reliable application server which in practice probably means more than one. These servers sit either at your main office or, possibly, in a reliable data centre somewhere, and it's on the application servers that the users' programs actually run.
There are two popular thin client operating protocols: Citrixs Independent Computing Architecture (ICA) and Microsofts Remote Desktop Protocol (RDP). The former is what you'll be using if you go for Citrix's application server package (MetaFrame), but if you prefer to go with Microsoft's Terminal Services, you'll use their proprietary RDP instead. Modern thin client computers such as WYSE's WinTerm range support both, so you're not stuck with proprietary protocols.
The two important considerations with application servers are performance and reliability. Performance is a factor of the applications you're running and the number of remote clients connecting concurrently to each server, and it's important to check the hardware requirements for your chosen application server before buying your kit (links are provided at the end of this article).
Reliability is, of course, a factor of the hardware you specify. If your applications are mission-critical, you'll consider installing multiple servers in a cluster but if the budget doesn't stretch that far then you should at least ensure that disks are RAIDed sensibly and that you have redundant fans and power supplies in the server(s).
There is a third consideration for the application server which isn't directly related to the server platform itself: the user applications. As we've said before , some third-party and home-grown applications may have issues when moving from a desktop environment to an application server, so some research is in order if you use this type of application.
The WAN connection
The next essential factor in thin client operation is the reliability of the link between the user and the server. Clearly, there's no point having a super-reliable server if the WAN link is up and down like a yo-yo.
It's perfectly feasible to run thin client application servers over Internet links, but reliability can suffer and the service level agreement from the Internet supplier will generally not be sufficient (as anyone whose BT ADSL has ever broken will testify, it might be fixed in minutes but it could be days). You'll probably want to subscribe to a WAN arrangement with a proper service level agreement attached, then one that guarantees you a response in a timescale that fits the business.
The traffic flows of thin client protocols are generally very asymmetric there's a small amount of information (details of mouse movements and clicks) flying up the wire, and a much larger amount (screen updates) coming back, and so thin client operation lends itself nicely to ADSL. We'd suggest you go for a private circuit ADSL offering, though something like BT IPStream (see link) since you get the cost benefits of ADSL along with service and performance benefits of private circuits.
With regard to the connection speed you'll need: again, this depends how many clients you'll be deploying. Again, we're provided links at the end of this article to some Citrix and Microsoft documents that help out on this front.
Dealing with hardware failures on the user's equipment is a breeze when you're working with thin clients. Not only do the devices themselves have a minimum of moving parts (and mechanical stuff is always the most susceptible to failure) but the functionality is also relatively simple (no dial-up networking problems to diagnose, for instance). If the hardware fails, you just swap it out and put a replacement in; if you have remote offices with multiple users you can consider giving each office a spare thin client terminal just in case, or if your users work in ones and twos a next-day courier may be the answer.
One of the benefits of using thin clients is that you reduce the risk of users unwittingly introducing viruses into the corporate network, as they can't use floppies or CDs with their terminals. This can, however, be one of the drawbacks too: there may be a time when a legitimate need for connecting peripherals arises allowing users to print material when working at home, for instance.
The thin client manufacturers have thought of this, though, and so as well as basic, connectionless machines you can also purchase thin clients with one or more of the standard connectors USB, serial, parallel and so on. Clearly you need to control who can connect what (which you do centrally on the admin console), but the option's there if you need it.
The last thing to consider is: what about users who need to work when disconnected from the corporate network? Well, in such cases you're going to have to provide them with fully-fledged computers; you can, however, continue to integrate them into the thin client world by using an emulator on their PCs to provide connectivity to the central application servers. If you're using Windows Terminal Server, for instance, it's a simple case of providing the users with Microsoft's Remote Desktop Connection (called the Terminal Services Client on pre-XP versions of Windows); Citrix users have a similar option, the ICA Client (which, incidentally, runs on a number of client operating systems including Windows, MacOS, OS/2, DOS and various Linux/Unix platforms).
Thin client operation can bring immense savings in client support for companies with a number of remote users. To make the most of it, the users must work in one place (at home, for instance, or in branch offices), but if your enterprise is suited to this mode of working, the potential rewards are significant.