Evoking images of a multiheaded beast, Microsoft's Windows-based Terminal Server platform (formerly code-named Hydra) is poised to revolutionize the way you deploy applications. Combining the best ideas of thin-client technology with the familiarity of Windows NT, Terminal Server is Microsoft's ace in the hole against the network computer (NC). (The sidebar "What About the Network Computer?" offers another perspective on NCs.)
Deploying Terminal Server will be a complex proposition. It will be so different from the traditional Windows model of computing that anything approaching a large-scale rollout will leave you rethinking your entire enterprise IS strategy.
From servers to clients to the very backbone of your network, Terminal Server will put new, unfamiliar demands on your IS infrastructure. The time to plan for a Terminal Server rollout is now, while you are formulating budgets. Don't find out too late that you needed to beef up that server or add another T1 line.
This article provides the information you need to plan effectively. You'll learn how to prepare for a smooth Terminal Server deployment, and what to expect—for server hardware requirements, bandwidth utilization, and everything in between.
The first beta of Terminal Server was not available for this article, so I'll discuss the product based on its lineage (the product is a descendant of Citrix Systems WinFrame). Special thanks go to the product teams at Citrix and Microsoft for helping to make this preview possible. (For a review of WinFrame 1.7, see John Enck, "Desktop Technology Today," page 86.)
A New Twist on Windows
Before you can fully appreciate Terminal Server's impact, you must understand how a multiuser platform differs from single-user Windows. Under NT, applications execute within the context of the current user profile. If a user is logged on to the system console, the security and preferences associated with that user's profile define the runtime environment.
Terminal Server exploits this concept of distinct user sessions to provide multiuser access to NT. When a Windows terminal user logs on to a Terminal Server, Terminal Server duplicates the underlying NT runtime environment (e.g., the user logon process, the Win32 subsystem) in memory. Terminal Server then assigns this new copy (which executes alongside the original) to the incoming user and modifies it according to the user's profile.
As more users connect to Terminal Server, it repeats the duplication process for each connection. The result is a seamless multiuser environment: All Terminal Server users have a private NT runtime environment tailored to their user profile.
The underlying technology that manages this subsystem-cloning process is MultiWin, which Citrix developed for use in its popular WinFrame remote access platform. Microsoft licensed MultiWin for inclusion with Terminal Server.
The Terminal Server MultiWin model is not very different from single-user NT: The client accounts (and user profiles) define the individual runtime environments. However, NT supports only one console user operating under a single-user profile, and Terminal Server lets multiple user sessions run concurrently and share the host system's resources.
Terminal Server's virtual console capability makes this process possible. Instead of piping the user I/O for a particular MultiWin session to the system's physical console, Terminal Server redirects the information to a remote client. This client can be a physical device (e.g., a Windows terminal) or a software viewer application running on a remote workstation. Either way, the information Terminal Server sends—bitmap translations of the session's desktop, keyboard input, and mouse coordinate data—is rather primitive. In this regard, Terminal Server is similar to a Windows remote control package, but on a much broader and more robust scale.
All these characteristics—from the way that Terminal Server slices up the NT console, to the type of information that Terminal Server sends over the wire—directly affect Terminal Server's system requirements and its effect on your infrastructure. The benefits of the Terminal Server model are numerous (seamless integration with NT security, low client overhead) but come at a cost: more server horsepower and network bandwidth, and diminished application compatibility.
Server Requirements
When most IS planners learn of Terminal Server's projected server requirements, their initial reaction is sticker shock. MultiWin's subsystem duplication is costly, both in terms of system RAM (to hold the multiple session images) and CPU cycles. To put it bluntly, Hydra eats servers for breakfast.
Still skeptical? Consider the recommended server configurations in Table 1, page 180. I took these figures from the technical training guide for Citrix WinFrame. Citrix based these recommendations on the older WinFrame 1.6 platform, which is an extension to NT 3.51. Citrix never shipped WinFrame 2.0 (its multiuser NT 4.0 solution and the basis for Terminal Server), so the company didn't publish any recommended configuration parameters. Probably, Citrix's recommended RAM numbers would have been higher to compensate for the larger NT 4.0 working set and the well-documented code bloat of current-generation Windows applications.
Citrix differentiated between typical users and power users, in its server recommendations. According to the Citrix technical training workbook, a typical user "generally uses one or two applications but normally only one at a time. The data requirements are not complex and do not usually contain Object Linking and Embedding (OLE)." A power user is "a more sophisticated user who uses larger applications and data files, and often has three or more applications active at the same time. The data requirements are complex and often use OLE heavily."
With any modern MultiWin implementation, the distinction between typical users and power users becomes blurred, in part because of the increased complexity of today's Win32 applications. Even moderate system use can launch multiple processes within a given user session, sending system memory requirements rocketing skyward.
To test these theories and better understand what constitutes realistic server-side requirements for a Terminal Server implementation, I elicited the help of Competitive Systems Analysis (CSA), a Northern California market research and consulting firm that has evaluated various MultiWin platforms. Using a late release candidate of WinFrame 2.0, CSA profiled the memory usage for a typical MultiWin session.
What CSA found generally confirmed my suspicions. Even in a relatively modest application scenario (load Microsoft Word 97, load a document, load Microsoft Internet ExplorerIEto perform a Web search), session memory requirements (as measured by the WinStation: Working Set parameter in NT's Performance Monitor) ballooned to more than 20MB, with an average memory load of more than 15MB. Screen 1 shows this profile.
Based on CSA's findings, I revised Table 1 to reflect Terminal Server's more demanding environment. I updated the processor parameters to better reflect today's technology and eliminated the distinction between typical and power users because it no longer applies. Table 2 summarizes my projected server configurations for Terminal Server. I based the data on the assumption that Terminal Server's Virtual Memory subsystem will ease the RAM crunch (you'd better budget for a fast disk subsystem, too). Microsoft's new thin-client platform probably will require massive server resources to support even modest client loads.
Here are two action items for would-be Terminal Server architects:
- Keep Terminal Server's appetite in mind when making server purchasing decisions. In particular, watch out for workgroup servers that offer limited symmetric multiprocessing (SMP) and memory expansion. Four-way SMP and 1GB of RAM must be standard equipment.
- Think beyond the disk. Traditional file and print (and even database) applications are primarily I/O-bound. Terminal Server pushes I/O and CPU memory subsystems to their breaking points, so don't skimp on processor power: A 200MHz Pentium Pro with 1MB Level 2 cache will work, and a 300MHz Pentium II with 512KB of RAM is ideal.
Bandwidth Requirements
Terminal Server will need lots of bandwidth. Unlike NT, which can operate over slow-link connections, Terminal Server is low-bandwidth intolerant. Starve this beast by saturating the network or inadvertently disrupting communications, and all of its heads (clients) will attack.
Microsoft has Citrix to thank for this aspect of Terminal Server's architecture. Citrix optimized WinFrame for multipoint (instead of shared-bandwidth) data communications as part of WinFrame's positioning as a remote access solution.
Under WinFrame, the server hosts most user sessions via analog modem connections over dial-up phone lines. Each user receives a private network channel into the server. The only competition is for the server's core hardware (e.g., the CPUs, system memory, disk). Bandwidth is immaterial because each inbound connection is unique and dedicated to one user. The left side of Figure 1 depicts a WinFrame configuration.
This model is great for a Remote Access Service (RAS) solution, but not for a chaotic corporate LAN. Here, Terminal Server's finely tuned execution model may begin to break down as user sessions compete with each other and with the rest of the network for bandwidth. The right side of Figure 1 shows a Terminal Server configuration.
Bandwidth is a finite element in any network equation. You can simulate RAM or even multiple CPUs (through virtual memory and multitasking), but you can't simulate bandwidth. You have it, or you don't. If you don't, Hydra is likely to turn around and bite you: Application windows will repaint erratically, the session will ignore or lose user input data, and overall usability will take a nosedive.
Just how voracious will Terminal Server be? The bandwidth requirements will vary depending on the client protocol in use. Unlike WinFrame, which used Independent Computing Architecture (ICA), Terminal Server will support multiple client types. Although supporting multiple client types adds flexibility, it also makes profiling a Terminal Server solution's bandwidth requirements problematic.
Take ICA as an example. Citrix recommends at least 20Kbps per session. With less bandwidth, your system shows the effects of communications latency through slow repaints and choppy input response.
Table 3 shows bandwidth recommendations extrapolated across various user configurations. To put Terminal Server's requirements in a real-world context, the table also defines the aggregate bandwidth and equivalent connection type.
What about T.120/T.Share? (T.120 is the International Telecommunications Union conferencing protocol; T.Share is Microsoft's version of the protocol.) Microsoft's protocol suite of choice, T.120/T.Share, will be the default client interface for Terminal Server. I couldn't obtain firm numbers at press time (little information is available on the suite's bandwidth requirements), but the protocol's roots are in the high-performance world of ISDN video conferencing, which doesn't bode well for Terminal Server's bandwidth requirements.
If ICA takes 20Kbps, you can assume that any combination of T.120/T.Share components will be at least 25 percent more demanding (ICA is very finely tuned). Though T.120/T.Share will ship with Terminal server, ICA is a third-party add-on that you must buy separately (well worth the investment).
Here are some suggestions with regard to bandwidth for Terminal Server:
- Evaluate current network utilization levels and build out as necessary. If you now consume 80 percent of the available bandwidth on your 10Mbps Ethernet backbone and you plan to roll out 500 new Windows terminals and their supporting servers, you have two choices: Invest in some new routers and a second backbone, or upgrade to 100Mbps Ethernet.
- Analyze WAN connections for potential bottlenecks. Slower WAN routers will become overwhelmed by as few as four or five Terminal Server sessions, so identify these bottlenecks early and isolate traffic accordingly.
- Don't skimp. Citrix recommends 20Kbps for an average ICA session, but CSA has found wide fluctuations in client demands. A Terminal Server session frequently spikes into the 30Kbps to 40Kbps range when users are rendering a complex bitmap image. So err on the side of caution—you can never have too much bandwidth.
Integration Issues
You've beefed up your application servers and groomed your network infrastructure to handle Terminal Server's wide load. Now comes integrating applications.
For managing applications, a Terminal Server platform will be a lot like any other NT system. You install applications at the server console, and users access them over the network. However, with Terminal Server, the users will do more than access a network share point; they will be working with a virtual copy of the server's console. The process works as if the user had logged on to the server as a local account. If you have Microsoft Word installed on the server, users executing Word will see the program running within the context of the server's hardware environment—just as if they were sitting at the server console. The beauty of MultiWin is that when you implement it properly, it is completely seamless to the user.
However, this shared console model of execution is not without problems. Let's look at three application scenarios that have proved troublesome for administrators of Citrix WinFrame and derivatives.
Console applications. Some Windows programs don't adapt well to a simulated console environment. A good example is GFI Fax & Voice's multiuser fax server software. The package's client interface relies on a Windows Messaging API (MAPI)-based pop-up dialog box to address an outbound fax. Under WinFrame, the dialog box appears on the server's console because the dialog box's address is the computer name, instead of the name of the user who wants to send the fax. The result is the user sees nothing on the remote desktop, and the operation fails. The only workaround for this default behavior of the dialog box is to rewrite the GFI fax application so that it addresses the dialog box to the username (a nonstandard behavior that requires a modification at the source-code level).
CPU-intensive applications. Applications that peg the CPU (e.g., forcing the system's processor to 100 percent utilization through a keyboard monitoring loop or similar code structure) can be problematic in a multiuser environment. In a single-user system, operators rarely feel the effect of a CPU-intensive application because they are interacting with it. However, in a shared system, all users feel the effects of a CPU-intensive application because it degrades performance systemwide. Because many popular applications (Microsoft Office 97, IE, even legacy DOS programs) peg the CPU, you can understand why Citrix has steadfastly recommended the deployment of SMP platforms for even moderate client loads.
Multimedia applications. Multimedia applications and Terminal Server won't mix. Because programs execute within the context of the server's hardware, they can't take advantage of any client-side multimedia resources. If the client has a sound card or a full-motion video adapter, the server-based application won't see it because the environment that the application is executing in exists solely on the server.
Clearly, you must weigh some serious application issues when you evaluate any Terminal Server solution. Beyond compatibility, the lack of multimedia support could severely limit Terminal Server's appeal as a general-purpose deployment platform.
As you integrate applications into Terminal Server, follow this advice:
- Test, test, test! If an application uses a lot of pop-up dialog boxes, especially MAPI components, grill the developer about dialog-box addressing. If developers are uncooperative, threaten to drop them. In today's climate of mission-critical awareness, sloppy programming is inexcusable.
- Outlaw nonessential DOS programs. DOS programs are the chief culprits in most pegged-CPU scenarios. Programs such as msd.exe (a leftover from DOS 5.0 and 6.0) are particularly nasty. Delete them before they come back to haunt you.
- Think mixed-media interfaces. One way to work around the multimedia handicap is to integrate elements from outside the session. Terminal Server's client interface will run as an ActiveX control, so you can easily combine an application session with other Web elements to create a more robust solution. Unfortunately, such a mixed-media solution won't work on a dedicated Windows terminal, but it will work on PCs or NCs running a Terminal Server session within a window.
Is Terminal Server Worth It?
Terminal Server is a technological enigma. It has by far the thinnest client interface of any Windows platform. System requirements for the client are trivial: 1MB to 2MB of RAM and a network connection. This technology provides a true Windows terminal (i.e., dumb, thin, and marginally functional) solution.
Unfortunately, this product will achieve its slim client figure not by compressing the underlying computing model (as the NC does) but by shifting the existing Windows model to the server. Terminal Server is a move from fat clients and fat servers to anorexic clients and obese servers—a lateral transition that places considerable stress on other areas of the corporate infrastructure.
The tradeoffs are clear: Ultra-thin client computing in exchange for massive servers, high bandwidth consumption, and the potential for some really nasty compatibility headaches. The question is whether Terminal Server is worth it.
The answer is a concrete maybe. For specific tasks (e.g., acting as a kiosk or providing bank tellers with nearly bulletproof workstations), this technology is a promising solution. It's robust, reliable, and relatively easy to maintain—qualities that will appeal to any veteran IS planner.
However, Microsoft seems to have in mind a broader role for this product. NT guru and Microsoft VP Jim Allchin was recently quoted as saying that Microsoft sees Terminal Server as the company's vehicle of choice for deploying Win32 technologies across Windows 3.x systems, a scenario that the platform is ill suited for. Such a foolhardy strategy will likely backfire, leaving early-adopters holding the bag. (For another perspective on reusing legacy systems, see "UARCO Gets Thin," November 1997.)
The bottom line: Don't believe the hype. Test prototypes extensively and keep the server, bandwidth, and compatibility issues in mind. This beast needs special care and feeding, but when deployed appropriately, it is the undisputed king of the Windows terminal jungle.
