Progress at the Speed of Thin

Terminal Services offers a way to move your clients to Windows 2000--and other new applications--without messing with hardware or OS upgrades.

Microsoft’s vision statement up until a few months ago was something like this: “A computer on every desk and in every home running Microsoft software.” During the past year, Microsoft reinvented itself and came up with a new, broader mission: “To empower people through great software any time, any place, on any device.” It seems as though we have a new digital device every month; getting data on our traditional desktop only seems so old-fashioned. We would never imagine running Windows 2000 on our Palm, but it’s reasonable to want electronic information everywhere. Since Microsoft has always excelled at providing an integrated offering, it’s logical that the company has integrated thin-client computing into the base server offering of its newest, greatest OS.

When Microsoft released Win2K, it included Terminal Services as stock equipment on the Server, Advanced Server, and Data Center versions. This is wonderful news to all of the people who want to provide thin-client solutions without having to purchase an OS outside the mainstream.

For a briefing on thin client products, see "Getting Lean and Mean: Windows 2000-Ready Thin Clients," in this issue.

A Definition

The core of thin-client computing is a multi-user operating system. That’s because, contrary to traditional PC solutions, in a multi-user environment multiple users run on one system sharing the same CPU and memory. The next component is a client device. Typically, this is a PC; however, it can be as small as a tablet device. The third piece is a protocol that transports keystrokes and mouse movements from the client to the server and then sends the screen updates from the server to the client.

In the Win2K combination, the multi-user OS is Win2K Server, Advanced Server, or Data Center. The client can be any Windows networking OS including Windows CE. With third-party software, the client can also include Unix, DOS, and Windows 3.1 for heterogeneous environments.

The protocol Microsoft provides is Remote Desktop Protocol (RDP). RDP uses TCP/IP for the Transport and Networking layers. How does this change the current work environment? In a traditional solution at work, Microsoft Word would be running on 100 different desktops, consuming memory and a CPU on 100 computers. In the thin-client solution, Microsoft Word runs on one computer; 100 clients function as terminals. The clients require a minimal amount of CPU and memory, thus the name “thin-client computing.”

A Taste of the Experience

The release of Win2K doesn’t mean we can all immediately run the new OS on each of our desktops. Maybe you lack the hardware; maybe you need more time or resources. But how about using Terminal Services to accelerate deployment of Win2K desktops and applications? The creative among us could have a Win2K server with Terminal Services enabled and allow down-level clients to experience Win2K technology today. Another option: Provide Microsoft Office 2000 on the Terminal Server, thus allowing users to access this new software with just 16M of memory on their PCs.

The terminal server client can connect to a complete desktop—or complement its own desktop—by simply launching a server-hosted application. It’s possible for a terminal server client to have multiple terminal server sessions at the same time, all accessing a different server for a different application.

How It Works

A key component of the multi-user OS is the session object. It’s critical to segregate one session’s processes, memory allocation, and security clearance from another session. When a user logs off, all resources allocated by the session must be released. One that’s different from the others is called the console session; it actually uses the drivers on the server for keyboard, mouse, sound, and video. All other sessions direct their I/O requests over the network where the clients’ drivers will be used. An idle session is one looking for a job—it hasn’t been associated with a specific user, and its purpose is to speed up the log-in process.

Figure 1. The fundamentals of Terminal Services operations.

In the traditional PC world, multiple copies of applications don’t run at the same time on one system. (OK, we may have serious Solitaire players who have multiple games all going on at once.) Is there any significant benefit to having a hundred copies of Microsoft Word (or the application of your choice) all running concurrently on your terminal server? Interestingly enough, the answer is yes. Your mother always said that sharing was a good thing. Running a hundred copies of a program doesn’t require 100 times the amount of memory of a single instance of that program. And this isn’t unique to Terminal Services. Windows NT uses the memory management scheme Copy on Write, which allows two processes to share the same page of memory. If one process needs to make a change to the page of memory, it wouldn’t be appropriate that both processes see the change. In this event, the memory manager creates (copies) an extra memory allocation for the process making the change. This is convenient when you run a second copy of Word, because you don’t have to load two copies of the DLLs and executables.

Most Improved

Microsoft has spent much effort in making Terminal Services for Win2K an excellent offering. Let’s look at the features.

