In-Depth

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.

• By Bruce Rougeau
• July 01, 2000

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.

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.

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 www.microsoft.com/WINDOWS2000/guide/server/features/
terminalsvcs.asp. 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.

Customizations

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.

Integration

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.