Over the past 2 months I've examined solutions that are leading the trend away from traditional fat-client technology toward thin-client technology. In January, I looked at the product that started the Windows NT multiuser snowball rolling, Citrix's WinFrame, and I reviewed the Compaq DeskPro 4000N, a lean machine that typifies the network PC. In February, I explored Exodus' NTERPRISE, a multiuser-NT product that competes with WinFrame.
Both WinFrame and NTERPRISE factored heavily in the design and development of Microsoft's Windows-based Terminal Server, formerly code-named Hydra. In fact, Microsoft licensed the code contained in WinFrame and NTERPRISE to develop Terminal Server, and the company brought key developers of both products to Redmond, Washington, to help with Terminal Server's development. What is the result of this effort? You can judge for yourself, because this month I take a look at the Beta 1 release of Terminal Server and the Beta 1 release of Citrix's pICAsso, an add-on product for Terminal Server that lets Intelligent Console Architecture (ICA)-based clients access a Terminal Server system.
Terminal Server embodies Micro-soft's vision of where Windows-based terminals are heading. But Microsoft isn't the only company with imagination and binoculars. Other products are competing for a slice of the multiuser-NT market. One such product is Maxspeed's MaxStations, which offers a high-performance and low-cost multiuser-NT implementation. As you will see, Maxspeed's solution is ideal for several market segments.
Windows-based Terminal Server, Beta 1f
Not long ago, Citrix had a prototype implementation of WinFrame 1.6 running under NT Server 4.0. Citrix referred to this product as WinFrame 2.0. Unfortunately, WinFrame 2.0 never came to market, because Microsoft refused to license the code for NT 4.0 to Citrix--or to any other multiuser-NT player (i.e., Prologue and Exodus). Microsoft's move prevented any multiuser NT 4.0 products from reaching the market. But Microsoft didn't stop there. The company turned around and licensed key technology from Citrix, Prologue, and Exodus to help construct Terminal Server. Given this background, the burning questions for me were these: What will Terminal Server look like? Will it resemble WinFrame or NTERPRISE, or will Microsoft spend time and effort to give the product a whole new look and feel? My questions were easily answered. After I installed the Beta 1 release of Terminal Server, I poked around to discover that it looks and feels like WinFrame 1.6. Does this mean Terminal Server is just a repackaged version of the aborted WinFrame 2.0? The answer is no. Microsoft made some significant changes at the network layer.
Installing and Configuring Terminal Server
Installing Terminal Server is like installing NT Server 4.0. The Terminal Server CD-ROM contains an installation option for upgrading existing WinFrame 1.6 systems to Terminal Server, but I opted for a fresh install. (I figure you can trust a Beta 1 release only so far.) I had no difficulty installing Terminal Server on a 200MHz Pentium system with 64MB of memory. Best of all, Microsoft has not added new licensing steps to the product.
Next, I nosed around a little to examine Terminal Server's default configuration options. By default, Terminal Server sets up support for TCP/IP-based T-share clients, which means you can run to your nearest T-share terminal and start using Terminal Server right away. However, the specifications for Windows terminals aren't yet finalized; therefore, no T-share terminals are on the market. Fortunately, the Terminal Server CD-ROM contains a T-share client program so that you can test connectivity from desktop PCs. Because Terminal Server supports only T-share clients, you must purchase third-party add-on packages if you want support for ICA (WinFrame) or X11 clients.
Once I had Terminal Server up and running, I recorded its TCP/IP address and installed the Terminal Server T-share client program. This simple process reminded me of installing the WinFrame client. After the client program was installed, I was ready to go--or so I thought.
Subtle Changes
I soon discovered some of the underlying differences between Terminal Server and the Citrix/Exodus/Prologue products. When I started the Terminal Server Client program, the program window presented me with a list of the domains and workgroups in my network, as Screen 1 shows. Unfortunately, the workgroup I defined for Terminal Server was not on the list. However, this situation didn't deter me because I had written down the server's IP address. I just keyed the IP address into the host field, and off I went.
But I didn't get very far. As soon as the client reached into the network, its request for access was rejected with a security error. This situation was a new twist for me. In the Citrix/Exodus/Prologue products, you connect to the server and access is determined at logon time, not at connect time. Because my Terminal Server was operating in a workgroup, not a domain, I added my user password to its local user database. I went back to my client system and tried again. This time I received a logon screen.
I was taken aback by the need for prelogon authorization at first, but the more I thought about it, the more I liked this feature. Obviously, Terminal Server is meant for integration into an existing domain, and the prelogon authorization feature plays well in that environment. More security is always a good thing, right? However, it's odd to preauthorize the connection and then present a blank logon screen for further access to Terminal Server. What was the point of the preauthorization? At any rate, once I was authorized to connect to Terminal Server, I could log on to the server and access server-based applications through the client program.
| Windows-based Terminal Server, Beta 1 |
| Contact: Microsoft * 800-426-9400, Web: http://www.microsoft.com |
| Price: Undetermined at press time |
| System Requirements: 200MHz Pentium Pro, 128MB of RAM (to support 25 users), Beta version is Intel only; release version will support Alpha also. |
Behavioral Studies
I was impressed by the overall feel and performance of Terminal Server's client-server interaction. Based on my informal tests, T-share offers similar performance to ICA. (I'm currently defining more rigorous tests to prove this assumption, and I hope to have a definitive answer soon.)
Although the client-server connection performed well, the client program has some bugs. The most annoying one is that sometimes the cursor falls out of sync and takes on a life of its own. At that point, you can't access any applications on the server because you can't point and click. All you can do is bring up the Task Manager and kill the client program on the client system. I also had some occasional client-program lockups when I changed display modes on my client/server connection. But when I connected to the server using a virtual display mode that was smaller than my local display mode (I connected to the server at 640 * 480 resolution with my local display set to 800 * 600), the client interface came up with a minimal work area and enabled scroll bars, even though it had plenty of room to come up maximized. All things considered, the client program supplied with Beta 1 is a good start. Just don't bet your life on it.
The server side seemed fairly resilient. However, I found that adding software often caused the server to go through the restart cycle incorrectly. For example, when I added Internet Explorer (IE) 3.02 to the server, the server stopped responding during the shutdown process. I restarted the server manually without any complications, however.
I didn't have any problems running applications from a client (although I didn't run every conceivable business application). I did, however, run through the suite of standard NT utilities, and I installed and ran both IE 3.02 and Netscape Navigator 4.0. One fairly amusing test I ran was to use Navigator to connect to a live video broadcast server I was testing in the Windows NT Magazine Lab. Although the client connected and displayed the live broadcast, I noticed a delay of 4 seconds to 5 seconds between the realtime broadcast and the on-screen display. This test emphasizes that you shouldn't use Terminal Server (or any multiuser-NT product) for graphics-intensive or multimedia applications.
One component that clearly did not work well was Terminal Server's administrative program. Terminal Server comes with two administrative programs: one for configuring connections (as Screen 2 shows) and one for monitoring connection activity (as Screen 3 shows). Both modules look like they were lifted out of WinFrame 1.6. The configuration module worked, but the monitoring module did not. The monitoring module did not show my active connections or any other activity. In other words, the monitoring module was completely useless, at least until I added the Citrix pICAsso module.
My conclusion is that Terminal Server is Citrix WinFrame 1.6 running under NT Server 4.0 with support for ICA removed and support for T-share added. In comparison with my negative experiences with the Windows 98 and NT 5.0 beta releases, Terminal Server was a pleasure to install and work with. After all, it worked most of the time. If you take the Beta 1 release of Terminal Server for what it is--proof of concept implementation--I think you'll be pleased with what you see. I know I was.
pICAsso, Beta 1
Citrix provides pICAsso as an add-on to Terminal Server. (Citrix chose the name "pICAsso" because it has "ICA" in the middle.) The pICAsso add-on provides ICA support to Terminal Server and additional features that Microsoft does not provide in the core Terminal Server product, such as application publishing and load balancing. When you add pICAsso to Terminal Server, you end up with a product that has a very similar feature set to the WinFrame 1.7 release I reviewed last month.
Installing pICAsso was simple and very similar to installing WinFrame. It even includes the online licensing steps that Citrix added to WinFrame 1.7. The beta release of pICAsso I reviewed had two major features: ICA support and load balancing. I did not have time to test the load-balancing option, so I concentrated on the addition of ICA to Terminal Server.
After I added pICAsso to my Terminal Server system, I was surprised to find that the Terminal Server monitoring utility started working. I was able to monitor and watch my inbound connections, which I could not do before I installed pICAsso. Screen 4 shows the monitoring utility in action.
The best way I can describe pICAsso is to say that it turns Terminal Server into WinFrame 1.7 running under NT Server 4.0. With pICAsso installed, I connected to my existing ICA-based terminals (I used both Wyse and Tektronix models) with no problems. I also connected to the system from client machines running the ICA client program. (Citrix provides client software with pICAsso, but I used the client software I installed when I was testing WinFrame 1.7.) Of course, my T-share client software continued to work, too. The pICAsso product adds support for ICA; it doesn't replace T-share.
The pICAsso add-on includes additional utilities for application publishing, which lets client systems connect directly to specific applications instead of connecting to the server logon program. (For more information about application publishing, see my review of WinFrame 1.7 in "Desktop Technology Today," January 1998.)
Adding pICAsso increases the usability and robustness of Terminal Server. With pICAsso installed, all of Terminal Server's server-side administrative tools worked. I could use the Citrix tried-and-true ICA client software instead of the shaky Microsoft T-share client software, and I could access Terminal Server from my legacy ICA terminals. Until the T-share client software and T-share terminal market mature, view pICAsso as a mandatory addition to Terminal Server.
| pICAsso, Beta 1 |
| Contact: Citrix Systems * 954-267-3000 or 800-437-7503, Web: http://www.citrix.com |
| Price: Undetermined at press time |
| System Requirements: 200MHz Pentium Pro, 128MB of RAM (to support 25 users) |
MaxStations
Maxspeed has developed a unique combination of hardware and multiuser-NT software that provides the highest-performance solution for multiuser computing I've seen to date. Although Maxspeed's solution doesn't scale to hundreds of terminals, it does scale well to dozens of terminals, offering performance you have to see to believe.
Fast by Design
The Maxspeed solution, MaxStations, has three elements. The first element is IGC MultiNode, which is multiuser software for NT Server 3.51 or NT Workstation 3.51. The second element is one or more MaxStation controllers, each of which drives a set of terminals. The third element is one or more MaxStation units, which are terminal units that bring video, keyboard, and mouse capabilities to the desktop. All three elements work together to provide a high-performance environment.
IGC MultiNode is a variation of Prologue's WiNTimes and Exodus' NTERPRISE: It uses the multiuser kernel software that Prologue and Exodus pioneered. In fact, installing IGC MultiNode looks and feels like installing NTERPRISE (which I reviewed in "A Thin Client Solution for X Terminals and More," February 1998). The difference in the Maxspeed environment is that IGC MultiNode does not support connection from X11 clients (as do WiNTimes and NTERPRISE). Instead, IGC MultiNode includes support for the MaxStation controller. IGC MultiNode adds one more twist: It uses a dongle (a device that attaches to the parallel port) as its licensing control.
The second element in Maxspeed's solution, the MaxStation controller, is among the more interesting adapters I've seen. Each controller consumes a 16-bit ISA slot and provides support for two or four MaxStation terminal units. The connection between the MaxStation controller and the MaxStation units is made with CAT5 unshielded twisted pair (UTP) cables. The solution supports a connection distance of up to 200 feet or up to 500 feet (the type of MaxStation unit used determines the length of the connection). The links between the controller and the terminals are direct cable connections, a different configuration from other multiuser-NT solutions, which connect over the NT network. In fact, I don't think you need a network adapter in the IGC MultiNode host system to implement the Maxspeed solution.
However, what makes the controller interesting is not the terminal connections. What makes it interestingand what enables the Maxspeed solution to offer high performanceare the video subsystems for each terminal port on the controller. These controller-based video subsystems handle all of the display units locally (inside the host computer) and ship the results to the terminal units. This setup is different from other multiuser implementations, which ship raw video information over the network and rely on the terminal or client software to resolve and render the screen images. The Maxspeed approach is much faster than any network-based approach.
The third and final element in Maxspeed's solution is the MaxStation terminal unit. This unit looks like a network computer in that you must attach a keyboard, mouse, and VGA (or SVGA) display to it. The terminal unit includes a parallel port and a serial port for printer connections. I didn't open up a terminal unit, but I can't imagine there's much processing power inside. After all, the controller handles the video processing; all the terminal unit has to do is perform some basic I/O operations.
Maxed in the Lab
I tested the Maxspeed solution in the Lab. My test environment consisted of a 120MHz Pentium processor with 64MB of memory to serve as the IGC MultiNode host, a four-port MaxStation controller (model SGX-4), and four MaxStation terminal units (model GWX, good for connections up to 200 feet).
Installing the IGC MultiNode software was simple enough, although you must follow the steps documented in the installation guide. First, you must start with a system running NT Server 3.51 with Service Pack 5 (SP5) or NT Workstation 3.51 with SP5. I went with NT Workstation 3.51. A CD-ROM version of SP5 is included in the IGC MultiNode packaging. After installing NT and SP5, you must configure and install the MaxStation controller: Find a memory area with 8KB free and set the switches on the controller accordingly. (The controller is set for D0000-DFFFF by default.)
Next, you must install the dongle on the host system. After you've done so, install the MaxStation units (that is, plug in keyboards, mouse devices, and displays) and connect them to the MaxStation controller. I went through these steps with ease. The biggest trick for me was being conscientious and reading the installation documentation. Once I read the instructions, the installation procedure was clear.
After I installed NT Workstation 3.51 with SP5, configured my MaxStation controller for address D0000, and installed the dongle, I had one MaxStation unit fully configured and attached to the controller. Then I had to install the IGC MultiNode software. The software installation was simple. The only tricky part was making sure the software settings for the MaxStation controller matched the settings I had configured on the adapter, as Screen 5 shows. After the software was installed, I rebooted the system.
Voilà!
When NT and IGC MultiNode rebooted, I was in business. When the logon display appeared on the console, I looked over at the MaxStation monitor, and sure enough, a logon screen was there. I then installed and ran IE 4.0 and a handful of my favorite utilities. MaxStation's performance was impressive. It felt as responsive as using the console on the system.
However, the Maxspeed solution has limitations. One of the biggest limitations is that IGC MultiNode runs with NT 3.51 but not NT 4.0. If you have applications that depend on NT 4.0 or users who expect the NT 4.0 look and feel, the Maxspeed solution might not be the best choice for you.
Another limitation is that the Maxspeed controller is an ISA card, which means that the number of terminal units you can support on a given system depends on your motherboard. Maxspeed sells an expansion unit that gives you seven additional ISA slots, and you can add up to four expansion units per system to get even more ISA slots. According to Maxspeed, the maximum is 26 controllers per host, which gives you a maximum of 104 MaxStation terminal units per host. On the one hand, this capacity isn't very impressive in comparison to solutions like WinFrame, NTERPRISE, and Terminal Server. On the other hand, you get pretty impressive speed for your investment.
One final, rather annoying, limitation of the Maxspeed environment is that you must turn on a MaxStation terminal before you start the server. The terminal won't come up after the server starts. I couldn't find a way to tell the server to activate a terminal unit that was powered on after the fact. However, you can power up and power down the terminal units while the server is running, with no ill effects.
I don't see the Maxspeed solution taking over corporate America anytime soon. But I do see it as an ideal way to implement small self-contained installations. For example, the Maxspeed solution would be ideal for restaurants, small point-of-sale operations, and other businesses that have been dominated by standalone or decentralized midrange computers (e.g., VAX/VMS and AS/400) and terminals. All things considered, Maxspeed's MaxStations product is a pretty slick solution.
| MaxStations |
| Contact: Maxspeed * 650-856-8818, Web: http://www.maxspeed.com |
| Price: SGX-4 Controller $995, GWX terminal unit, $399, 5-user multinode $895 |
| System Requirements: Intel system running Windows NT Server 3.51 or NT Workstation 3.51, 6MB to 16MB of additional RAM per user |