Total Integration
Remember how we’d see a new service pack for Windows NT, then have to wait for the Terminal Server Edition version? This problem is a thing of the past. Great news—Terminal Services is part of the base Win2K Server offering. This means it won’t be treated as “an exception.” When a service pack or hotfix is released for Win2K, no more waiting for the Terminal Services version; we’ll already have it.

Application installation is more integrated with Add/Remove Programs. In previous versions of Terminal Server, the installer of an application had to remember to put the system in Application Install Mode. If the mode wasn’t changed, the application might not work for other users. (More on this shortly.) This shift is now automatic in the Win2K version. If a user tries to run a setup program, he or she will be forced to use the Add/Remove Programs routine from Control Panel.

Windows-based Terminals
Client devices running under a terminal server can have as little horsepower as a 386 processor and 8M of memory. Several vendors have embraced this vision and built a complete line of Windows-based terminals with no moving parts. When a new version of Windows ships, these machines don’t have to be replaced.

Wyse Technology, Inc. offers a wide selection of Windows-based terminals for the desktop and office environment. Learn more at

Hitachi America Ltd. ( has a new line of tablet computers named “ePlate,” which run Windows CE as the client OS and make great Terminal Services clients. The Windows CE client also has handwriting recognition, which means that you don’t use the keyboard to enter information. It’s nice to have a tablet computer with a PCMCIA wireless network card communicating (with no keyboard!) with your terminal server. It’s like defying the law of gravity. People look at the tablet screen and wonder how you’re running Win2K on a device without a hard drive or keyboard. The current model is designed for indoor use and retails for about $1,200. A new version will be released this summer for outdoor use. A current market for this technology is the medical field. Doctors use the ePlate today for accessing medical information.

Keep your eyes on these Windows-based Terminals. Next thing you know, you’ll see them mounted on golf carts with antennas throughout the golf course for those users who want to perform day-trading while enjoying an afternoon of sun.

—Bruce Rougeau

On a third integration front, Terminal Services offers a tighter union with the client. When a client connects to a terminal server session, the client’s printers and Clipboard get mapped to it. This is convenient, because it gives the user immediate access to locally defined printers. Clipboard synchronization enables a user to copy an object within the terminal server session and paste it in the client OS. Users expect these sorts of integration options, which Microsoft provides through virtual channel support. This means that the client’s defined printer doesn’t have to be shared in order to have access on the terminal server. You could even say Virtual Channel Support is magical—the terminal server accesses resources on the client even though those resources aren’t shared.

Better Server Performance
On the same hardware, Win2K Server Terminal Services can serve more users than Terminal Server Edition. NEC recently published a white paper, “Windows 2000 Terminal Services Capacity and Scaling,” which you can find at
. This article is based on Release Candidates 2 and 3. One test result worth noting is that on a four-way system, NT 4.0 Terminal Server Edition accommodated 95 knowledge workers doing their jobs, whereas Win2K satisfied 120 users. That’s right: 25 more users on the same hardware by changing to Win2K.

Two Modes of Operation
Terminal Services offers two modes of operation: Remote Administration and Application Server.

The former has got to be one of the coolest features of Terminal Services. Remote Administration lets you perform tasks from anywhere as though you’re sitting at the console. As the admin, you can access the console from anywhere in the enterprise, or even at home, via dial-up (or through the Internet on non-Win2K operating systems). Every one of your servers should be set up for remote administration. While in this mode, only administrators can access Terminal Services. Terminal Server Client Access Licensing (TSCAL) isn’t enforced; only two sessions are supported, and there are no idle sessions, which minimizes overhead for this service. Since you’re not providing sessions to the user community, there’s no install mode while the server is configured for Remote Admin. This means you can’t use Remote Administration mode to deploy applications out to the masses from your server.

Application Server mode is designed for the typical thin-client environment in which you want to let users access the applications on the server. Client Access Licensing is enforced and idle sessions are created to speed up the log-in time for a user. If you wanted to make Microsoft Office available to your company, you’d need to put the server in Application Server mode (Figure 2).

Figure 2. The two modes of Terminal Services installation: Remote Administration and Application Server.

RDP 5.0
Remote Deployment Protocol (RDP) has improved performance for quicker screen updates. RDP conserves bandwidth by providing compression and persistent client-side bitmap caching. Screen data is compressible, requiring little overhead. The screen updates include bitmaps and can be cached on the client to avoid sending the entire bitmap each time.

Remote Control
When you think about Terminal Services accepting and sending all screen, keyboard, and mouse I/O over the network, you proably wonder whether that means you have all the building blocks to take remote control of another user’s session. This functionality is new in the Win2K offering—and truly handy for help desk people. Having trouble understanding users’ complaints by phone? Take remote control of their sessions to see what they see and take control of their keyboards. In order to accomplish this, both users must have terminal server sessions. The controlling session (the one taking control of the other) must launch Terminal Services Manager and take control of a session. (See Figure 3.)

Figure 3. Connections configuration for Remote Control.

You’ll need to remember several rules, however:

  • The console session can’t be remote-controlled, nor can it take remote control of another session.
  • No one can control the console session.
  • Both sessions must be run under RDP.
  • The controlling session must have a screen resolution greater or equal to the controlled session.
  • The controlling session must have a color depth greater or equal to the controlled session.
  • Only administrators can take remote control of a user session by default.

Installation Matters

If you’re doing planning for Win2K, the decision to install Terminal Services should be made up front. (Yes, you can add it later; it just takes more work.) To install Terminal Services, choose Control Panel | Add/Remove Programs | Add/Remove Windows Components | Terminal Services. After pressing Next, you’ll have the option to specify whether this server will be in Remote Application Mode or Application Server mode. If you choose Application Server mode, you’ll need to uninstall all applications before installing Terminal Services, then reinstall them after Terminal Services is functional.

After you select the mode, the Windows Components wizard asks how to set the registry permissions (Figure 4). The first option, “Permissions compatible with Windows 2000 Users,” makes the system more secure. The second option, “Permissions compatible with Terminal Server 4.0 Users,” is for backward compatibility. Some legacy applications may need to change a registry value in Win2K that requires a power user or administrator to modify. In order to let Win2K make your systems more secure, I advise you to select the first option. The more secure registry prevents anyone other than administrators from installing applications. [For more on Terminal Services security, see Roberta Bragg’s “Security Advisor” in this issue.—Ed.]

Figure 4. Defining application permissions during the Terminal Services installation.

If you have applications installed on the server when selecting Application Server mode, the system will complain. You’ll get a friendly dialog listing the applications and a message warning that they may not work properly. Heed the warning!

When the Terminal Services are installed, you’ll have to reboot your system. Yes, this is one of the few times that you need to shut down and start up Win2K after installing a new service. Why? We’re now switching to multi-user mode—we’re changing the core of the OS from single user to multi-user; serious enough for the system to take a new picture of itself.

Of course, at some point you may decide to uninstall Terminal Services. Before doing so, you should remove all applications, remove the service, reboot, and then reinstall the applications. Because several changes are performed in the registry, this is the recommended route.

Application Matters

Today, applications work better with terminal servers than ever before; however, you’re bound to come across some hiccups. Programmers in the past rarely took into account a multi-user operating system (or multiple people using the same PC) in their application design. This led to problems like improper use of HKEYLocalMachine, over-use of the CPU, and identifying the user by IP address or machine or NETBIOS name.

Take the problem with HKEYLocal Machine. This is where global values get stored. If an application stores user-dependent values in HKLM, another user can come in and overlay those values; the last one in wins.

Another common problem occurs when the install program writes values to the HKEYCurrentUser (HKCU). When the program runs, it looks for values in HKCU (placed there by the install program); if they’re not there, the program doesn’t work properly. In this scenario, the installed application works for the person who installed it, but not for anybody else. The new Win2K logo guidelines require programmers to become more aware of the issues of a multi-user environment. However, they don’t make compliance mandatory. Also, it’ll be awhile before the applications we’re running today have Win2K logo compliance. That said, a year ago third-party programmers treated Terminal Server as another OS; they’d get their Windows 95, 98, and NT versions out the door, and other releases would wait for another day. Now we’re bound to see improvements on this front if programmers want that logo.

Terminal Services Licensing
You might think that because Terminal Services is part of the core Windows 2000 Server operating system, the only thing you need to buy is a Win2K Server license. Not true. On a typical Windows NT Server installation, was it enough to pay for the server license and client OS license? Before Windows NT 3.5 it was enough; however, since then Microsoft has implemented its Client Access Licenses (CALs). The concept of a CAL is that the users benefitting from the server should pay their way—and, by the way, this isn’t unique to Microsoft. In other words, the price of the server is based on the value brought to your company, based on the number of users who benefit.

In order to implement Terminal Services you must have the following licenses:

  • Win2K Server (you can substitute Advanced or Data Center).
  • Win2K Server Access license (this is because the client uses files on the server).
  • Win2K Professional on the client or a Win2K Terminal Services CAL.

You can find the various price tags at

Once you have a slightly better understanding about what licenses are required, you can look at the steps and components you need to configure Terminal Server Licensing.

The first thing to do is activate the Terminal Services License Server (TSLS). Microsoft calls this phase one. You perform this on a domain controller on which Terminal Services Licensing service is installed. The process of activating the TSLS registers it with the Microsoft Certificate Authority and License Clearinghouse (MCALC). There are various ways to register your TSLS with the MCALC: over the Internet, via the Web, by fax or phone call. As a result of your TSLS being registered, you’ll get a License Server ID, a 35-character string issued by the MCALC. Phase two is to enter in the client license pack ID, which authorizes this TSLS to administer the licenses purchased. Phase two can be repeated as many times as needed.

When a client initiates a Terminal Services session, the terminal server goes out and finds a TSLS. If it fails to do so, it will have a 90-day license server grace period. If the terminal server doesn’t find a TSLS within 90 days, it stops issuing temporary licenses and those clients won’t be able to run Terminal Services sessions. If the TSLC doesn’t have an available Terminal Services CAL, a temporary license will be issued and is good for 90 days. If the client is a Win2K OS, then it doesn’t need a Terminal Services CAL. Terminal Server Licensing services doesn’t talk to any other licensing manager including Windows NT 4.0 Terminal Server Edition.

Also, if you use third-party software (such as Citrix MetaFrame) installed on top of Terminal Services, it doesn’t remove the Microsoft licensing requirements even though it has additional licenses. The third-party licenses are in addition to Microsoft’s. Ouch!

—Bruce Rougeau


Sometimes applications have behavior that works well on a fat client but doesn’t work as well on a thin-client solution due to resource consumption like bandwidth. Microsoft Office is a perfect example. Its Office assistants are cute, but all the moving, bouncing, and eye contact isn’t really necessary and requires processor cycles. To eliminate extraneous activity in Office, Microsoft has made a transform file, termsrvr.mst, available in its Office 2000 Resource Kit. As a matter of fact, you can’t install Office without it on a terminal server. The command to install Office 2000 on Terminal Server Edition or Terminal Services after installing the Office 2000 Resource Kit would be:

setup.exe TRANSFORMS=”D:\Program Files\ORKTools\ToolBox\Tools\Terminal Server Tools\Termsrvr.mst” /qn+

The location d:\Program Files is where we’ve installed the Resource Kit in this example. Look for other applications to provide the same type of solution.


To install Office on your Terminal Server and make it available to several users, the Terminal Server must be in Application Server mode and Install mode. This is done automatically when using the Add/Remove Program routine. Remote Administration mode doesn’t support Application Install mode. The latter can best be described as a video camera watching everything we do while installing an application, in case we need to know this for another user later. During Application Install mode, new registry entries are shadowed in HKEY_Local_Machine\
Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install. If the setup program queries for the Windows directory, it returns %systemroot%, where all .ini files will be installed.

After installing an application, the system will be put back into Application Execute mode. During the Execute mode, if our application asks for a registry value that doesn’t exist, the “camera” will look in the area used during Install mode. If the value is found, it will be added to the registry and returned to our program. Each user has a Windows folder in his or her Home directory where the .ini files are stored. When a user logs on, the system checks the system directory for .ini files newer than the ones in the user’s Windows directory. If newer .ini files are found, they’re merged with the user’s .ini files.

Think Smart, Think Thin

Terminal Services is a wonderful solution if it meets your needs. Of course, I wouldn’t advise you to force it on everyone. If your application sucks up CPU cycles, requires intense graphics, or needs more than 256 colors, then it’s probably not for you. Just remember that a terminal server can be your total solution, or it can let you add applications to your existing desktop environment.

The way I see it, you can spend your money to provide high-end workstations on desktops and try to keep them current. Or you can put your IT investments in your servers and provide thin clients on the desktop.

comments powered by Disqus
Most   Popular