Printer Friendly

Extending the Reach of the Thin Client.

Using a few main servers and many thin client terminals made it easy for us to extend our services, in more ways than one.


In May 1999, our library faced a crisis. Y2K was just around the corner and we were not prepared. The public access workstations on the reference floor were badly outdated, but we were too overwhelmed to deal with them.

We work for the Wake Area Health Education Center (AHEC), which consists of Information Resources, Regional Health Education Services, and the busy multi-specialty physician practice, CARE-lina Medical Associates. As one of nine AHECs in North Carolina, Wake AHEC is also responsible for providing continuing education and information to health care practitioners in a nine-county region.

Our group, Information Resources, includes the Medical Library, Information Systems Support, and a Conference Center. Information Systems Support is responsible for all computing throughout Wake AHEC, but has an especially close relationship with the Medical Library. So, all in all, we had about 300 PCs to replace. Given the time, budgetary, and staff constraints that we were facing back in May 1999, the chances of completing the upgrade before midnight on December 31 looked very bleak indeed.

Not only were we facing the upgrades for Y2K, but we had also entered into a collaborative agreement for an online integrated library system with two other North Carolina AHECs--one in Wilmington, on the Atlantic coast, and another in Asheville, in the mountains to the west. We are based in the middle of the state, in Raleigh, and we had to find a way to complete our upgrades and integrate two other AHECs into our online library database application that was housed here at Wake AHEC.

We needed a quick method to update PCs throughout the building. That's when we began to seriously investigate the thin client model for providing library services to the reference floor in the Medical Library and to computing services throughout Wake AHEC.

Why Use Thin Clients?

The concept behind server-based computing is not new. Basically, server-based computing uses the resources of a centralized server to distribute applications to PCs or to Windows-based terminals (WBTs). These terminals receive screen updates and send keyboard and display information, but perform almost no local processing. Server-based computing allows people to avoid redundant setups, since the software is installed on the server once rather than on each user's PC. This feature is also important when software needs to be upgraded. Because thin client terminals need no processing power of their own, they do not have to be replaced every 18 months to 3 years as do PCs. Because these devices do not need memory or processor upgrades, we expect that they will last 5 years.

Furthermore, security is strengthened in this model because the server administrator can easily determine what functions users have access to, thereby preventing them from changing wallpaper or installing inappropriate software. Security is also heightened by using WBTs because they generally do not have disk drives or other storage devices. This prevents users from loading viruses or other potentially damaging software.

The Latest in Thin Clients

In the November/December 1998 issue of this magazine, Andrew C. White published an article explaining the state-of-the-art in thin client computing at the time. Naturally, quite a bit has changed since then. With the new Pentium-class machines and some of the improvements in the multi-user application program interface (API) of Windows NT, it is easier than ever to move to a server-based architecture. Even so, the "buy-in" costs of implementing a server-based solution are still significant.

When we made the decision to move to server-based computing, we considered two options. First, we could purchase Microsoft Windows NT 4.0 Terminal Server Edition, or we could purchase Citrix Metaframe 1.8. Both products use the familiar Windows NT 4.0 interface, but there are several important differences. The Microsoft product uses a protocol called Remote Desktop Protocol (RDP) to communicate with clients over a TCP/IP network, while Citrix uses the more efficient Independent Computing Architecture (ICA) protocol. But ICA has advantages other than efficiency. First, it allows administrators to "shadow" users' sessions, essentially controlling their interface remotely. Second, it allows for simple connection between local printers and the thin client. Third, it provides for load balancing between multiple servers, therefore more efficiently distributing the server workload if you have more than one server providing applications. There are other administrative advantages of ICA, but we felt that these were t he most important.

The bottom line, however, was that Citrix is expensive. Because of budgetary constraints, we chose to build our implementation on Windows NT 4.0 Terminal Server without Citrix Metaframe. We also discovered that Boundless Technologies has a free product called Citrix Device Services. This allows the terminals to connect using the ICA protocol, thus gaining most of the advantages of Citrix Metaframe.

