Windows 2003 Terminal Server, Remote Desktop, thin clients and all that

Citrix, Terminal Server, Tarantellla, Web Enabled, Thin Client, Diskless Workstation, Dumb Terminal, Smart Terminal, Client Server, or related Remote Desktop, VNC, GotoMyPC, Screen Scraping, blah, blah, blah. No wonder people get confused. Lots of similar or related things, no end of licensing confusion, no end of general confusion.

Let's try to cut through some of it. First, let's move back and look at the original Unix style multi-user model: dumb terminals, green screens (even if they were orange or white), the character based environment that all Windows folk loathe and disparage. How did that work? The application ran on the Unix server, and only sent characters back to the terminal, and the terminal only sent keystrokes to the Unix box. This is the hateful environment of Unix, disliked not just for its esoteric character based commands, but also for the centralized control, the lack of empowerment for the user, and for the priesthood of the central server administrators. Funny, but the priesthood is back, along with centralized control, lack of empowerment, and all that. All that's different is GUI vs. character based.

And that's not even fair either, because Unix has had GUI remote access for some time: X Windows. Again, the real application runs on the CPU of the server, and the client (the X Terminal) just sends key and mouse events and then displays the screens that the centralized server app sends back. The X Terminal can be a stand alone device not a whole lot smarter than a dumb terminal, or it can be a piece of software running on a PC or other computer. Whatever it is, we're still in the same "mainframe" mindset: the app runs on the server.

Client Server

At some point, someone realized that it might make sense to have the client do some of the grunt work. Maybe it's as simple as just caching some graphics, but more likely it means hiding an unfriendly server app from the user. This can make things easier all around: put raw power in the server application, but don't concern yourself with user friendliness. If you need a list of A/R totals, just have the server dump that information: no formatting, no prettiness, no grand totals, no headers, etc. Put some smarts in the client to do the pretty-it-up stuff. The server side might be little more than a database that takes SQL queries and spits back results, but the GUI-fied client running on a PC (or whatever - could be running on a Solaris SparcStation) hides all that.

Now, the important question: is that a "fat" client or a "thin" client? And the answer is: who knows? It depends on who is looking at what and what they think is important about each side of the system. Who does most of the heavy lifting? See Fat vs. Thin: Ten Common Myths about Client / Server

There's also a very special kind of client, designed for old character based apps. This GUI-fies the old Unix app, adding menus and mouse capability etc. It may involve a new app added to the server that helps it talk to the old app, or it might do "screen scraping" - figuring out what's going on by reading characters from the screen. Or it might do both.

Windows, the single user OS that isn't really

Enough about Unix, at least for now. Enter Windows. Windows apps were originally very "fat client". If they used a server at all, it was for file and print services: the data might be stored at the server, but the app ran at the local PC. That's as "fat client" as you can get: the server's involvement is very small. Important, of course, but it's not doing much real work. There are still lots of "multi-user" Windows apps that work that way. But eventually people realized that the server could run the app just like it did on Unix (except with more interruptions from crashes, of course) and a thin (or thinner) client would run at the PC.

In this situation, the Windows server is acting just like the Unix server did: the central app runs on the server, clients on PC's send commands to it and process the results. In fact, this is so much like Unix that some app vendors let you choose your server OS: they have Windows versions, Unix versions, Commodore 64 versions .. well, maybe not that, but the idea that the server part of the app could run on Windows or various flavors of Unix is still popular with bigger and more important apps. There's a Windows client, but the server can be whatever you want.

Remote Desktop, VNC, etc

These types of products have nothing to do with what we are talking about, except in the sense that they are thin clients for the biggest app of all: the OS desktop. They all have different features and capabilities: they make take total control, they may "share" with the machine's real user (great for training), but the important point is that they are running the machine's desktop. On a Windows machine, that's as far as you go, though of course with a Unix box there could be multiple possibilities. But let's not complicate that.

However, Remote Desktop is extremely similar to the Windows Terminal Server client we'll be talking about next. So similar that you may find the clients talked about in the same context, and at least on some platforms, you might use the same client software to access either Remote Desktop or a Windows Terminal Server. Even if there is different software, you might me able to use the Terminal Server Client to access Remote Desktop. I only mention all that so you know that is why some discussions of one or the other may be confusing.

