Microsoft's Terminal Server Arrives on the Scene

ENT, Sept 10, 1998 by Garrett Michael Hayes

Based on Microsoft's standard NT Server 4.0 product, Terminal Server adds only a handful of special-purpose utilities and almost nothing in the way of a different look and feel. The added capabilities are almost entirely hidden from view. However, Terminal Server does offer some benefits not found with the standard NT platform. For instance, Terminal Server enables complex applications to become more usable across WANs, it can be used with Windows Terminal Devices, and it helps extend the life of older hardware systems on the way to obsolescence.

To put Terminal Server through its paces, we loaded the product onto three systems, using a Dell Computer Corp. (Round Rock, Texas, www.dell. com) PowerEdge 2300 workgroup server as the primary test bed. We also loaded Terminal Server onto a Hewlett-Packard Co. Kayak workstation and a Dell Optiplex workstation. Client connections were made from Pentium-class workstations running Windows NT Workstation 4.0, 486-based workstations running Microsoft Windows for Workgroups 3.11, and a Viewpoint TC Windows Terminal device running Windows CE, which was provided by Boundless Technologies Inc. (Hauppauge, N.Y., www.boundless. com).

In an installation supporting 30 to 50 clients, Terminal Server requires a fairly powerful system, such as a dual Pentium II or Pentium Pro server with at least 512 MB of RAM. Users connect to that system from a variety of other platforms by running client software and establishing a link across the network. Unlike a traditional client system in a Windows NT network, however, all application processing is actually occurring on the Terminal Server machine. Only the visual presentation is carried to the end user's desktop. Because the application processing takes place on the Terminal Server system, any application the server can run may be accessed from any platform on which a Terminal Server client can be run. For instance, a user can run 32-bit Windows applications even when operating an outdated 386 or 486 platform.

Setting Up

The basic installation of Terminal Server is almost identical to that of the plain old NT server. Only one screen is added, asking for the number of Terminal Server client connections to be supported. A few other aspects have very minor changes, such as default installation as a standalone server, and not installing Internet Information Server by default. Regular NT defaults to installing as a Primary Domain Controller, but Microsoft recommends, for two reasons, against using a Terminal Server system as a Primary or Backup Domain Controller. The first reason is that the volume of traffic on a heavily loaded Terminal Server could interfere with the appropriate responsiveness and reliability of a domain controller. Second, users are directly logged into the Terminal Server, and for security reasons you generally don't want users logged directly into your domain controller where they might be able to access or affect settings such as the password files.

Once installed, the system looks almost completely like a standard installation of Windows NT Server 4.0. The only visible differences are a default black background rather than the typical blue, and a new Start Menu option labeled "Windows NT Security." This menu choice is used to bring up the small system menu normally invoked by pressing control-alt-delete. Like the system menu in a typical NT installation, this menu allows the user to invoke the task manager, log off, change passwords, shut down the server if authorized, or lock the session. It also adds sections identifying the system as a Terminal Server and indicating the username, date and time of the current logon session.

The most significant difference we encountered in setting up Terminal Server came when we began to install some typical applications. Because a Terminal Server has multiple users running applications simultaneously on a single system, the software must be able to cope with the fact that users may require individual copies of some resources -- such as a personalized dictionary -- while needing shared copies of other items such as dynamic link libraries. Unfortunately, many applications, including Microsoft's own Office suites, were written with an assumption of "one machine, one user." Because of this, applications often write user-specific entries into the portion of the system registry intended for machine-specific information, and vice versa.

To account for this, Microsoft provides a set of post-installation scripts for 23 common applications and suites. After installing an application, such as Office 97, the administrator runs the appropriate post-installation script. The script then examines the system registry for entries in the wrong place and adjusts them accordingly. The post-installation scripts automatically use a feature called "change user," which means that the software is installed in such a fashion that different users can start from a set of common option settings, and then individualize the settings.