The implementation of Citrix Device Services also reduced our support costs significantly. We shadow users' sessions to provide education and support, allowing individual users to change profile settings as needed. Also, since two of our sites are miles away, we can provide support for those users without leaving our location.

One hidden cost that we had to deal with was the training cost to IT staff. Windows Terminal Server (WTS) has a deceptively familiar interface. It took some time and effort to change the way we supported users. Here's an example: The oldest support trick in the world is to reboot the computer if an application fails to respond. With WTS, except in the most dire of circumstances, this is simply not an option. Support technicians must learn to troubleshoot problems without resorting to some of the old methods that are effective on a PC. Also, the registry becomes a much more important tool in designing the user environment. For many, manipulating the registry directly is an intimidating task. Our staff has learned to overcome this fear in order to better serve our customers.

We did some research before we bought our thin client dumb terminals. As you would imagine, Windows-based terminals are cheaper than PCs by approximately $500 per unit (about $750 each). After looking around, we purchased one of the cheaper models of WBTs, the Boundless Capio 325, which actually cost less than $500.

The money we saved on hardware devices was invested in more robust and powerful servers. We purchased Dell PowerEdge 4300s, configuring them with the fastest processor available at the time (a Pentium III-650) and 512 MB of RAM. Each server had a single hard disk. Since we were purchasing eight servers, enough for both the Medical Library and the physician practice, we knew we could survive the loss of any single server, thus we did not need any RAID configurations. Also, since the only information on these disks would be the program file typically run on a PC, space was not an issue. The servers cost approximately $9,000 each, so we could break even with a PC-based solution if we could have 18 terminals connect to each server. (The sizing rule of thumb for thin client computing has been that each processor could handle approximately 20 simultaneous users.) Since the servers were single-processor machines, we estimated our capacity at 160 users, including the 10 public access terminals in the medical library . This meant that, compared to a PC-based solution, we would save only a very small amount of money in the initial stages of the implementation.

The real savings in this scheme is due to the reduced support costs. Because so little is actually happening on the terminals, very little can go wrong. Most of the problems are related to the configuration of users' profiles on the server. Since these profiles are maintained centrally, our support staff has a single maintenance point and the ability to fix many users' problems with one action. For instance, if we need to upgrade an application for our users, we perform the installation once for each of our eight servers, rather than once for each of the 160 clients. This frees our support staff to handle more interesting and challenging problems.

We had begun our installation in September 1999, and we completed the upgrades in both the Medical Library and CARElina by November 1, 1999, in plenty of time to prepare for Y2K.

The cost savings for our organization was real, if not immediately realized. The story of our thin client computing could easily end there, but after becoming comfortable with our implementation, we began to see how it had changed our whole way of thinking.

Reaching Remote Desktops

As the name Remote Desktop Protocol implies, the very concept of the desktop has been freed from the constraints of the local PC. This provides many benefits and opportunities. We first used the concept of the remote desktop for our strategy to make services highly available. One of the great weaknesses of a thin client implementation is that it introduces a very significant "single point of failure" (SPOF). If something important on the server fails, instead of inconveniencing one user, now you have completely denied all services to many users. While we can build many fault tolerances into our server, machines have extremely inventive ways of destroying themselves. Our aim was to eliminate the server as a SPOF. We did this using the roaming profiles feature of Windows NT.

Basically, we save a user's personal information, desktop, printer configuration, and other important information on a centralized server. When a user logs on to a WTS, the information is downloaded to the WTS and when the user logs out, the information is copied back to the central server. So now what happens if a WTS decides not to work? Since all the users' information is saved somewhere else, that user can log on to a second WTS and not know the difference. Under certain configurations, users will need to be told which new server to log on to. We use a feature of Domain Name Services (DNS) to associate all the WTSs with a single DNS name. If one server were to go down, the users could double click on the same connection icon, and would be sent to a different WTS seamlessly.

