In March 1998, the Windows NT Magazine Lab reviewed Windows NT Server 4.0, Terminal Server Edition, beta 1; Citrix Systems' MetaFrame, beta 1 (then named pICAsso after Citrix's Independent Computing Architecture—ICA—protocol); and Maxspeed's MaxStations (see John Enck, "Spawn of the Hydra," March 1998). Terminal Server and MetaFrame (a Terminal Server add-on) shipped in 1998, and since the article, many companies have implemented one or both products to create a multiuser NT environment. Thus, the Lab is ready to revisit the thin-client review.
Windows NT Server 4.0, Terminal Server Edition
The most obvious difference between Terminal Server and MetaFrame is the products' display protocols. A display protocol is a data-link layer protocol that transfers a client's input to a server for interpretation and transfers the server application's output to the client for display. Not all display protocols are equal. If you've read anything about multiuser NT during the past year, you know that ICA currently has capabilities that the original version of Terminal Server's RDP doesn't have. RDP doesn't support playing audio files, copying between local and remote applications, printing from local printers, or running protocols other than TCP/IP. ICA supports all these types of functionality. Terminal Server's Service Pack 4 (SP4) and Windows 2000 (Win2K) will add some of these features to RDP. (For more information about these upgrades and about how RDP and ICA differ, see "Terminal Server Grows Up," page 103.) At press time, RDP lacks some of ICA's functionality, but RDP is adequate for Win32 clients that don't need sound.
Installation and Configuration
Installing Terminal Server is similar to installing the standard NT Server 4.0 OS. The Terminal Server CD-ROM includes an option for upgrading an existing NT Server installation to Terminal Server. The Terminal Server version of SP3 installs with the OS. However, although Microsoft released NT 4.0 SP4 in December 1998, SP4 for Terminal Server (which has a different kernel from standard NT 4.0) isn't available at press time. Microsoft said Terminal Server's SP4 would be available in first quarter 1999. By default, Terminal Server installs as a member server, not a domain controller. This default option is beneficial because it helps ensure that user authentications don't overburden your Terminal Server system, which must serve client terminal requests. If you can install NT, installing Terminal Server is a cinch.
After I installed Terminal Server, I was ready to play with the OS. I rolled out Terminal Server's Client Creator tool and prepared to install the Terminal Server client on my network's workstations. You can create a client installation disk on your Terminal Server system, then install the Terminal Server client on user workstations from the installation disk. Or you can place the installation software on a shared drive. Terminal Server's client software resides in Terminal Server systems' \%system-root%\system32\clients\ tsclient\win32\disks\disk1 directory. Make this directory a shared directory, and users with appropriate permission sets (including members of the domain Users group) can connect to the share and run the Terminal Server client's Setup program.
After you distribute the files to your Terminal Server clients, setting up the client software to find the Terminal Server system is simple. (Wonder of wonders, you don't have to reboot workstations after installing the Terminal Server client.) The only part of client configuration that is confusing is a licensing screen that warns you that you must have an NT Workstation license to run the Terminal Server client. Microsoft created this window before it changed Terminal Server's licensing rules. On February 1, Microsoft began offering three kinds of Terminal Server client licenses: a Terminal Server Client Access License (CAL) for office connections to a Terminal Server system, an Internet Connector (IC) license for anonymous Internet connections to a Terminal Server system, and a work-at-home license for users with a valid Terminal Server CAL to connect to a Terminal Server system via RAS.
The simplest way to start a Terminal Server session is to open the client software and choose the server you want to connect to, as Screen 1, page 152, shows. If you don't see your server in the client's list of available Terminal Server systems, you can type the server's IP address or name in the Server drop-down list to connect to it.
You can also start a Terminal Server session by creating a custom connection in Client Connection Manager on a Terminal Server client. This option gives you more control over your session's settings, and it creates a connection entry in the Terminal Server client program group and Client Connection Manager that you can reuse. You can even create two Client Connection Manager entries to one server if you want to use different connection settings for different Terminal Server sessions on the same server. You can configure automatic user logons in Client Connection Manager, or you can let users log on each time they connect to a Terminal Server system. Users must log on to every Terminal Server session they open, regardless of whether they are already logged on to their NT domain or workgroup.
User Administration
Terminal Server comes with a couple of tools that let you keep tabs on your network's Terminal Server sessions. (For information about command-line alternatives to these GUIs, see Mark Minasi, "9 Undocumented Terminal Server Commands," page 76.)
Terminal Server's User Manager for Domains application has user account properties that NT's User Manager utilities don't include. You access these extra properties by clicking the Config button on an account's User Properties sheet. These Terminal Server-specific properties, which Screen 2 shows, let you determine whether the user account can connect to your network's Terminal Server systems (by default, all accounts can use Terminal Server), how Terminal Server handles connection timeouts, and whether network connections are persistent. The User Configuration property sheet also lets you configure session shadowing settings, but these settings aren't available unless you are running MetaFrame. (Terminal Server doesn't disable this option by default; the option's availability might confuse Terminal Server administrators who don't know that the current version of Terminal Server doesn't support shadowing without MetaFrame.)
You manage Terminal Server connections with the Terminal Server Administration tool, which Screen 3 shows. Terminal Server Administration lets you view all current sessions, send messages to a particular session, disconnect sessions, and choose sessions to shadow (if you're running MetaFrame). The utility lists all processes running in each session.
The last Terminal Server administration tool is Terminal Server License Manager. License Manager shows you how many of your Terminal Server system's client licenses are in use and which computers are using them. However, although License Manager tells you how many licenses are in use, it can't help you shut down idle sessions. License Manager lists sessions by machine name, but Terminal Server identifies sessions by username, so you need the username to shut down a session. Another License Manager limitation is that it monitors only Terminal Server licenses; it can't keep track of licenses for applications that run on your Terminal Server system.
Applying Yourself
After I set up my Terminal Server system's connections and applications, I found that the Terminal Server user experience is generally good. In my tests, business applications such as Microsoft Office performed impressively. These programs worked almost as well from a Terminal Server session as they did locally. The Terminal Server sessions were even a little faster in some cases than my desktop; for example, the splash screens on my 66MHz 486DX client (which has 32MB of RAM) displayed more quickly via Terminal Server than they did when I ran the applications locally. Even PowerPoint presentations ran well in my Terminal Server tests. However, I didn't like scrolling through Microsoft Word documents in my Terminal Server sessions. The documents scroll more quickly and more jerkily via Terminal Server than they do when the application's running locally. I suppose that with practice I could get used to this movement, but I don't like it.
You'll probably have to tweak some of your applications to get them to work in a multiuser environment. Not every application works on Terminal Server systems, and you must reinstall some applications for each user before the applications will work with Terminal Server. This incompatibility isn't exactly a fault of Terminal Server. The applications' designers just didn't develop them for a multiuser environment. Getting around these incompatibilities requires some tinkering at the server end. (For more information about problem applications, see "Can a Hybrid Network Work for Your Enterprise?" October 1998.)
You need MetaFrame to publish individual applications on Terminal Server systems. But you can create Terminal Server Client Connection Manager entries to start sessions that run only one application and terminate when the user closes the application.
The Terminal Server experience isn't visually seamless for end users. When I've asked prospective users what they want most from a Terminal Server client interface, they've told me that they don't want to have to think about whether an application is on their local hard disk or on the Terminal Server system. (Most Terminal Server clients are PCs, not Windows-based terminals or network computers—NCs—so they can store applications locally.) Terminal Server, in its native state, doesn't offer users this transparent access to applications, mostly because Terminal Server sessions display in a window on the client. If users don't maximize a session, they see the session in a window that is smaller than their screen size. If users maximize a session and run it at the same resolution as their client's local display, the window is bigger than their screen, so they have to scroll up to access the application's menus and scroll down to access the Start menu. The only way to achieve a seamless Terminal Server desktop without using MetaFrame is to run the Terminal Server session in full-screen mode, which you set from the client connection's Properties dialog box within Client Connection Manager. However, when you use full-screen mode, you can access local applications only by using Ctrl+Alt+Break to toggle between the Terminal Server session and the local desktop. These problems aren't insurmountable, but they're inconvenient for users.
Error! Error, Will Robinson!
Overall, Terminal Server is a good product that does what Microsoft says it does. Client sessions run reasonably well, and connecting a client to a server is easy. However, the OS's error handling isn't good. If a Terminal Server client's connection attempt runs into a problem, the connection ends without identifying the problem (unless a message such as Error code 0x904 counts as identification). Because Microsoft designed Terminal Server to reduce administrative costs, the company ought to provide error handling that doesn't require hands-on assistance from experienced Terminal Server administrators.
Similarly, the error messages I received when I ran into problems adding vendor-supplied network support drivers to a Terminal Server system were uninformative. The messages told me only that Terminal Server couldn't copy a particular .dll file, without offering information about where I could find the problem file. (I later found out that I needed to point the network setup program to both the installation CD-ROM and the folder in which I'd stored the drivers.) The problem isn't earth-shattering, but it's annoying.
The Verdict
Terminal Server is a somewhat limited but very serviceable way of making an NT desktop available to Win32 and Windows for Workgroups (WFW) clients. Making applications accessible to users through Terminal Server is easy. Terminal Server applications run pretty well on the client end. Although the administrative tools are limited, they perform as advertised. And Terminal Server's price is right. If you're running a network with only Win32, Windows CE, or other potential RDP clients, Terminal Server is a cost-effective method of making applications centrally available and taking up few client resources.
| Windows NT Server 4.0, Terminal Server Edition |
|
Contact: Microsoft * 425-882-8080 or 800-426-9400 Web: http://www.microsoft.com Price: $1299 for one Terminal Server server license, five Terminal Server client licenses, and five Windows NT Server 4.0 client licenses $9999 for one Internet Connector license $32 to $34 per user for work-at-home licenses System Requirements: Server: Pentium processor or better, 32MB of RAM, plus 4MB to 8MB of RAM for each user session, 175MB of hard disk space, VGA or better video, CD-ROM drive, TCP/IP network protocol, One or more NICs, Client: Windows-based terminal with RDP support or PC with 386 processor or better, Windows for Workgroups or later OS, 4MB of RAM, 4MB of hard disk space, TCP/IP network connection, RDP client |
MetaFrame 1.0
Citrix Systems released MetaFrame 1.0 in July 1998. Because MetaFrame adds ICA support to Terminal Server systems, the product lets Terminal Server machines support sound, print to local printers, publish individual applications instead of entire desktops, and support non-Win32 clients. You can use Citrix's Load Balancing Services add-on to set up two or more MetaFrame systems to act in tandem, so that the most available server handles session requests.
Load 'er Up!
After a bit of a rocky start, I liked MetaFrame 1.0. A buggy initial installation had me pulling my hair out. The installation caused sessions to stop responding and client connections to time out. Even server-based tools timed out for display. As I attempted to track down the problem, Kurt Moody, technical marketing manager for MetaFrame, offered me a tip: Install applications you want to run in MetaFrame after you install MetaFrame. I started the MetaFrame installation over, and reinstalling the server and client software cleaned up the problems. (For the record, I have no reason to believe that my installation problems were anything but a fluke.)
Because I had to install the software twice, I was glad that the MetaFrame setup is simple. I installed MetaFrame on a 350MHz Pentium II system with a 40X CD-ROM drive that was already running Terminal Server. The whole process took me less than 20 minutes and required only one reboot. The only complicated part of the MetaFrame installation is the activation of the license packs. If you want to run ICA clients, you must activate MetaFrame client licenses. You can use the software without activating client licenses, but your server will stop responding in 35 days. Screen 4 shows the Citrix License Activation Wizard, in which you choose a method for activating the licenses. Run the wizard, or go to the Citrix Web site at http://www.citrix.com/activate to activate your MetaFrame license.
Installing the MetaFrame client software is similar to installing the Terminal Server client. Like Terminal Server, MetaFrame requires you to copy files to the client. You can create client installation disks, or you can make the MetaFrame client available on a shared drive. You use MetaFrame's ICA Client Creator tool to make client installation disks for Win32, Win16, or DOS clients. I used ICA Client Creator to make Win32 disks. (The Windows clients require two MetaFrame installation disks; the DOS client requires one.) The MetaFrame CD-ROM doesn't include software for all possible clients, but you can download MetaFrame clients for OSs that the CD-ROM doesn't support (e.g., Macintosh, UNIX) from the Citrix Web site (http://download.citrix.com). To let users install the client files from the network, share your MetaFrame server's \%systemroot%\system32\clients\ica directory with the network. Then, users can choose the folder that contains the client setup files for their OS and run the setup.exe file in the \disks\disk1 folder within that shared client folder. You don't have to reboot after you install the client. The only major difference between the Terminal Server and MetaFrame client installations is that the MetaFrame client setup program doesn't have an uninstall feature—a deficiency that came to my attention when I was fixing the buggy installation. (You can use Control Panel's Add/Remove Programs applet to remove the MetaFrame client.)
After you install the client, MetaFrame prompts you to create a connection entry. The session setup wizard's connection options are easy to follow. However, the wizard's Browse button appears to let you search for applications you want to run on the MetaFrame server. If you click Browse, you end up in your local ICA client's directory, and the only applications on the Terminal Server system that you can reach are applications in a shared directory. (When I pointed this problem out to Citrix representatives, they told me that the Browse button is an error.) Other than the Browse button, the only aspects of the wizard that I don't like are that it doesn't prompt you to choose a display mode unless you choose not to accept the default settings, and 640 X 480 is the default screen size. I doubt that most users run applications at that resolution.
MetaFrame's client setup provides pop-up Help tips that are helpful for users attempting to set up session connections. Thin-client computing is all about reducing user-desktop support, and letting users set up their sessions probably sounds like a good idea. However, despite the Help tips and fairly clear steps, some of MetaFrame's client setup options will likely lead users to call the Help desk.
User Experience
For the most part, my experience on the client side of MetaFrame was excellent. The system's responsiveness was roughly equivalent to the Terminal Server client's responsiveness, but with one major difference: MetaFrame sessions tie in to the local interface better than Terminal Server sessions do. Published MetaFrame applications appear in a window and minimize to the taskbar, just like local applications. Desktop sessions have their own taskbar, but their display doesn't require scroll bars. You can see the entire MetaFrame client desktop at once. After spending time navigating an application in Terminal Server and confusing the display's scroll bars, I was happy to use MetaFrame. Like Terminal Server programs, MetaFrame applications don't seem to run as quickly via terminal sessions as they do locally, but the difference isn't large enough to make most users uncomfortable. MetaFrame's addition of sound to the thin-client desktop is nice, although the sound is a bit choppy.
The only trouble I had with the ICA client was a direct result of its stability—I got cocky and shadowed (i.e., remotely controlled) a Terminal Server session from within another session. Shadowing from a session doesn't work very well; the cursor wanders across the screen. But the client recovered beautifully after I shut off the shadowing, and my experiment had no lasting repercussions. From now on, I'll shadow only from the Terminal Server system.
Serverside Administration
In contrast to Terminal Server's minimalist approach to server administration, MetaFrame has enough settings and monitoring tools to keep the most proactive administrator happy. You can use these tools to publish applications and to make published applications available to ICA-client users.
Citrix's licensing tool displays the applications that are available to the network. The only catch is that inactivated licenses don't display use, and Citrix didn't provide an activation key for this product review, so I wasn't able to test the licensing tool. The MetaFrame Administration tool, which Screen 5 shows, displays MetaFrame clients' installed protocols and shows current connection information. The tool also enables shadowing.
Finding MetaFrame's administration tools can be tricky. The icons that appear on a toolbar on the server desktop after user installation aren't self-explanatory, and MetaFrame's tool tips show up only when you don't have any applications open. Opening the Citrix program group, which names icons, is easier than trying to figure out which tool is which from the icons' tiny pictures. However, after you find the tools, they're simple to use. I was publishing applications 5 minutes after installing them on my MetaFrame system, and I used MetaFrame Administration to troubleshoot the connection problems I experienced with my first MetaFrame installation.
I agree with John Enck's assessment of pICAsso in March 1998: Adding MetaFrame increases Terminal Server's usability and robustness. Terminal Server is useful by itself, but administrators who need additional features will appreciate MetaFrame. MetaFrame is easy to use and easy to make effective, and MetaFrame clients' functionality is close to local applications' functionality.
| MetaFrame 1.0 |
|
Contact: Citrix Systems * 954-267-3000 Web: http://www.citrix.com Price: $4995 for a 15-concurrent-user license Additional user licenses are available; for pricing information, contact Citrix Systems System Requirements: Server: 200MHz CPU or better; multiprocessor system recommended to facilitate system scaling, Windows NT Server 4.0, Terminal Server Edition, 16MB of RAM, plus 4MB to 8MB per client, PCI bus or other high-speed (non-ISA) bus for NIC strongly recommended, SCSI or Fast SCSI recommended, TCP/IP, IPX/SPX, or NetBEUI network protocol, Client: Windows-based terminal or PC running the Terminal Server client, TCP/IP, IPX/SPX, or NetBEUI network connection |
MaxStation
The alternative to ICA and RDP is skipping the display protocol entirely and just sending graphical output from the server to the client. Maxspeed's MaxStations are thin-client devices that use a special type of ICA called Direct ICA to run video output directly from servers to clients. I must admit that I was skeptical about MaxStation. I wondered how different one more thin-client product could be. But now I'm sold on Maxspeed's solution. MaxStations aren't appropriate for every environment, but when they work, they work. Running an application locally is faster than running the program on the server and downloading rendering information to a client. The difference isn't large, but it exists. Display protocols, no matter how good they are, take time to work. Working on a server via a MaxStation system feels exactly like working on the local machine.
What Is the MaxStation?
In a sense, when you use a MaxStation, you're working on the server locally. Maxspeed's technology runs a direct analog video feed from a Terminal Server system to the thin-client monitor. The MaxStation setup consists of three parts. The first MaxStation component is an SGX controller that fits into an ISA slot on the Terminal Server system. The back of the SGX controller has two or four (depending on the MaxStation model) unshielded twisted pair (UTP) ports. The second component, the MaxStation machine, is a terminal about as large as a medium-size pizza box. You plug a monitor, mouse, and keyboard into the terminal, and you can plug in a printer. You run a Category 5 UTP cable from the port on the back of the MaxStation to the corresponding port on the controller card, and the video output streams through three of the pairs in that cable. The fourth pair of wires transmits mouse and keyboard input to the server. The third piece of the MaxStation trio is Citrix's Direct ICA protocol. Direct ICA provides an NT 4.0 interface, which previous iterations of the MaxStation lacked.
MaxStations are interesting not only because they're fast but also because of how they work. The SGX controller is a video controller card. You can't run most analog video streams across a long distance, but MaxStations' connections work across a LAN. You can't use it across a WAN or dial-up network, but the connection works fine as long as the client and server are within 200' to 500' of each other. (The maximum distance depends on the model of MaxStation that you use.) The SGX controller is the only connection between a MaxStation client and a Terminal Server system. You don't need a network connection to use MaxStation, but the client can use any network connections the server has access to. MaxStations don't cause network traffic problems, because they need no more network bandwidth than a one-user client. You can install in the server as many controller cards as you have ISA slots for, as long as you have a MaxStation license for each client.
A MaxStation terminal isn't particularly prepossessing. The terminal looks like an NC, and it's little more than a memory buffer for video information. MaxStations have very small CPUs, so they're simple to set up. You plug in the peripherals, plug in the server connection, boot everything up, and you're finished. The only problem I ran into in booting MaxStations is that the terminals' sole mouse connection is for a serial mouse (not an in-port mouse like most new mouse devices). Fortunately, I had a converter handy.
I tested a MaxStation with Direct ICA, which comes on the MetaFrame 1.0 CD-ROM. Like the ordinary ICA protocol, Direct ICA can support only 256 colors. This limited color range is a shame, because Direct ICA displays video so well.
Let's See What You Can Do
To test a Maxspeed system, I installed a four-port SGX controller card in a server with a 350MHz Pentium II MMX CPU and 128MB of Synchronous DRAM (SDRAM). The system was running Terminal Server and MetaFrame 1.0. Although Maxspeed documentation extensively explains how to change the jumper settings to configure the I/O address space that the SGX controller uses, I found that the server's default settings of D8000 worked just fine. Check your system setup if you're not sure whether that base address is free. I powered down the server, plugged a MaxStation into the port in the SGX controller card, and booted the server.
Next, I installed the Direct ICA protocol. Direct ICA doesn't come with a graphical configuration tool, but I found the setup program by reading the Direct ICA documentation that comes with MetaFrame. After I installed the protocol, I ran the MetaFrame Connection Configuration tool to set up Direct ICA support, powered up the MaxStation, and rebooted the server. I watched the software detect the card and make sure that all its ports were up and running. (I discovered that neatness counts—plug the first MaxStation into the first port, or the system will hang during this detection phase.) When the server boots, you'll see a Windows logon screen on the MaxStation. Log on, and you're in a Direct ICA session on the server.
Limitations and a Quibble
As much as I like the MaxStation's performance, I must admit that Maxspeed's solution has limitations. First, the technology's dependence on a direct connection between client and server restricts it to locations in which such a connection is possible, and it restricts the number of MaxStations one server can support. Second, Direct ICA doesn't support encryption. Third, users can't adjust the Maxspeed user interface (UI) from their terminal. If a user wants to change the screen resolution from 640 X 480 to 800 X 600, an administrator must change the setting through the MetaFrame Connection Configuration tool, which Screen 6 shows. Fourth, users can run only one session at a time on a MaxStation terminal. This single-session functionality is typical for NC users, but it might make Windows-based terminal users cranky. Because of these limitations, MaxStations are best for smaller networks on which all user terminals are within one building.
My one quibble with the MaxStation is that although Maxspeed's technical support staff was very helpful, I hate the product's documentation. The documentation is confusing, and it doesn't explain what you need to know to set up the product on your server. (Maxspeed designed the documentation for SCO UNIX servers; the NT connectivity information consists of an outdated note on one page.) If you decide to implement MaxStations, forget the manual; use Citrix's Direct ICA documentation to install and configure your MaxStations. After I had the Citrix documentation in hand, the installation and testing went smoothly.
The MaxStation isn't going to replace the Terminal Server model of thin-client computing. The technology's requirement that each client have a local-area connection to its server makes this solution feasible only for a small number of users. Although you can add multiple SGX connectors to a server, running many clients per server can be difficult. Each SGX connector supports a maximum of four clients, and many high-end servers have mostly PCI slots, not the ISA slots that Maxspeed's SGX connectors require. In addition, although MaxStations are cheaper than some other Windows terminals and NCs—and much more responsive than Windows terminals or NCs—replacing all your existing client machines with MaxStations isn't cost-effective unless you need MetaFrame on your servers anyway. MetaFrame and its client licenses aren't cheap, and the MaxStation terminals and SGX controllers cost extra.
However, companies that use MetaFrame, that intend to replace their standalone computers or terminals, and that want extremely high-speed performance on their clients might find MaxStations worth the price. Such firms will find that MaxStations deliver the same level of performance to terminal users that the users' Terminal Server system delivers locally.
| MaxStation |
|
Contact: Maxspeed * 650-856-8818 or 800-877-7998 Web: http://www.maxspeed.com Price: $399 for GWX terminal; $995 for SGX4 controller card; $650 per seat for four-node implementation System Requirements: Pentium processor or better, Windows NT Server 4.0, Terminal Server Edition, Citrix MetaFrame, 64MB of RAM, plus 8MB to 16MB per user, SCSI CD-ROM drive, One free ISA slot for each SGX controller card |