Terminal Server, Citrix, Tarantella

Now we come to the more interesting stuff. The idea behind all all of this is to let the Windows machine run more than one copy of an application. Why not? Why limit yourself to one desktop? Why not have a copy that the client off at the other PC can individually control? Think of the benefits: one application to keep patched and current. One big muscular server to run this stuff, much weaker machines for the clients. Control the environment they see: maybe they only get one specific app rather than a whole desktop! Or if they do get more general purpose use, we can lock them down much more easily to specific settings that they absolutely cannot mess with no matter how much they may know about their PC. Centralized control, money saved, security improved, wow, this is great!

Well, except that it really wasn't so great, at least so not when it first came out. Nothing wrong with the base idea, heck, that had been proven and tested on Unix for many years. And nothing really wrong with the server software or the PC clients that let all this magic happen - oh, there may have been bugs here and there, but those get cleared up. No, the real problem was the Windows applications.

Design Basics

The problem was that the Windows apps were seldom designed to be multi-user. They were written to run by themselves on their own machines, and they tended to not like keeping separate configurations etc. for multiple users. The multi-user software on the server could do a few things to fool the apps, but a poorly written app would still screw you up royally. So the early promise of this fell very flat: I saw many a business embrace this idea and toss it out a year or so later.

That was some time ago though. Nowadays, most Windows apps (the important ones, anyway) have been rewritten to be multi-user friendly. You can run Terminal Server (or Citrix, Tarantella, and who knows what else) and access apps with much weaker clients. The clients may not have to run on Windows PC's either: Macs, Linux, maybe even your mobile telephone or PDA can have clients to access the apps. All you need is licenses - both licenses for the multi-user access software AND licenses to run the apps multiple times. That can all be very confusing, see http://www.brianmadden.com/content/content.asp?id=154 and http://www.microsoft.com/windowsserver2003/howtobuy/licensing/ts2003.mspx for some help with that.

By the way: Microsoft makes you buy licenses for products like Word etc. for each computer (terminal, whatever) that will connect and use the product. No "floating" licenses; see Licensing Microsoft Office in a Windows Terminal Server Environment

This can get really confusing: see How to install Microsoft Office on Terminal Server

Let's get really complicated

OK, time for a test. Here's the situation: we have a Unix server that runs a Cobol application. It uses what it calls a "thin client" app that you install on Windows machines. You also have remote offices and they tell you that the best way to handle that is to install Terminal Server. Their thin client, installed on the big Windows 2003 Terminal Server, will access the Unix box. So - remote clients access the Terminal Server to run the thin client which actually talks to the server app on the Unix box. Need a picture?

 [ Windows Machine Running Terminal Server Client]  <--->
 
 [ Windows 2003 Terminal Server running application's Thin Client ] <--->
 
 [ Unix box running application server component ] 
 
 

Do you see that a thin client is running another thin client? OK, two questions? Do they need the Terminal Server? If I do use the Terminal Server, does that mean ALL my Windows PC's have to use it?

If you've read and understood all of this, you know the answers. First, no, they don't absolutely need the Terminal Server. Their concern probably is speed because your remote machines aren't running at local network speeds. It's possible that their application doesn't like waiting for things too long and will misbehave if you don't use this method, but more likely it's just that performance will suffer. Still, app vendors are always looking for excuses when their software bombs, so if they say they want Terminal Server, you probably should do it their way. But that doesn't mean that your local PC's need to access the app that way. Assuming they have the horsepower and appropriate OS to run the app's thin client, they can bypass the Terminal Server and go straight to the Unix box. However, you may have other reasons to send them the circuitous route: you may have older, weaker machines that can't handle the app's not-so-very-thin client, but could run the Terminal Server Client. Or maybe you've just had it with Microsoft's never ending problems and you want to run Linux or Mac PC's - they can run the app's Windows Client by way of Terminal Server. Carried to the extreme, you might need only ONE Windows machine to care for. That's a comforting thought, isn't it?

See also http://www.brienposey.com/kb/using_terminal_services_for_net_mgmt_1.asp