Conceptually, the nature of the desktop becomes more fluid. Thin client implementations are fundamentally based on a three-tier architecture (see Figure 1).

At the top level, closest to the user, is the presentation of information. This is where the Windows-based terminal fits in the picture. The middle layer is where application processing actually takes place. This is where the Windows Terminal Server fits. The final tier is a data server, which may contain database information or user files. The files that make up the desktop become part of the data distributed to middle-tier servers, while the presentation of the desktop becomes more a function of the communication between the middle-tier and first-tier devices. For our library, this means that we can control both the presentation and the data that makes up the desktop merely by manipulating servers behind the scenes. It no longer matters which device a library client uses to view the information. We can preselect the best of the Internet and the best Windows application and present those to any user who can connect to our network.

In our earliest experiments, we delivered the library's preselected resources to users remotely located throughout Wake AHEC. These users would double click on a connection icon and then be connected to the very same desktop they would see if they were seated on the reference floor.

Because the profiles for our reference users are centralized, we can maintain control over the content and thwart the various attempts to add inappropriate resources to our library desktops. This has also greatly reduced the time we spend supporting the library's reference-floor computers.

Extending the Application

The final step in the evolution of our thin client implementation has been our move toward becoming an Application Service Provider (ASP). delineates the three characteristics of an ASP:

* Remote access serving for the users of an enterprise

* An off-premises local area network to which mobile users can be connected, with a common file server

* Specialized applications that would be expensive to install and maintain within your own company or on your own computer

In 1999, the AHEC Medical Libraries at Wake, Mountain (in Asheville), and Coastal (in Wilmington) formed a consortium to implement the Horizon integrated library system. The client requirements for Horizon are considerable. For example, in the year since we implemented it, the memory requirements have grown from 64 MB RAM to 128 MB RAM. To get around this, we offered our consortium partners the option of skipping the required hardware upgrades and connecting via the Internet to a WTS designated to distribute the Horizon application.

For our consortium partners, the advantages of doing this are that they can rely on our systems department to load all software upgrades. They can bypass the operating system requirements (Windows NT 4.0 or Windows 2000) of the application as well as the hardware requirements. The application is also faster using a terminal server. The disadvantages are that they have to print to a network printer and manipulate files at the server rather than on the local machine. For those sites that chose this option, the installation began and ended with the installation of a terminal services client, which took about 5 minutes. Once the connection was established, they received the Horizon application as updated and controlled by our systems department. This became absolutely critical when we entered into a beta testing agreement with epixtech, the Horizon vendor. Horizon client software was updated at least once a week, which would have been an enormous burden on our consortium partners. (These libraries are small with no IT staffs of their own.) Those who decided to connect via the terminal services client had no updates to install. The folks at Mountain AHEC have opted to continue on terminal server at all but the cataloger's workstation. The Coastal group preferred to print to local printers. Over the next year, we expect the consortium to grow from the current three libraries to eight libraries. We will continue to offer the application via terminal services.

In addition, at Wake AHEC we use something called Tarantella Enterprise II, which will deliver applications (whether Windows applications, terminal applications, or X11 applications) to clients via the World Wide Web. We can build a library "Webtop," which could include resources that are based on UNIX servers, mainframes, or Windows Terminal Servers. This gives us unparalleled freedom to choose the best applications for our clients. We can also make these services available to any client with a Web browser anywhere in the world that is connected to the Internet.

Modularity and Flexibility

The three-tier structure of our application services provides a great deal of flexibility. Essentially, we can assemble and disassemble the component parts of our network quickly and easily. For example, let's say that the library discovers a new database of medical information that would greatly benefit our users. This database has a typical client/server installation. Prior to our thin client implementation, our users would have to wait until our systems group could find the time to install the client piece of the software on each PC that was to have access. Depending on the application, this could have taken months! With thin clients, we can install the application just once for each server.

