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?

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 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 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?

Also, here is a nice chart that compares remote desktop software for various platforms.

From Linux: http://www.rdesktop.org/.


Got something to add? Send me email.





(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Windows 2003 Terminal Server, Remote Desktop, thin clients


9 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Tony Lawrence




---November 19, 2004

Hehe. And people get confused by X Windows networking.

Mostly terminology. Too ancient for todays PC's server/client model:
X Servers = X Windows software that runs on the X terminals

X Clients = Programs that run on X Servers. (like Firefox Web browser is a X Client)

Think about it like the X Server serves the keyboard, pointing device, and monitor I/O "up" to the X client program. Also remember the X Server runs on the same computer as you are on.

Quite weird. Well, that's 1986 for you.

Also VNC works differently when it's served up from a Unix/Linux machine then what it does on Windows. Because with X windows you can have multiple X Servers you can setup VNC with a completely new and unique X Server for each user that connects. No remote control mouse thing like you get on Windows, each vnc session gets a unique desktop.

(this is what originally VNC was made for, if I remember correctly)

So when going from a X Windows served VNC to a VNC client on another PC that would mabye be a medium client? Or a think, or half-baked client? :P

Good article, though. Who wrote it?

--Drag


---November 19, 2004

I wrote it (if you don't see an author credit at the top, it's me).

I didn't want to confuse the VNC stuff on Unix - obviously VNC can be multi-user on Unix because Unix is automatically multi-user.

--TonyLawrence


---November 19, 2004

Oh.

For a long time I figured VNC was the same in Unix as it was in Windows, until I tried it and it confused the snot out of me for a little while. So that's why I mentioned it.

--Drag

---November 19, 2004

I think it's good you did - I just didn't want to get the original article all confused by it. Comments are a good place to talk about it.


--TonyLawrence







Fri Jun 24 15:18:58 2005: 704   LytleDavidSmith


VNC on Unix is very much like Terminal Services on Windows. Each user gets his own desktop.

When you use a VNC client on Windows to access Unix, it may seem like the VNC client is simply an X-Windows server that runs on Windows, but that it not the case. VNC does act as an X-Windows server, but the VNC X-Windows server actually runs on the Unix system. The VNC client then acts to remotely control the VNC X-Windows server from the Windows system.

It is very much like the example in the article where you use Terminal Services to execute a mainframe thin-client, only with VNC accessing Unix, the mainframe thin-client (VNC X-Windows server) actually runs on the mainframe (Unix server), so to speak.



Tue Oct 25 14:22:01 2005: 1241   taplintoys


I just recieved and set up an HP T5500 I won on eBay for $100 + shipping. It runs WindowsCE with Internet Explorer (OK), Media Player (buffers poorly), etc. plus an RDP terminal client and emulation of some traditional UNIX clients, which might be nice for an aging cross-platformer like me. I have not yet tested the non-RDP client apps.

WindowsCE is both impressive and underwhelming. The learning curve is near zero for anyone who knows Win98, 2K, or XP, but limited storage and features frustrate a desktop app junkie. Microsoft did pack a lot of familiar goodies into a small package. I was able to use the CE control panel to setup its IP seconds after plugging in, with almost no earlier WindowsCE experience.

I tried to play a small video off my website with the built-on Windows Media Player. The clip started and sounded OK at first, but choked ten seconds in. No biggie, I thought, except this box lacks the space to download and play locally even a tiny video. Still pictures looked great once I right-clicked the desktop (just like XP) to raise the default resolution to 1024x768 true color.

I concentrated next on using the RDP client with my test Windows Terminal Server. Worked as well as any other RDP client I've tried. The only things missing are the GUI speed necessary for most games and multimedia, sound (why?), and a current Java runtime. I am unsure why RDP gets no sound when the CE-based apps play it nicely. Maybe I'll find a software fix for that.

For kicks I also tried the original Unreal over RDP. It ran, but the response time was intolerable and again, no sound. Civilization 2 with its minimal requirements played better. All my "business" apps and Visual Studio 2003 loaded and ran via RDP without trouble, and surfing was fine - this posting is evidence of that, being written in an RDP connection.

So first impressions of the HP T5500 are:
1. Cheap, small, and silent are all selling points
2. Great work-pony if you do not need multimedia
3. Near-zero client maintenance = good kiosk box
4. Can surf even if Terminal Server is briefly down
5. No games and no multimedia. I guess I won't give
up those traditional PC capabilities willingly.

Good, not great. Big step up from a Sun Ray - which I tested thoroughly before selling off - because I can run most of my apps, including open source apps - smoothly on Server 2003. If nothing else, this HP might make a nice travel tool in any hotel room with a LAN port. Also on our porch in the summer, or later in my son's room when he's old enough to study but not old enough to be trusted with a PC.



Thu Sep 6 18:01:54 2007: 3113   Marc


Another tool worthy of consideration is NX, which is quite a bit faster than VNC and can also proxy VNC and RDP and provide some speedup.

(link)

Here's the free server for Linux:

(link)

-Marc
(link)




------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

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.

Contact us





The successful construction of all machinery depends on the perfection of the tools employed; and whoever is a master in the arts of tool-making possesses the key to the construction of all machines... The contrivance and construction of tools must therefore ever stand at the head of the industrial arts. (Charles Babbage)

What happens then? Is there a ticker tape parade and heartfelt thanks from the computer it has reached? No, my friends, there is not. The poor packet is immediately gutted, stripped of its protective layers and tossed into the hungry maw of whatever application (mail, a webserver, whatever) it belongs to. (Tony Lawrence)








This post tagged: