Evaluating Windows Terminals

The most important features aren't the ones you'd expect

Windows terminals are solid-state devices that display applications running on a Windows terminal server. The OS that powers the device might be a form of Windows or a flavor of Linux. The device might offer terminal emulation support in addition to Windows display protocols, as many of the terminals I review here do. (For more information about Windows terminals and protocols, see "Related Articles in Previous Issues," page 124.) Regardless of the local OS or the protocols supported, Windows terminals can display Windows graphical output routed from a Windows terminal server.

Windows terminals make up only about 30 percent of the desktops in the thin-client world. The other 70 percent of desktops are PCs that run a display protocol and thus can run locally installed applications as well as terminal server applications. But Windows terminals have advantages over PCs in some situations. A PC might be too big for the available space, or the environment might not be good for a PC—dust in a warehouse, for example, can damage a hard disk. Or perhaps you need a device that is nearly impossible to break or misconfigure for installation at an unattended kiosk, at a truck stop, or in a library. Whatever the reason, you need to use terminal services, and you've determined that PCs are not a good client for the environment. But how do you choose a thin-client device? When evaluating thin-client devices, you might find that the most important features aren't the ones you'd expect.

Windows Terminal Basics
On the outside, core Windows terminal features include a keyboard, a mouse, and serial and parallel ports. Many newer terminals also have one or two Universal Serial Bus (USB) ports. But you'll need to think carefully about the devices you plug into USB ports. Any device (such as a scanner) that requires a lot of chattering between the client application and output device will bog down the network. So, don't assume that you'll want to plug a particular device into a terminal simply because you can.

10Base-T network connections have been standard in Windows terminals for a while, but 10/100Base-T connections are becoming more common. For logical connections, Windows terminals generally support RDP, ICA, and at least one (and perhaps many) traditional terminal emulation types (e.g., VT100, 3270), so you can use one terminal for all connection types.

The basics of configuring a Windows terminal are simple. Windows terminals use TCP/IP to communicate with the network, so you'll need to specify whether the device will get an IP address from a DHCP server or will have a static address. You'll also need to choose display settings. Most Windows terminals support resolutions of at least 1024 x 768 or 1280 x 1024, and refresh rates of 75Hz to 85Hz are typical. If you change either core configuration option, you'll need to restart the machine. You'll also need to know what you're doing or have a good manual when you set up a Windows terminal because no online Help is available on either Windows- or Linux-based Windows terminals.

Securing Windows terminals can be a problem. One Windows terminal I tested required me to include logon information when I set up a connection to a terminal server. Even terminals that don't require logon information let you include a username and password in the connection settings so that the user doesn't have to provide the information at logon. But if you include logon information in the connection configuration settings, anyone with access to that connection can log on to the terminal server and access any domain resources available to that account. If you choose a terminal that requires logon information in the connection settings, you'll need to physically protect the terminal. Although some terminals include password protection or support smart card readers as an extra layer of security, I generally advise against including logon information in any connection setup unless your environment is completely secure or you give few permissions to terminal users.

A Need for Speed?
How do Windows terminal devices compare on the inside? One of the easiest criteria to isolate is CPU speed. Faster is better, right? Well, yes and no. Having a fast CPU isn't a bad thing, and thin-client devices that perform local processing benefit from more power. However, because of the way thin-client devices work and because of what they're designed to do, CPU speed isn't as important as some other factors. You can't evaluate a thin-client device by using the same criteria you would use to evaluate a PC because a Windows terminal doesn't do a PC's job and operates in an environment different from that of a PC. In a thin client's simplest form, the device is an extension of the terminal server with a remote display. When you understand how Windows terminals work and what they do, you can clearly see why CPU power isn't the main determinant of performance in most present-day terminals—and why CPU power might become more important as the standards for Windows terminals change.

Whether you use RDP or ICA with terminal services or you use a terminal emulation package that shipped with your thin-client device, the method of getting graphical data from the server to the client is approximately the same. When you connect to a terminal server, the server assigns a session to you and identifies it internally. Any application you run from that session is associated with the session so that what you do with your application doesn't affect the same application running within other users' sessions. The terminal server's monitor doesn't display the application output for any session except the console session. Instead, the display driver for the remote session downloads to the client the commands needed to show application output, window resizing, text input, and so forth. In the other direction, the session's client uploads mouse clicks and keyboard movements, which the terminal server interprets only for that session. As you might guess, remote sessions use different video and client I/O drivers than does the console session because the remote-session data takes a different path from the console data. (You don't need to load extra drivers—they're part of terminal services.)

On the client end, all you need to manage the connection to the terminal server is a network interface so that the Windows terminal and terminal server can communicate, video support and a monitor so that the client can render and display the output, and a CPU to process the network and video data. If the client uses a device connected to its local serial, parallel, or USB port, the display protocol also transports the information needed to make that client-side device work with the terminal server session. Thus, the terminal's key innards are the network interface, the video logic, the memory for storing data, and the CPU. About 70 percent of Windows-based terminals (WBTs) use National Semiconductor's layout. This layout divides key system components into two groups connected by a PCI interface that also interfaces to the network card. One group of components performs number crunching, and the other group carries out data I/O.

Basically, the path from the Windows terminal to the terminal server starts with the PCI-based network connection. When the network delivers data to the Windows terminal, the network card passes the data through the PCI interface to the group of number-crunching components, which includes the CPU, memory controller, bus controller, video generator, and SDRAM. As the video generator creates graphical output, the video generator passes the output to the display module on the terminal (I/O) side, which is where all port interfaces are located. Currently, motherboard speeds range from 66MHz to 83MHz, with 83MHz being most common. (Keep in mind that CPU speeds are separate from motherboard speeds.) Although 100MHz motherboards should become available this year, they will likely appear only in the few higher-end Windows terminals that are intended to do more local processing (such as the processing that CAD programs require), not in models designed to replace text-based terminals.

Because the terminal's primary job is to display output generated on the terminal server, the critical parts of the data path are those to the network controller and the video generator. If these paths are slow, the device will be slow. Certainly, the more information transferring between client and server, the more work the CPU has to do. However, when you're talking about a 200MHz CPU responsible only for helping to process incoming and outgoing network data and doing any work that a graphics accelerator can't handle, the demands aren't great. Video and network interface speeds are more important to device performance than is CPU speed, and in general, total performance on the Windows terminal depends more on server load and network throughput than on client-side performance.

I don't mean that CPU speed is never important. When devices have locally installed applications, such as Web browsers, CPU speed makes a difference just as it does in the PC world. As you'll see in the following reviews, a few Windows terminals have locally installed Web browsers. With time, more such terminals will appear—the newest specifications for Professional model Windows terminals include the option of installing a local copy of Microsoft Internet Explorer (IE) 5.0 and Windows Media Player, and Linux-based thin-client devices often include a locally installed copy of Netscape Navigator. Microsoft's next version of the specification for Standard WBTs will permit OEMs to include a Windows CE-compatible version of IE 4.0 on the device. Local application support isn't limited to browsers, either: You can customize Netier Technologies' NetXpress SL2000 to include just about any locally installed application you want. In fact, some thin clients are getting decidedly chubby, moving from lean and mean to solid-state PC wannabes.

On thin-client devices that don't run locally installed applications, however, CPU speed is much less important to overall performance. Congestion at the server or network level is likely to have a far greater impact on Windows terminal performance than the terminal's overall performance is, and video and network driver efficiency is likely to be more important to client performance than CPU speed is. In the past, many Windows terminals manufacturers used proprietary OSs on terminals. But when Windows CE became available (appearing on terminals in mid-1998), the trend reversed toward using readily available standardized OSs. The reason for this change isn't hard to determine: As one OEM told me, hiring developers skilled in a proprietary OS is much harder than hiring developers skilled in a widely used OS. These days, you have three main choices for the OS in a thin-client device: embedded Windows NT, Windows CE, and Linux.

Choosing an OS
A Windows terminal's OS, its drivers, and the display protocol the device uses to communicate with the terminal server for a session have more influence on the device's performance and ease of maintenance than the hardware does. First, the terminal's OS influences which drivers are available. Second, the OS determines the setup and configuration interface—or at least whether it will follow a standard.

Any Windows terminal powered with embedded NT or Windows CE must conform to Microsoft's model for Windows-based terminals. WBT Standard terminals use Windows CE and don't support locally installed applications. (WBT Standard 1.5, which Microsoft announced in January and will make available before second quarter 2000, will permit a locally installed copy of IE 4.0 for Windows CE.) WBT Professional terminals use embedded NT and may optionally include a locally installed copy of IE 5.0 (or another browser) and Windows Media Player. To be sold as a WBT, neither type of terminal can support any devices, such as floppy drives, that aren't part of the standard. Additionally, OEMs must follow a particular design when creating an interface for a terminal's configuration and session setup tools. OEMs can add to these interfaces, but the basic tool layout must always be the same.

Linux terminals don't have these restrictions. A Linux terminal can include any device that its manufacturer deems necessary or desirable, and the OEM can decide how to design the terminal's interface. However, this flexibility means that Linux terminals are less predictable than their Windows-based cousins. If you can set up one Windows CE-based terminal, you can set up another one without having to think much about it—even if the options vary, the basic information required and the manner of displaying it are the same across all similar devices. If you know what information you need to connect a Linux terminal to the server, you can figure out how to make the connection, but you can't go to a different Linux terminal and automatically know the location of all the tools. These differences, combined with a poor user interface (UI) and lack of management tools, made setting up the two Linux-based terminals I tested a chore.

Finally, the OS your terminals use can influence the types or quality of display protocols available to you. As of November 1999, the restriction on RDP working with non-Windows clients ended and a Linux-compatible version of RDP became available. However, RDP isn't on all Linux boxes. When RDP does appear on Linux terminals, it's RDP 4.0, which doesn't support all the functionality of RDP 5.0, used with Windows 2000 (Win2K). Furthermore, the Linux version of RDP doesn't yet work all that well. Although Linux's RDP might improve by the time you read this, for the time being, I'd skip the Linux RDP clients and use ICA instead.

Is Performance Important?
As I've stated, CPU speed isn't a key factor in differentiating Windows terminals, and neither is the locally installed OS. The speed of the client's network interface and video generation matter more, but the network speed and server load overshadow even these factors in real-life performance. However, when you eliminate factors such as network congestion and server load, the performance differences between devices can be significant.

To evaluate the performance of thin-client devices I cover in this review, I tested them with BAPCo's SYSmark 98 and recorded the time each device took to complete the application benchmark tests for Netscape Navigator 4.05; Microsoft Excel, Word, and PowerPoint; and Adobe Photoshop 4.01. For consistency, I ran these tests on a nearly unused network segment and on a dual 300MHz Pentium II terminal server with 128MB of RAM that was supporting only NT Server 4.0, Terminal Server Edition (WTS) with Service Pack 4 (SP4), Citrix MetaFrame 1.8, and one session running one benchmarking tool. The benchmarks ran through a series of tasks common to each application. I used the ICA display protocol for the tests because the devices had only that protocol in common. I ran all the tests at 800 * 600 resolution. Table 1, page 122, shows my results.

Looking at the benchmarks in Table 1, you might immediately assume you should avoid Neoware Systems' NeoStation 2300 because it was the slowest in the tests. However, I caution you against making a purchase decision based solely on performance. First, the tools available for a given Windows terminal will make a big difference in the time you spend to update and manage the terminal. At press time, several vendors were developing remote-administration tools, but tools were available on only a few of the terminals I tested. Second, when you use one of the slower terminals (as opposed to running a benchmarking tool against a stopwatch), the terminal feels little different from other devices that completed the tests more quickly. Apart from the fact that you don't type as quickly as a benchmarking tool, the influences of server and network responsiveness mute these performance results. If you stress the server a bit and add some network traffic to the segment, the numbers won't mean as much. When all other factors are equal, some terminals will be faster than others, but you'd be making a mistake if you considered only performance when choosing a Windows terminal.

Instead of focusing on how quickly a device can draw pictures, think about the requirements it needs to fill. Some Windows terminals support only 10Mbps networks; others support both 10Mbps and 100Mbps. Does the device you're considering support the network speed you need? Consider performance, but also think about where the terminal will fit—physically and logically—into your organization. Will you be using the terminal in an environment in which PCs aren't practical? Does the device's form factor work in your situation? What kinds of management tools are available for the device? Does the terminal have the port types (e.g., COM, LPT, USB) you need? Are the terminal's plugs and power connections easy to reach? How quickly is the terminal available when you turn it on? Finally, how would you feel about plugging in several hundred of the devices?

Results
The reviews that follow look at nine Windows terminals and help you evaluate the offerings. Table 2, page 122, compares these terminals' features. After examining the devices, I came to some general conclusions about the offerings.

The only two Linux Windows terminals available for this review were Boca Research's BocaVision JNC205 and the Thinworks e3000. I'd hoped to have a wider sample of Linux-based terminals, but Wyse Technology canceled production of its Linux terminal in favor of a device that uses embedded NT, and Netier Technologies' device wasn't available in time to review. The disappointing news is that, based on my sample, Linux Windows terminals aren't yet ready for prime time. I know I'll hear from dissatisfied readers about this conclusion, and I wish I could report that Linux terminals were as fast and well designed as the best Windows NT- or Windows CE-based devices. However, my evaluation of the JNC205 and the Thinworks e3000 shows that Linux Windows terminals still have rough edges.

Linux's RDP protocol is slow, and its graphical portion is shaky. Unlike native RDP, which runs on Windows only, Linux RDP can't use the client OS's graphical capabilities, and so will remain slower until developers streamline the protocol. Even when the devices use ICA, their performance is no better than average. And the poorly designed interface can make setting up ICA connections painful. (Of the Linux-based terminals I evaluated, I'll take the text-based menus over the Windows-like GUI.)

The devices also tend to be big and heavy, which isn't necessarily a problem but does mean that Linux terminals are less space-efficient than a Windows CE-based terminal that can stand up next to its monitor. Neither type of device has centralized administration tools available. In short, the Linux terminals look like the Windows CE-based terminals of a year or so ago. The one advantage the Linux devices might (but don't always) have is cost. Although you'll need to provide a mouse, keyboard, and even a power cord, at $375 the Thinworks e3000 is inexpensive because the OEM doesn't need to license the OS. However, a couple of the Windows CE devices are almost as economically priced, and they have the peripherals the Thinworks e3000 doesn't have.

Removing the Linux devices from the picture leaves one NT-based terminal and six Windows CE devices in the group I evaluated. The Windows CE devices were fundamentally similar, but a few stood out. If you work with Network Computing Devices' NCD ThinPATH products (which can manage both PCs and the NCD ThinSTAR Windows terminals), you'll need the NCD ThinSTAR 400, which has a good design in most ways and performs well. Readers looking for a true bargain in terms of feature set and cost will like Boundless Technologies' Capio 325.

I really liked Wyse's Winterm 3320SE in many different ways, though. Its display isn't quite as high-quality as some of the other devices, but it's perfectly usable, and the terminal's security and reliability features make it attractive, particularly if you access a terminal server from across a WAN. As a general rule, when evaluating WBTs, look for features that enhance their usability (such as high-quality graphical output), security, or ease of management.

ART-4000
Addonics Communications' Windows CE-based ART-4000 is a simple Windows terminal with an odd mixture of benefits and liabilities. On the outside, the ART-4000 is fairly compact. The device can rest either on its side or propped up on its edge in the stand included with the unit. Because the ART-4000 can rest on its side instead of being under the monitor, the fact that all ports and the power switch are in the back doesn't cause a problem. (For ease of setup, however, I prefer to have at least the sound I/O ports and the power switch on the front.) Although the terminal has only one serial port (instead of the more usual two), it has two USB ports.

Like the other Windows CE terminals, the ART-4000 walks you through the necessary setup steps when you power it on for the first time, prompting you for the IP address settings and display settings. The display settings have a Test button, but because the resolution goes to only 1024 x 768 and the refresh rate to 75Hz, you probably won't need the Test button unless you're working with a very old monitor.

When you restart the device after initial setup, the basic configuration should be quick because few options exist beyond the basic settings found in all WBT Standard terminals. You can't password-protect the configuration and connections settings, although you can protect the device with coded swipe cards. However, the swipe cards don't prevent device users from reconfiguring settings.

With configuration complete, you're ready to set up connections to terminal servers that work with RDP, ICA, or Ericom PowerTerm text-based terminal emulation. If you're new to creating terminal connections, you'll appreciate the excellent and detailed documentation that comes with the ART-4000.

I'm not quite so happy with the terminal session because of one problem: The video output is slightly fuzzy compared with the output of the other devices I tested. The windows display quickly (the ART-4000's benchmarks were slightly slower than average, but the device feels just as fast as others when you're using it), and letters appear as you type, but the slight blurriness of the display makes the terminal uncomfortable to use. This consideration might seem minor. However, a video output that gives users headaches won't sell people on the thin-client experience, even though the video support, not the terminal services, is the problem.

The ART-4000 is responsive, is the only device I tested that has smart card support, and is easy to set up. However, the display definitely needs some work, and the price is expensive for what you get. Unless you really need smart card capability, I'd recommend another model that costs about the same and has a wider range of features, even if it doesn't support smart cards.

BocaVision JNC205
The JNC205 was one of the first Windows terminals to use Linux for its locally installed OS. The device was an early beneficiary of the Linux-compatible version of the RDP display protocol and offers the expected ICA and 3270 emulation as well. I looked forward to comparing the JNC205 to its WBT brethren, but this device doesn't offer much reason for you to choose a Windows terminal based on Linux. Although the JNC205 is less expensive and boots more quickly than the WBT Professional terminals that are its competitors, the device's interface and performance are subpar for both users and administrators.

The JNC205 uses a Windows 95-like interface, complete with Start menu to access configuration options. Although the interface uses an X for a cursor and has different fonts on the dialog boxes, the UI has maximize and minimize buttons and functions very much like the Win32 UI does. If you're familiar with Windows, you can easily locate the tools you're looking for. When you use the tools, however, you'll find them poorly laid out and confusing. If you don't have a good idea of what you need to do to make the connection, you'll be lost in the tools' dialog boxes. While configuring settings and setting up connections, I found that trying to do more than one thing at once seemed to make the device hang. Later, I discovered that the device wasn't hanging; rather, the mouse stopped responding or responded very slowly. I had to restart the machine to make the mouse work.

Only the system configuration tool is relatively easy to use, but even it lacks some basic features found in other Windows terminals, such as support for the number pad or a graphical test button so that you don't configure the device to use a refresh rate that the monitor can't handle. (If you happen to set the JNC205 to an unsupported refresh rate, press the Esc key during system boot to open the boot options, then select Emergency settings to display the system configuration tool at 640 x 480 resolution and a 60Hz refresh rate.) To set up a connection, you must provide user connection information, although you can assign a user password to the device to mitigate the resulting security liability. To update the OS, you connect to the BocaVision FTP site, which the vendor updates whenever the firmware changes.

When you connect, the device isn't spectacular. The RDP client had intermittent video output problems, displaying black boxes for text (this problem disappeared when I reconnected), and the Linux-compatible version of RDP was noticeably slower than the native Windows RDP protocol. The Linux version of RDP must provide capabilities that the native RDP version can rely on the client OS for, so this lag isn't surprising, but anyone thinking of using Linux RDP should be aware of the difference in speed. (Also remember that the JNC205's early version of the RDP protocol only became available in November 1999, and Linux Windows terminals with RDP support might use a later version by the time you read this article.) The ICA client worked without problems, but I found the session less responsive than other available ICA connections.

You might choose this device over the WBTs for a few reasons. First, the JNC205 gives you a locally installed browser for a lower price than does Netier's NetXpress SL2000 (this advantage will be lost when WBT Standard 1.5 permits locally installed copies of IE 4.0 in Windows CE-based terminals). Second, this device is good for those who prefer Netscape Navigator over IE and who want a locally installed browser. Third, the JNC205 has two USB ports, which is more than some Windows CE-based terminals offer. Finally, the product's network speed is 10/100Base-T, not 10Base-T. But even considering these advantages, I can't recommend the JNC205 unless you simply can't afford a WBT Professional terminal. The JNC205 is awkward to use, not very responsive, and—surprisingly, given what I'd heard about Linux's speed compared with Windows'—relatively slow even when loading Netscape Navigator, a locally installed application.

Capio 325
The Capio 325 is an excellent low-cost Windows terminal. In performance, the terminal rated average in the benchmarks that Table 1 shows, but my own user experience was excellent. The device draws windows incredibly quickly (logons take place almost instantly, and the terminal has no problem keeping up with typed user input). As you'd expect in a terminal session, performance fell off a bit when I used the Microsoft Paint program to draw bitmaps: Unless I drew slowly, the curves came out as jagged points. But except when drawing bitmaps, running applications in a terminal session feels like running applications locally. The product supports multiple types of terminal emulation. The Capio 325 also supports touch-screen input.

Like many other Windows CE-based terminals, the product's physical design is neither perfect nor terribly uncomfortable. The ports are on the back of the device but aren't difficult to reach, and the design doesn't force you to put the monitor on top of the device. The Capio 325's boot-up time is also average for a Windows CE device. The user's guides aren't as detailed as some other vendors' (e.g., Neoware Systems') manuals but are adequate for most users' needs. Finally, Boundless provides Viewpoint Administrator management software for remote administration. Viewpoint Administrator 2.1 uses a Windows Explorer-like interface and supports hierarchical management, thin-client grouping, and flexible security permissions.

However, the Capio 325 I tested was missing some features common to other Windows CE-based terminals, such as sound support (although this feature is available as an expansion option). When I wanted to pick a display resolution and refresh rate, I found that the Display configuration tab doesn't provide a Test button, so I couldn't check whether the settings I'd picked worked with my monitor. (However, this device supports a maximum refresh rate of 1024 x 768 at 75Hz, as opposed to the higher resolutions and refresh rates that other devices support, so the lack of a Test button probably won't cause problems unless you're using a very old monitor.) The device also doesn't provide a USB port. These omissions might not cause a problem for you, but you should be aware of them.

For a thin-client environment that is in a LAN—and thus has a reliable connection—I'd definitely consider the Capio 325. The product is very fast, is easy to set up, has most of the basic features that you find in Windows terminals (including remote-administration tools as well as password protection to keep users from changing the configuration and connection settings), and is less expensive than most other Windows terminals. The only options missing are some of the security granularity and connection reliability tools that I found in a few of the other Windows terminals I reviewed. Otherwise, it's a great little box.

NCD ThinSTAR 400
Management tools for Windows terminals are product-specific. For example, you can't use Wyse tools to manage a Boca Research box. The vendors also restrict their tools to Windows terminals and don't take into account an organization's PCs that use terminal services. NCD offers NCD ThinPATH tools that give users remote administration, load balancing, and functionality that RDP 4.0 doesn't provide. This suite of tools mimics MetaFrame's functionality but works only with PCs and the NCD ThinSTAR suite of Windows terminals, so the NCD tools lock you into an NCD-type terminal.

The NCD ThinSTAR 400 is the most recent terminal in the ThinSTAR series, and NCD has improved most of the physical attributes over the NCD ThinSTAR 300. Instead of being a large device that sits under the monitor, the NCD ThinSTAR 400 is a stand-up model. The sound I/O ports and power switch are on the front of the terminal and easy to access. On the back of the terminal are two USB ports, two serial ports, and one parallel port. The only exterior design flaw is the position of the power cord's connection. Rather than put the connection on the back of the device, as other vendors do, NCD put the power connection on the bottom. You insert a special connector at a particular angle into a plug that you can't easily see. This design isn't a deal-breaker, but when I set up the terminal, inserting the power connector was frustrating, which made me wonder how I'd feel about plugging in 500 of these devices. The NCD ThinSTAR 200 had a great stand-up design, and although the NCD ThinSTAR 400 is closer to that design than the NCD ThinSTAR 300 is, neither terminal matches the NCD ThinSTAR 200's simplicity.

Apart from the power connection's physical peculiarity, the NCD ThinSTAR 400 performs well. Like other Windows CE devices, when you turn on the terminal for the first time, it walks you through a setup wizard for network and display settings. The terminal's display settings are among the most flexible of the Windows CE-based terminals I tested. The terminal also has a refresh rate of 85Hz and a top display resolution of 1600 x 1200—the highest resolution of any terminal I tested.

After you reboot to establish the video and network settings, you might want to check out the other available configuration settings. Most of the options (e.g., input, display, network) are similar to the settings on other Windows CE-based terminals. But the Management tab offers many extra options. First, you'll notice that the NCD ThinSTAR 400 gives you a high degree of security granularity. For example, you can password-protect each part of the configuration settings, not just the entire collection. Second, the Management tab's subtabs provide many options that give you a great deal of control over the device. However, you'll need to do some homework to understand these options.

The NCD ThinSTAR 400 doesn't come with a hard-copy manual to help you understand the configuration settings. When you purchase the NCD ThinPATH management software, you get an online manual. Otherwise, you can either download the .pdf file from the Library section of the NCD Service and Support Web site or buy a hard copy of the manual. Considering the detail of the configuration settings, I strongly suggest you download both the System Administrator's Guide and the User's Guide from the Web site so that you can refer to the manuals as you walk through the configuration options. Documentation wasn't available at press time but should be available by the time you read this article.

Although the NCD ThinSTAR's management tools are excellent, the terminal's performance is fair. This terminal draws windows very well, but it has a slight lag (similar to that I've seen with other Windows terminals) when drawing glyphs, which can make typing awkward and less natural than on some faster Windows terminals. You're always aware that you're running applications in a terminal environment, not locally. Regarding connection types, the model I tested supported only RDP and ICA connections. However, NCD had a terminal emulation connection in beta at press time.

One of the biggest reasons to buy the NCD ThinSTAR 400 lies in its total-solution management software. NCD ThinPATH software is the only terminal-management solution that also supports PC clients and is your only option for tools that let you control both PC clients and terminal clients to a degree not possible with the native NT terminal services alone. Because the NCD ThinPATH management suite costs less than MetaFrame, and NCD's software gives you flexibility to choose tools, the NCD ThinSTAR is a good choice if you're planning a Windows-only thin-client environment, even if the cost is slightly higher than some other terminals.

NeoStation 2300
The NeoStation 2300 is the smallest of the devices I tested. This device has a good design. The power button and sound I/O ports are on the front of the device, so attaching headphones or a microphone is easy. On the back, the terminal has a parallel port, two serial ports, a standard DB-15 video connector, an RJ45 network connector, a mouse port, a keyboard port, and a PC Card slot. The only connection the device is missing is a USB port. However, whether this absence is a loss is debatable because some USB devices (such as scanners) that pass a large amount of data don't operate well in a server-based computing environment. If you want a 100Mbps network connection, you need to say so when you buy the terminal because the default for the NeoStation 2300—as for many Windows terminals—is 10Base-T.

After you power up the terminal, you can easily set up the device and create terminal connections. When you start the terminal for the first time, Windows CE's setup program prompts you through a series of steps to configure the device to work on your network. After you complete the setup, you can start creating terminal connections. Windows CE doesn't provide online Help for administrators who are new to setting up Windows terminal connections. However, new administrators can refer to the excellent and thorough hard-copy documentation that comes with the NeoStation 2300.

Using this terminal is generally pleasant. The video quality is easy on the eyes, connections are easy to set up, and the device's thorough manual includes lots of step-by-step, well-illustrated explanations about how to configure the device. If you get stuck, you can take advantage of the 90 days of toll-free telephone technical support and free software upgrades. Because the terminal supports RDP, ICA, and optionally the Pericom terminal emulation client, you can connect to a couple of different kinds of servers. The configuration options include support for French terminal server connections (which don't use encryption). This unusual Windows terminal feature will make the lives of administrators who work with the French edition of terminal services a bit easier. The display settings include a prominent Test button and a variety of refresh and resolution options (up to 1024 x 768 at 85Hz or 1280 x 1024 at 75Hz) that work with nearly any monitor.

Neoware supports two kinds of supplementary software for the NeoStation 2300. First, Citrix Device Services adds functionality to RDP connections, letting you use RDP 4.0 to support client-side serial and parallel devices. (RDP 5.0, which comes with Win2K, supports client-side devices, and the NeoStation 2300 should support RDP 5.0 by the time you read this article.) Second, Neoware's Update Wizard for Windows CE management software comes with the terminal and lets you remotely configure it. To update clients with this software, you don't need to attach the terminals to a server; just turn on the terminals and attach them to the network. You can remotely create and define new terminal connections with the connection management software now in beta.

During setup, the NeoStation 2300 I tested stuck occasionally in a configuration screen. I needed to cycle the power off and on, but a reboot took only 42 seconds and wasn't a big problem.

Regarding performance, although this terminal is fast when displaying Windows and screen redraws, you'll notice an infinitesimal but slightly distracting delay in video and glyph output. For most applications, the delay isn't as pronounced as the performance benchmarks in Table 1 might have you believe, but the delay exists and is a bit distracting. The degree to which this delay will be a problem depends on the user's tolerance and the applications he or she uses. Compared with a 66MHz 486DX2-based PC, the NeoStation 2300 seems very responsive. Compared with a 400MHz Pentium II PC, this terminal feels a touch slow.

Overall, I found the NeoStation 2300 comfortable to use and easy to set up, although a bit slow. The NeoStation 2300 might be a good choice for thin-client environments that support applications without many screen updates. This terminal is an inexpensive addition to a network and provides all the necessary functionality for most people who require a Windows terminal.

NetXpress SL2000
If you want to create a pure thin-client environment, using NetXpress SL2000 might appear to be overkill. However, if you want a terminal that is more like a PC, this device is a good choice.

Although Netier came out with the NetXpress SL2000 long before Microsoft announced the specifications for WBT Professional terminals, this device follows that design. (NetXpress SL2000 uses embedded NT Workstation 4.0 SP3 because Netier released this terminal before Microsoft released the specifications for embedded NT Workstation.) This terminal has a locally installed copy of IE 5.0 (Opera Software's Opera and Netscape Navigator are also available), and you can choose from Windows Media Player or RealNetworks' RealPlayer G2. Therefore, you aren't dependent on a terminal server for Web access. You can choose to have the reseller install other applications locally in flash memory, but the device will then cost more because of the memory necessary to accommodate those applications.

If the NetXpress SL2000 is so PC-like, why use it instead of a PC, when you can probably get more power from a PC for the same price? First, although you can order NetXpress SL2000 with a CD-ROM drive or a hard disk, this device is ordinarily a solid-state machine—an advantage in dirty and noisy areas in which dust or vibration could damage rotating media. Second, this terminal is smaller than a PC, so space isn't a problem. Third, you don't have to lock down the local interface—Netier locks it down for you according to your specifications. So, only someone with the administrator's password can use many of the Control Panel tools, and users can't modify browser settings. You'll still need to use system policies to lock down terminal sessions, but the clients are secure from most user tampering.

The NetXpress SL2000 has a good external design. Commonly used ports (e.g., mouse, keyboard, sound I/O) are in front, so they're easy to reach. The serial, parallel, and USB ports are on the back. The power switch is also on the back, which isn't my preference for terminals. However, you probably won't want to turn off NetXpress SL2000 often because it boots fairly slowly.

The NetXpress SL2000's interface is different from other WBTs' interfaces. Instead of displaying the simple list of connections that you see when you turn on a Windows CE-based terminal, the UI displays a modified form of the Win32 desktop, including the taskbar and Start menu. However, this appearance is misleading. The Start menu shows only a few tools: Shut Down, Help, Documents (for local documents only, not terminal session documents), version information, and a Programs menu that provides links to IE 5.0 and the RDP and ICA client tools. Microsoft designed the RDP and ICA client tools for NT, so you already have support for Citrix Program Neighborhood (which Windows CE will eventually support) and the Client Connection Manager for RDP connections. Thus, you can connect to server farms from the NetXpress SL2000 instead of having to connect to individual Citrix servers, as you must with terminals that use client OSs but lack Program Neighborhood support.

Netier also makes Rapport Administrative Software, which you can use to control and update the terminals. Rapport Administrative Software lets you manage thin clients and update their applications and firmware settings from across the network. The NetXpress SL2000 also comes with Citrix Device Services, which adds to RDP 4.0's support for client-side serial and parallel ports.

The NetXpress SL2000 isn't for everyone. This terminal has more power than some users will need, and at $720, which doesn't include the cost of the OS license, this product isn't inexpensive. The terminal's slow boot time means that you'll probably want to leave it on, unlike other terminals that boot quickly enough so that turning them off when you aren't using them is practical. And users who want to turn on the terminal and immediately log on to a terminal session might find the Win32 desktop confusing because this UI destroys the illusion that the terminal session is running locally. However, the terminal provides a way to give people the power and customization of a PC in a sealed-case box. If you need more oomph than a Windows CE-based terminal can give you, I recommend the NetXpress SL2000.

TeleCLIENT TC7170
I have a love-hate relationship with TeleVideo's TeleCLIENT TC7170. As a user, I love most things about this device. This Windows CE-based terminal is extremely responsive, and the video output is high-quality, supporting resolutions of up to 1024 x 768 at an 85Hz refresh rate. The device not only performed well in my application benchmarking tests but is very responsive when you're running a terminal session.

As an administrator, I like this terminal's local features: the detailed system inventory, the touch-screen display support, and the ability to password-protect the connection configuration so that only password holders can configure terminal connections. When you start the TC7170 for the first time, the Windows CE setup program provides a series of prompts to configure the device to work on your network. After completing the setup, you can start creating terminal connections. My only quarrel with the connection setup isn't with the TC7170 but with the Windows CE connections interface, which assumes that you know how to set up the connection. At press time, TeleVideo was still working on the documentation, but I've seen the documentation for other TeleVideo models, and it was very helpful.

I'm less impressed with the TC7170's administration and setup, however. From a software standpoint, I found setting up the terminal fairly straightforward. Yet, the current lack of management tools (TeleVideo is developing some tools, which I haven't seen) means that you have to physically touch and configure each device. I also found the terminal's physical design awkward. All the ports are on the back: the parallel port and two serial ports, the two USB ports, the sound I/O ports, and the standard video connector, network connector, mouse port, and keyboard port. The terminal doesn't label the mouse and keyboard ports, so you need to consult a diagram to tell them apart. Even worse, the 17" monitor sits atop the terminal; a slot in the bottom of the monitor fits over a tab on the supporter that fits on the base. Therefore, setting up the pieces is awkward because you have to hold the heavy monitor sideways while you fit two separate pieces (the terminal and the supporter) together. Assembly is easier with two people, but I wouldn't want to put hundreds of these terminals together. Nor would I want to dismantle this terminal to replace the monitor or terminal. Putting the monitor atop the device also makes reaching the ports difficult.

TeleVideo assured me that many customers like this design, and in a cramped area, a terminal that doesn't take up more desktop space than the monitor requires can be advantageous. But when I look for an integrated terminal and monitor, I like a truly integrated design that incorporates the terminal portion into the monitor. TeleVideo doesn't plan to release an integrated device until the second half of 2000, which is also when TeleVideo's management software should be ready.

The bottom line is that as you physically set up the terminal and plug in attached devices, you'll hate the TC7170's awkward design, but your users will love its speed and high-quality display. However, at $899 (including a 17" monitor), the terminal is fairly expensive, considering that you can buy a decent 17" monitor for $200. I'd probably choose another terminal with a high-quality video output over the TC7170 so that I could have a less awkward form factor and more configuration options.

Thinworks e3000
In the second half of 1999, Linux-based Windows terminals began to appear. The timing wasn't coincidental. Citrix released an ICA client for Linux in September 1998, and the noncompete agreement that gave Citrix exclusive rights to support non-Windows clients' attachments to Windows terminal services expired in November 1999 and cleared the way for a Linux-based RDP.

Thinworks designed the Linux-based Thinworks e3000 to replace a desktop computer or terminal. This purpose is evident in the shipped unit's lack of power cord, keyboard, and mouse. I thought the manufacturer had left out these items in error. When I asked about them, Thinworks told me that the company expects customers to have standard power cords and keyboards. The moral: If you purchase the Thinworks e3000, make sure that you already have a power cord, keyboard, and bus mouse.

Like the other Linux-based terminal I tested, the Thinworks e3000 employs a sturdy design intended to have the monitor on top. This setup makes reaching the ports a little difficult (which is one reason I prefer stand-up models) but does cut down on the amount of desk space the device uses. A serial port, two USB ports, a parallel port, and a game port (although the device doesn't come with any games) are on the back of the terminal. The power switch and reset button are on the front and easy to reach.

Linux-based terminals don't follow any particular scheme, so don't be surprised that this terminal is different in both setup and feature set from other Windows terminals—even Linux-based devices. When you turn on the device, you can boot either to the system configuration menu or to the connection defined in the server configuration settings. In other words, you can't edit the system settings and start a connection from the same interface; you need to boot to the interface that supports what you want to do. After you boot to the system configuration menu, you can save and exit, and the system boot will continue, similarly to how a computer resumes booting after you interrupt the boot to edit the BIOS. This method isn't terrible, but I prefer a system that lets me tweak connection settings and immediately try them.

If you assumed that the configuration menus are text-based, you're correct. Although this command-line interface might sound confusing if you're accustomed to a GUI, I found system and connection configuration easier to perform with these menus than with the Linux-based JNC205's graphical interface. The Thinworks e3000 organizes settings into several different menus (i.e., network, server, display, and administrative settings), which you access by pressing function keys. From the configuration menu, you can choose from four desktop appearances. The default appearance, which shows the window manager and an ICA client, is one of the better Linux graphical interfaces I've seen.

Basic configuration of the device isn't difficult to figure out; if you do run into trouble, the small user manual tells you most of what you need to know about setting up the connections. Technical support was very helpful when I ran into problems that the manual didn't resolve. The only catch is that the company is located in Sweden and doesn't offer North American-based telephone support. North American customers can communicate with the company's technical support through email, which isn't always an ideal solution. You're welcome to call, but calls from North America can get expensive, and the time difference makes coordinating problem resolution with Thinworks' office hours difficult.

The device's performance in an ICA session was average for the Windows terminals I tested. The Thinworks e3000 now supports RDP; this option wasn't available at test time. Like the other Linux Windows terminal I tested, the Thinworks e3000 was slightly slower than the Windows CE-based devices.

Would I use the Thinworks e3000? I preferred the device to the JNC205, mostly because of the better UI. However, the Thinworks e3000 isn't much less expensive than some of the Windows CE terminals I tested, and those terminals are easier to set up, have better RDP support, and come with peripherals. Even with ICA, the device's performance was average compared with the other terminals in this review. But if I wanted a Linux-based terminal and if Swedish technical support wasn't a problem, I'd choose the Thinworks e3000 over the JNC205.

Winterm 3320SE
Wyse is probably the best-known manufacturer of Windows terminals. After working with the Winterm 3320SE, I can suggest a reason for this popularity: In the Winterm 3320SE, Wyse has made a reliable workhorse. The Winterm 3320SE isn't flashy and doesn't have some of the extras that other terminals have, but Wyse built this terminal to be extremely reliable, and the extras add value.

On the outside, this device is similar to many other Windows terminals I tested. The device stands next to the monitor and has the power button on top and all ports (i.e., two serial ports, one parallel port, a sound I/O port, a network connector, keyboard port, and mouse port) easily accessible in back. Unlike the other stand-up models I tested, this terminal doesn't require you to affix a separate stand. Fewer parts means a shorter physical-setup time.

In terms of user experience, the Winterm 3320SE is similar to other terminals. For example, this terminal supports touch-screen technology, which can be handy for users of point-of-sale applications. This terminal's performance is generally good—not top of the line, but comfortable. I prefer a faster refresh rate than 75Hz, but I have no complaints about the interface, which draws windows quickly, can easily keep up with typing and video output, and is generally clear. The display isn't the most beautiful of the Windows terminals I tested, but it isn't uncomfortable to use. Unless you compare terminals one after the other as I did, you probably won't see any noticeable difference.

The device excels in its manageability, reliability, and security features. As an example of the manageability, you can specify an FTP server to push upgrades to the terminal. From the Applications tab, you can enable support for various remote management tools such as WyseWorks Remote Administrator and SNMP. The current standards for WBTs don't include SNMP support, so this device's SNMP support is rare in terminals.

The Winterm 3320SE has good security, too. A potential hazard of an ordinary Windows terminal connection setup is that users can see—and even edit—other connections and the system configuration information. Some Windows terminals provide a way to lock down this ability. These terminals either hide the Configure tab or password-protect sections of the system configuration tabs. The Winterm 3320SE goes a step further and lets you edit what users can see based on their user rights. From the Security tab, you can specify which connections display for individual users, assign users to groups, and grant users terminal access based on the configuration options that you define for their group memberships (e.g., administrator, user, guest). You can even edit these settings so that users can log on only to a session that you specify (and can never see the configuration interface) or can choose only from among connections that you specify. On a related note, you can selectively enable or disable support for the local LPT, COM1, and COM2 ports.

Security isn't the only advantage to the Winterm 3320SE. From the Security tab, you also can enable failover recovery, which pings the server before attempting to connect to it. If a ping fails, the terminal drops the connection and moves to the next server in the list until it finds one that answers the ping. This capability isn't part of standard ICA but is one of Wyse's ICA extensions. The terminal also offers the ability to resequence ICA packets when they arrive out of order.

I'm happy with Wyse's support. The representatives I talked to were helpful and responsive. A CD-ROM containing the manual comes with the device, and although the manual isn't dripping with detail about the more advanced device settings, it's as good as the best hard-copy manuals I've seen for other Windows terminals.

The end result is that in terms of support, core capabilities, general reliability, and ease of use, I definitely recommend the Winterm 3320SE to anyone who needs extra security and reliability. Although this device costs more than some of its competitors, the feature set can be well worth the cost.