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
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.
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?
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
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
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
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
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
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 are allowed.
This can get really confusing: see How to install Microsoft Office on Terminal
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
[ 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
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?
Also, here is a nice chart that compares remote desktop software for various platforms. That's a rehash of the same thing from Wikipedia; I only mention it because I wasn't aware of the Wikipedia chart until I was sent that..
From Linux: http://www.rdesktop.org/.
If this page was useful to you, please help others find it:
More Articles by Tony Lawrence
- Find me on Google+
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.