Terminal Services gives you strong remote administration capabilities. But before using it, carefully check out the heavy licensing requirements.

License, Please

Terminal Services gives you strong remote administration capabilities. But before using it, carefully check out the heavy licensing requirements.

• By Michael Chacon
• August 01, 2001

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.