A Case for Terminal Server

Terminal Server reveals a remote access solution

When I first heard about Microsoft's deal with Citrix to license Citrix WinFrame and develop Windows NT Server 4.0, Terminal Server Edition, I wondered how this new product might affect life in the NT world. The new OS's promise to combine the best of WinFrame's multiuser capabilities and NT 4.0's features and interface sounded appealing. Yet, I wondered when I might have an opportunity to test Terminal Server in the real world, and how the product might perform. Recently, an opportunity arose when one of my clients got into a jam. Read on, and I'll tell you the story of how Terminal Server solved the case.

Anatomy of a Problem
The client, a structural engineering firm, had recently hired my company to assist with the planning and deployment of a WAN solution to link two satellite offices to its central office. Each remote office has approximately 10 users, whereas the central office has about 30 users. The solution I deployed included private, 128Kbps frame relay links between the remote offices and the central office, and a 384Kbps link from the central office to the Internet.

I intended for the new remote office connections to provide access to central-site resources including a Microsoft Exchange Server email system and file and print shares. In addition, the remote offices use the central office's proxy server for Internet access with a private IP addressing scheme consistent with the central location. This configuration uses one Internet contact point to provide the administrators centralized control of Internet access and to reduce configuration hassles. Figure 1, page 84, shows the customer's network architecture.

After I put the frame relay links in place, I added BDCs to each remote office for local authentication and centralized file and print services. When the offices operated as expected in the new WAN environment, I imagined that the company's needs would quiet down. However, about a week later, I received a phone call from the customer that changed everything. The customer had neglected to mention an important detail in an implementation-planning meeting: Users in the remote offices need access to an accounting application that uses a Microsoft Access database at the central office. Shortly after my departure, the company's IS staff had configured users at the remote offices to access the accounting application.

The remote users experienced major performance problems with the application and the WAN links in this configuration, and the customer wanted to know how to resolve the problem. I explained the problems inherent in running a shared-file relational database such as Access over a low-bandwidth WAN link (with an average of five simultaneous users at each location, no less). After assessing the situation and considering the new information, I began to devise a solution.

Ideas for solving this problem fell into two categories: accommodating the traffic or reducing the traffic. One idea was to increase the fractional T1 port speeds of the frame relay links to accommodate the additional traffic. The customer's solution was to upgrade the accounting system to a new SQL Server-based version (an upgrade the company was already considering). The customer and I also discussed combinations of these two ideas.

Both solutions had strong disadvantages. Increasing the bandwidth of the frame relay links to the level required to run the application successfully meant high initial costs, plus the likelihood of doubling the monthly data communications bills. The firm's senior partners would frown at this prospect. Although migrating to a SQL Server-based application provides the increased efficiency and reliability of a client/server-based database, the upgrade meant possible unexpected expenses. Worse still, the consultant supporting the accounting system didn't find the SQL Server-based application to be much faster, and believed that performance problems would still exist.

Terminal Server to the Rescue
I fought a seemingly unwinnable battle of numbers. No matter how I approached the problem, the customer needed to spend a good deal of money to meet the demands on the network. I wondered whether additional applications on the customer's network would further exacerbate the bandwidth utilization problem. About that time, I remembered the newly released Terminal Server. After I researched and tested the product in-house for a week or so, with experiments over links that approximated the customer's infrastructure, Terminal Server's performance and stability impressed me. I decided this product was ready for prime time.

I proposed that the customer purchase a new server to run Terminal Server at the central office and install Terminal Server client software on user desktops that required access to the accounting application in the remote offices. The company already had RAS dial-in access via modem pools and PPTP, so I planned to leverage these connections to provide Terminal Server access to RAS-based clients.

The best part of this solution was its extensibility. Because Terminal Server clients need a somewhat consistent amount of bandwidth, adding more applications to the Terminal Server client doesn't significantly increase the client session bandwidth. (Terminal Server clients are similar to remote control applications—e.g., pcANYWHERE32, Remotely Possible/32—which primarily send screen and keyboard changes between client and server. These sessions require a fairly constant bandwidth, in contrast to native applications that have a wider variation in network usage.)

Although I devised the Terminal Server scheme to solve the accounting application and database access problem, Terminal Server's additional benefits quickly appeared. For this organization, the numerous benefits of a thin-client solution included the following:

The idea of using a generic user profile appealed to the customer, because it reduced administrative costs, security risks, and the potential number of failure points. (Unique user profiles require local configuration to properly run the applications, and thus increase administrative costs.) A generic user profile was feasible in this solution because the accounting application uses authentication separate from that of NT.

The ability to leverage Terminal Server for additional central site applications became a popular feature. After the customer fully understood this new resource's capabilities, the company wanted everything but the kitchen sink. The customer wanted access to its contact manager database application (i.e., Symantec ACT!) and Microsoft Office 97 through Terminal Server. This way, instead of servicing one application, the Terminal Server system became an instant gateway to essential corporate data. The bottom line was that for a one-time hardware and software purchase, the company could avoid the enormous increase in long-term monthly costs that the bandwidth-increase solution required. If the customer had supplied more bandwidth to attempt these feats, it might have ended up in the same situation it started in. Using Terminal Server, the customer can make more applications available to the Terminal Server clients without worrying much about the impact on WAN performance, as long as the applications don't generate an abnormal amount of screen activity (e.g., Web browsers, graphics applications). Another advantage of Terminal Server is the significant total cost of ownership (TCO) reduction, because it requires less application installation and maintenance. Another unexpected benefit of the Terminal Server solution was the ability to use different hardware for desktop client PCs. The customer wanted to maintain full-strength PCs for most of the desktop workstations, because many users run AutoCAD for drafting work and need the local horsepower. But Terminal Server makes it feasible to provide low-powered and low-cost systems—such as legacy PCs, thin-client workstations, and Windows CE devices—for clerical workers and other employees who don't require high-powered PCs.

Sizing and Pricing the Server
After the customer decided to go with the Terminal Server solution, the next step was to determine the hardware requirements for the new Terminal Server system. If you're considering deploying Terminal Server, start at the Microsoft Terminal Server Web site. I found several useful white papers about Terminal Server deployment, including papers discussing administrative issues and capacity planning. The most useful papers were "Windows NT Server 4.0, Terminal Server Edition Capacity Planning," at http://www.microsoft.com/ ntserver/terminalserver/deployment/ capacplan/tscapacity.asp, and the "Deployment Guide," at http://www.microsoft.com/ ntserver/terminalserver/deployment/ map/tsdguidewp.asp. Table 1, page 86, summarizes the capacity-planning white paper's suggestions for Terminal Server hardware requirements.

Microsoft's minimum requirements for various products (including NT) have burned me in the past, so I take software vendors' recommendations for hardware requirements with a big grain of salt. I took several steps to ensure the server's adequacy. First, I chose a base server platform that was highly scalable in terms of CPU and memory. Next, I padded Microsoft's figures 15 to 20 percent (a formula I have used successfully with vendor-provided minimum requirements). Finally, I tested the applications' performance on a non-production server running Terminal Server. This test was necessary, because the white paper bases capacity-planning recommendations on nebulous client usage levels (which Table 1 shows): Light (task-oriented), Medium (administrative), and Heavy (knowledge). The customer's users seemed to fall somewhere between Medium and Heavy, but I didn't want to make a false assumption.

After completing the test, I felt confident that the server configuration (a quad-processor-capable Pentium II Xeon server with two 400MHz Xeon processors and 512MB of RAM) met the initial load I expected. A possibility existed that the server's usage might increase drastically if it gained popularity. However, I knew that I could increase the server's capacity if the need arose.

The final area of capacity planning was to assess network utilization. I wanted to determine the average bandwidth of each Terminal Server client session. To collect the customer's data, I installed on the server the Network Monitor tool and Network Monitor Agent, which added the Network Segment object to Performance Monitor. I then used Performance Monitor to simulate the customer's expected Terminal Server usage. I used two key Network Segment counters to assess usage: %Network utilization, which gives the total bandwidth amount a network segment uses, and Total bytes received/second, which provides the number of received bytes per second on a segment. After I had these figures, I was confident that the WAN link satisfied the customer's capacity needs. I was ready to proceed.

To RDP or ICA? That Is the Question
The test also determined whether the RDP protocol, which Terminal Server includes, would suffice in the customer's environment from both a performance and an administrative standpoint. Before I had ever worked with Terminal Server directly, I had heard from several sources (including a Terminal Server product manager) that RDP was significantly slower and less feature-rich than its Citrix MetaFrame counterpart, Independent Computing Architecture (ICA). In fact, a few people I spoke with completely wrote off RDP, saying that MetaFrame and ICA were the way to go.

ICA (which requires you to purchase a MetaFrame product) is undeniably more sophisticated than RDP, but adding this functionality to your Terminal Server installation costs a great deal. Whether to use the Citrix products is purely a question of need. If RDP supports your compatibility, performance, and administrative requirements, you have no reason to shell out the extra dough for MetaFrame. But MetaFrame offers features such as additional client support (i.e., Web-based clients, Macintosh, UNIX, and Windows 3.1); shadowing for administrators to remotely view and control Terminal Server client sessions; server load balancing; local printing and drive mapping; and automatic client updates. (For feature comparisons between RDP and ICA, see Tim Reeser, "RDP or ICA," page 89.)

Because MetaFrame is an add-on product, you can purchase it later if you need it or if you can't afford it during the initial deployment. In this company's environment, RDP provided more than sufficient performance for remote client sessions (the company has 100 percent Win32-based desktop clients).

Licensing Landmines and Laments
After I had put the customer's hardware requirements in place, I needed to determine the licensing requirements. I had heard that Terminal Server had some eccentric licensing policies, and my initial research confirmed these rumors. Licensing Terminal Server wasn't very intuitive.

