Microsoft's Terminal Server Arrives on the Scene

• 09/10/1998

At long last, Microsoft Corp. released the highly touted Windows NT 4.0 Terminal Server Edition. Nicknamed Terminal Server, the new operating system enables a single Windows NT server to execute multiple sessions simultaneously, from a variety of platforms, and display them on a client remotely.

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, complex applications become more usable across WANs, can be used with Windows Terminal Devices and help 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 different 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, 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 an 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.

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.

Microsoft recommends installing all applications using the Add/Remove Programs tool under the Control Panel. For administrators who have done so many Office suite installations without using the Add/Remove Programs tool that blazing ahead on auto-pilot is normal practice, as it is for us, bear in mind that not following this recommendation may cause problems. After completing what seemed to be a successful Office 97 installation and running the post-installation compatibility script, we found that Outlook would not load. Re-installing according to the instructions solved the problem.

Connecting to Terminal Server from a Windows NT workstation required creating a single client installation diskette at the server, loading the software on our workstation, and defining the connection by providing the name of the server. A similar connection from a Windows for Workgroups station required creating and installing from three diskettes, but was otherwise virtually identical. Connection from the Boundless ViewPoint TC used built-in software.

Terminal Server requires that TCP/IP networking be in place for the connection between the client workstation and the system running Terminal Server. Terminal Server and the client display communicate using Remote Display Protocol (RDP), a Windows-specific set of rules for passing visual information. RDP is supported by the client software for Windows 3.x, Windows 95 and Windows NT platforms, and Windows CE, which runs Windows Terminal devices such as the Boundless ViewPoint device from which we remotely tested Terminal Server. Client connections from non-Windows platforms, such as Unix or Macintosh systems, use a separate protocol called Independent Computing Architecture (ICA), not supported in Terminal Server itself. ICA support requires the use a of a third-party product, such as MetaFrame from Citrix Systems Inc.

A client connection to Terminal Server may take on a number of different appearances once established. According to choices made when the connection is defined, the session may appear as a window within the regular environment, or it may be a full-screen session. Additionally, the session may present a normal desktop as it might be seen by a user actually seated at the Terminal Server system, or just one specific application may be run.

One unique choice presented to the user is the option to "disconnect" from a session, rather than to log out. If this option is exercised, the session remains active, with any applications continuing to run. The next time that user connects to the Terminal Server, the user will return to that session as if connected the entire time. Using this capacity, a user might start a resource-intensive application, and then disconnect the session to run independently overnight. The reconnection may be from any terminal device, and is not limited to the device from which the session was originated.

We established simultaneous multiple connections to a Terminal Server, with each session being logically separated from the others. Each user is actually executing a session on the Terminal Server itself. Depending on what each user is running, there may be a great deal of disk I/O or the like. Imagine, for instance, that 20 users are running a database application from Terminal Server. If the database resides on Terminal Server, disk I/O goes way up; if the database does not reside on Terminal Server, network I/O increases. The operating system is also handling lots of process-switching among the various users. Naturally, all these factors tend to slow performance.

In addition to enabling multiple users to run sessions, Terminal Server also enables one user to run multiple sessions. The sessions may be originated at one terminal device or from several different stations. If multiple sessions for a given user are disconnected, that user is given a list of sessions from which to choose at the next connection. In our testing, we found it incredibly useful to start a Terminal Server session with various administrative tools running, disconnect the session and then connect to it from various places as we needed to do administrative tasks.

Reconnecting to sessions was where we encountered our first serious complaint about the Terminal Server interface: the lack of any ready way to distinguish multiple sessions. Multiple sessions active at the same station are very difficult to distinguish from one another. The window headings indicate only that it is a Terminal Server session, and the name of the server being accessed. The user must rely strictly on the content of the session window to distinguish one session from another.

Similarly, we found it difficult to distinguish one disconnected session from another. Only the date and time at which the sessions were created and then disconnected provide any insight as to which session to choose. As with multiple connections from a single workstation, some sort of labeling facility would have been very useful.

We tested several Terminal Server connections, both on our own local-area network and from workstations connecting across the Internet, performing a number of typical operations both directly on the client workstation, with local applications, and using the Terminal Server connection. In both cases, the Terminal Server responses compared quite favorably with the responsiveness of local processing.

We ran the Outlook 98 client on an offsite regular NT system accessing our server, and then compared it with running Outlook from a Terminal Server connection. Establishing an Outlook session was noticeably faster using the Terminal Server connection, with most common functions being twice as fast or faster. And time-consuming functions, such as opening items with large attachments, were considerably faster.

In the LAN environment, neither Outlook nor the other Office apps showed any significant difference in behaviors. But in the WAN environment, we noticed that even an idle Terminal Server session has ongoing network traffic. The significance is that a session with any sort of screen activity will keep a TCP/IP session from timing out. For instance, a blinking cursor in Excel is enough to cause a tiny screen update to be sent over and over, thus consuming network bandwidth.

Terminal Server does not directly support load balancing or communications among multiple servers. However, administrators can accomplish rudimentary forms of both load balancing and high-availability by configuring multiple servers in the same network. In our tests, we installed Terminal Server onto three systems, configured them all as close to identically as possible, and then set up our DNS server to give out each of the three IP addresses in turn to subsequent queries. This round-robin approach allowed us to spread a load across the three servers.

However, this again brought up a limitation of the otherwise clean user interface. As we had discovered in the case of multiple sessions, there was no ready way to distinguish which server we had connected to. Having access to this information was important if we wanted to be able to disconnect a session and later reconnect to that same session.

The level of effort to maintain a Terminal Server installation should be comparable to or slightly less than that of maintaining a similar installation using NT Workstations. The initial phases of properly setting up the server and implementing applications take a bit longer and require somewhat more careful planning. However, this is offset in the longer term by the obvious benefits of centralized management, combined with the ability to rapidly replace such things as a damaged Windows Terminal without need for extensive reconfiguration.

The only area that could require significantly more effort is in maintaining Terminal Server as a solution in a high-availability environment. There, keeping several Terminal Servers synchronized with the same versions of software and compatible settings may take some effort. This would be especially true in keeping consistent implementation in a round-robin setup such as the one we experimented with.

In our testing, using Windows NT Server 4.0 Terminal Server Edition was almost a non-event. The majority of the installation and configuration tasks were so similar to those of a standard NT setup that our most recurring problem was complacency when we entered those few areas where there was a difference -- such as installing all software through the Control Panel.

The lure of the product is not simply to enable the use of inexpensive network computers (NC). Quite the contrary, unless a given NC can support either the RPC or ICA protocol, it won't even work with Terminal Server. Instead, Terminal Server will find a home by breathing new life into old hardware assets that may have been slated for the junk heap. It also will enable organizations to buy inexpensive, relatively low-powered PCs as desktop systems, with confidence that those devices will have a reasonable life expectancy, and should find use for those employees dialing in and launching bandwidth-intensive applications.

Windows NT 4.0 Terminal Server Edition
Microsoft Corp.
Redmond, Wash.
(425) 882-8080
www.microsoft.com
Pricing: server product license, $627; single workstation license, $238; Client Access License, $31.
+ Extends usable life of legacy hardware and software.
+ Complex applications become more usable across slower wide-area networks.
+ With Windows Terminal Devices, helps deploy standard applications into harsh or specialized environments where standard PCs might not be appropriate.
- Requires careful planning for software installation, to assure proper multiuser support.
- Custom or third-party applications may need to be modified to support multiple, simultaneous users.
- Lacks support for local devices.