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.
| 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 www.wyse.com.
Hitachi America Ltd. (www.hitachi.com)
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 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.
| 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 www.microsoft.com/windows2000/
guide/server/pricing/pricingwindows.asp.
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
|
|
|
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.