In addition, because the three-tier model is modular, we have a great deal of flexibility in network design as well. For instance, imagine that the database we referred to above becomes too large for its current file server. In a traditional client/server install, all the pointers to that file server would've had to be changed. This could potentially mean reinstalling each piece of client software, a very time-consuming task. With a thin client implementation, we would need to change the pointers to the third-tier database just once for each server.

As our new setup has grown, we've found ways to implement diverse network operating systems into the resource mix. For instance, we have a Health Education System that runs from a Novell NetWare server. The core of our WTS implementation is a Windows NT domain. With terminal services, however, we were able to install the client piece of the Health Education System on a WTS and then place a connection icon on our users' desktops. Essentially, they would log on to our WTS using the security of our Windows NT domain and receive a desktop with an icon for the Health Education System. Double-clicking this icon would take them to another WTS and log them in to the NetWare server. From this desktop, they could run the application. This allowed us to avoid doing an onerous installation of NetWare clients just so our patrons could use a single application.

Reaching Toward the Future

Now we have begun implementing a wireless network at Wake AHEC. This, combined with the rise of hand-held computing, has given us an unprecedented opportunity to build library resources directly into the patient care process. "The library" no longer needs to be a physical building, but can be a remote desktop distributed where it is needed. Our plans for the future include building a clinical desktop for physicians that would include library resources. This clinical desktop would be available at the patient bedside and could be integrated with the electronic medical record software used in the practice.

With the release of Windows 2000, opportunities for expanding our implementation have also grown. Terminal services are part of every Windows 2000 server, thus providing us with a clear upgrade path. In addition, Windows 2000's implementation of RDP has much of the functionality of Citrix Metaframe. Windows 2000 also includes an ActiveX Web client that provides some of the functionality of Tarantella. As we prepare for our Windows 2000 upgrade, we plan to move more of our resources for the entire Wake AHEC enterprise toward distribution via terminal services: Currently, we use thin clients to access Microsoft Office applications only in the Medical Library. We will soon be installing servers to distribute these applications via terminal services to our entire enterprise. In addition, we are implementing an electronic medical record in our physician practice, which will also be distributed via terminal services.

Because we now have the ability to change software implementations in a few hours instead of a few months, we can provide the services that our clients need with more speed and flexibility. With this we hope to change how our clients think of the library. Rather than seeing the library as a place to go to find information, we hope they see the library as an integral and integrated part of their daily routine. Our resources can be central to their daily work flow and can be presented in a way and at a time that is best for them.

So, were we prepared for Y2K? You bet! As a matter of fact, all the PCs were upgraded to either a thin client device or a new PC, and we were so confident of the success of this strategy that our systems support staff spent New Year's Day celebrating our success!

Susan C. Speer director of Information Resources at Wake AHEC in Raleigh, North Carolina, has 18 years' experience in microcomputing and library systems. Daniel Angelucci is the network administrator at Wake AHEC. He has a degree in philosophy from the University of Chicago and 6 years' experience in network design.
                              Cost Comparison
                            (costs and hardware
                          specifications gathered
                                May, 2000)
PC-Based Installation    Server-Based Installation
PC:                      Server:
Dell Dimension           Dell PowerEdge 4300
PIII - 700               PIII - 700
64 MB RAM                512 MB RAM
6.4 GB HDD               9.1 GB SCSI HDD
Standard Video           Win NT 4.0 TSE, 20 CALS
No Sound
$1,250/PC                $7,439.81/server
                         Boundless CAPIO 325
Total Cost for 20 Users: Total Cost for 20 Users:
$25,000                  $18,222.81
COPYRIGHT 2001 Information Today, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2001 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Technology Information
Author:Speer, Susan C.; Angelucci, Daniel
Publication:Computers in Libraries
Geographic Code:1USA
Date:Mar 1, 2001
Previous Article:Goin' Mobile: Using a Wireless Network in the Library.
Next Article:Cutting-Edge Statistics.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters