License, Please

One of the issues surrounding the migration
process to Windows 2000 is the considerable hardware investment
frequently necessary to run the new OS. Another issue
is a long-standing problem of how to best connect small
one- or two- user satellite offices to a larger enterprise
network without adding hardware resources to the satellite
offices. On top of this is the challenge of managing the
applications on the remote machines in satellite offices.

There are several options available in Win2K
to deal with these problems, but one in particular not
mentioned much these days is Terminal Services. Terminal
Services was a very hot topic during the thin/fat client
wars a while ago, but has subsided as of late. However,
with the fat PC still gaining ground and even handheld
devices continuing to gain weight with their own bells
and whistles, the thin/fat direction is decidedly on the
high-caloric, if not downright fat, side.

While Terminal Services isn't a panacea,
it certainly has a role to play in these areas, as well
as provides a solution to a growing
number of single-purpose applications in retail, banking,
public kiosks and similar types of commercial systems.
[For more on Terminal Services read, "Progress
at the Speed of Thin" by Bruce Rougeau in July
2000 issue. —Ed.]

Flex Your Server's Muscles

Citrix initially developed Terminal Services
as an add-on service during the fat/thin client wars.
After some bickering, the core product was licensed by
Microsoft for inclusion in Windows NT. Terminal Services
takes advantage of NT's and Win2K's multitasking, multithreaded
architecture and the little-known fact that Win2K has
always had the ability to support multiple users. This
functionality was just hidden, by design, to support only
one interactive desktop at a time.

The result of this tweaking was the ability
for a client to connect and authenticate against the Win2K
Server while having all of the application execution,
data storage and data manipulation occur on the server.
Only the keystrokes and display updates pass through the
remote connections, putting the burden of performance
resources on the server instead of the clients. This makes
it possible for older machines, without the muscle to
run Win2K to run applications in that environment.

The resources necessary on the Terminal Services
server depend upon the number of clients you plan to support
and the applications that'll be available for the clients
to run. As with most things Win2K, the areas to consider
for performance are memory and processors. The size of
the Registry is another thing to consider with Terminal
Services servers—they may be supporting more desktops
than a standard machine and these, of course, are stored
in the Registry.

Obviously, the faster a CPU the better; but
this is a case where multiple CPUs play a more important
role, as the various clients will be spawning more threads
on the system than a standard file server. As with all
the performance parameters, there's no special number
that you can choose to shoot for. You'll need to run the
System Monitor against the machine to see what particular
resource is being taxed the most and determine how to
best improve performance.

Enhancing Performance

Since all code execution is on the server,
memory is going to be the most likely culprit for dramatic
performance bottlenecks. Microsoft recommends at least
128MB of RAM for the base OS and another 20MB per client
session. However, this is really arbitrary, as the amount
of memory necessary will depend entirely on what applications
the clients will be using. Once again, System Monitor
can determine how much memory the applications on a particular
Terminal Services server each client will consume.

One piece of good news is that application
code can be shared by different clients, even though they're
running different sessions. For example, if multiple clients
are trying to run Excel, only one instance will be consuming
memory on the Terminal Services server. The real rule
with memory is that you want to have enough physical memory
on the machine so that the page file is rarely ever needed
to swap out executing code. Swapping to disk will have
the biggest negative impact on performance. Therefore,
preventing this occurrence is the low-hanging fruit of
performance gain.

Eliminate Overhead

There are two modes of operation for Terminal
Services. Remote Administration mode allows administration
of Win2K servers over remote IP connections as if you
were sitting at a PC on the network. When running Terminal
Services in Remote Administration mode, only the code
necessary for the remote connection is loaded, leaving
out the code that provides the ability to share applications
remotely. This reduces the overhead on the Terminal Services
server so it can be used on internally focused services
with little performance impact. Terminal Services in Remote
Administration mode allows two concurrent connections
and requires no additional licenses, which eliminates
a great deal of administrative overhead.

The mode most often thought of when considering
Terminal Services is Application Server mode. This allows
you to deploy and manage applications for thin client
access centrally. This mode also allows the tools available
with Group Policy, applied through Active Directory, to
be used to manage these thin clients in the same manner
as local machines. This mode has significant licensing
considerations, since you're essentially setting up a
scenario that eliminates the need for a PC-based Win2K
client.

Get Your License

Microsoft is very serious about this licensing.
To protect this space, it has designed Terminal Services
to stop functioning within 90 days if it hasn't directly
verified the license for the Terminal Services servers
that you plan to use. This means that licensing becomes
a central technical issue in the deployment of Terminal
Services. Terminal Services has a unique—at least
for now—method for licensing clients, which comprises
the following interdependent components:

Microsoft Clearinghouse. This
is a database stored at Microsoft, which keeps track
of licenses that have been legitimately activated for
a company's Terminal Services deployment. Without connecting
to this database and activating Terminal Services licenses
within 90 days of installation, the Terminal Services
servers will stop accepting client connections.

License Server. This local
database keeps track of the individual licenses for
the clients that connect to the Terminal Servers on
a company's network. There are two types of these license
servers.

Figure 1. The licensing scheme
for Terminal Services is complex, to say the least.
Careful planning is needed from the start.

A domain license server is the default and
is used for maintaining separate licenses for each domain.
It also must be used for workgroup installations and Windows
NT 4.x domains. With this type, only Terminal Services
servers in that domain or workgroup can use the license
server.

The other type is an enterprise server, which
can be used for all the domains in an entire Win2K site.
This license can only be installed using the Add/Remove
Program applet and only works with Win2K domains.

Terminal Server. This is
the server that provides the services we've been discussing.
It also validates each client as it connects; if a client
doesn't have a license, it obtains one from the company's
license server.

Client Licenses. These
are the individual licenses obtained from the Terminal
Services servers. They're stored on the client devices
and presented each time it connects to the Terminal
Services servers.

Remember, you must have an activated license
for Terminal Services to run for more than the 90-day
grace period. Microsoft provides four methods to activate
the license server. The easiest method is a direct connection
to the Internet through the Terminal Services licensing
wizard, which directs you to the Microsoft Clearinghouse.
The Clearinghouse sends back a digital certificate to
the licensing server, which can use it to validate subsequent
transactions to authorize the client access licenses for
the terminal servers.

If the licensing server doesn't have a direct
Internet connection, you can use another machine with
Web access to obtain the certificate, which you can then
transfer to the license server. If for some reason your
company doesn't have an Internet connection, you can fax
your information over or call the Microsoft Customer Support
Center—there's no escape. Regardless of the method
you use to authorize your license server, you'll end up
with a unique license server ID. You can then obtain individual
Terminal Services server client licenses for individual
distribution from your normal procurement method.

As you can see, before you even think about
the technological aspects of Terminal Services, there's
a considerable amount of planning that must take place
just to determine how to deploy your licensing architecture.

This may also be a preview of how Microsoft
plans to deal with licensing for all its software in the
future, as it begins to deploy the application component
architecture at the heart of the .NET architecture.