A Case for Terminal Server

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.

   Previous  [1]  2  3  Next