Spawn of the Hydra

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.