I thought that because Terminal Server is a true mainframe-style solution, licensing software on the Terminal Server system was a simple matter of licensing the Terminal Server system (with a per-seat Client Access License—CAL) and the client applications. However, at the time the customer purchased this solution, this wasn't the case. When I began researching the licensing, no concurrent licensing scheme existed for Terminal Server. (Note that MetaFrame supports concurrent licensing of ICA clients.) In addition, each client accessing the Terminal Server system required a standard NT Server CAL and a license for NT Workstation 4.0.

Microsoft recently announced significant changes to the Terminal Server licensing policies. Microsoft now offers Terminal Server CALs at an estimated price of $109 (significantly less expensive than NT Workstation at $319). Microsoft still requires you to add the NT Server CAL, which costs about $40, making the total price about $150 (rather than $360).

Microsoft also unveiled a work-at-home Terminal Server CAL at a significantly reduced price (50 percent of the standard Terminal Server CAL price) so that users can access their corporate Terminal Servers from home. (Note that the work-at-home CAL requires that you already own a standard Terminal Server CAL.)

Finally, Microsoft added a concurrent add-on component for Terminal Server, called the Internet Connector, for about $9995; the company designed the Internet Connector to accommodate up to 200 concurrent Internet-based users (e.g., a prospective customer accessing a sales demo on an Internet-connected Terminal Server system). Microsoft acknowledged customers' complaints about the original licensing and created a new scheme, which is great news for companies considering Terminal Server for deployment. (For more information about Terminal Server licensing, see "Understanding Terminal Server Licensing," at http://www.microsoft.com/ntserver/ terminalserver/exec/eomap/pricingdetails.asp.)

A Low Gotcha Factor
I appreciated the low number of gotchas that I encountered during this Terminal Server implementation. Rampant bugs often plague new versions (or modified versions) of a Microsoft OS, but I didn't experience this problem with Terminal Server. Terminal Server's straightforward process and the relative ease with which I got the first fully functional client session up and running with applications surprised me.

Despite my general success, the installation was far from problem-free. In fact, I ran into several problems that required advanced diagnostics and troubleshooting. The first problem occurred when the customer's accounting application was unable to access certain Terminal Server files and Registry keys crucial to the accounting application's operation. To diagnose these problems, I pulled out two trusty standbys from my NT toolkit: Systems Internals' NT utilities Regmon and Filemon (essential to any NT administrator's diagnostic toolkit). These utilities provide a realtime observation of your system applications' file access and Registry keys, including information about whether an application successfully obtained the requested access.

Compounding the file access problem was the fact that the client's security context wasn't sufficient for me to use Systems Internals' utilities (because of the utilities' administrative rights requirement). However, I ran the utilities locally from the Terminal Server console, which let me view the files and Registry keys that I couldn't access in other user sessions. After I identified the problem files and Registry keys, I made the necessary access control list (ACL) adjustments and resolved the problems.

I ran into problems after installing the Terminal Server Zero Administration Kit. ZAK runs as a noninteractive batch process and hides and secures files that you don't want users to access, such as OS-related files. This approach reduces administration problems and tightens security. A few server applications didn't like the fact that the files were hidden, and they refused to run. I had to relax some of the more aggressive ACL changes that ZAK made to various system directories to accommodate the applications. However, I used Systems Internals' monitoring utilities to make minor changes and easily dispatched the problems.

Parting Thoughts
Based on my experience, I have a few words of advice for those of you with a Terminal Server deployment in your future. First, install Terminal Server as a standalone or member server, not as a PDC or BDC. Much like Internet Information Server (IIS), Terminal Server is far easier to secure with a local account database controlling access to Terminal Server resources. If you make the Terminal Server system a domain controller, the only account database accessible to the server is the domain accounts database. Therefore, you can't restrict Terminal Server's client user accounts (for logon) to the local machine; you must use domain user accounts.

A performance-related reason to use Terminal Server as a standalone or member server is to prevent it from doing double duty as a domain controller and let it concentrate on its terminal-serving duties. For this reason, I also recommend minimizing the number of services you run on the Terminal Server system. When possible, keep such services as WINS, IIS, DNS and DHCP off the Terminal Server system and place them on other NT servers instead.

Finally, if you deploy the Terminal Server ZAK, ensure ahead of time that you understand ZAK's impact on the installation. The best way to learn how ZAK will modify the Terminal Server environment is to first read the white paper thoroughly, then test ZAK on a non-production server running the applications that you use within your organization. In addition, before installing ZAK, you will need to make a full backup of the Terminal Server system, including the Registry. In some cases, you might need to remove ZAK's directory attributes and ACL modifications to make certain applications run properly.

For my customer, Terminal Server was the secret answer to a major problem. Given the product's low TCO, simplified administration, and ability to create a homogenous desktop environment out of a heterogeneous array of client hardware, Terminal Server is certainly a product worth consideration. Who knows? Perhaps your organization will have a case for Terminal Server to solve.