In 1992, Microsoft did something it had never done before. It licensed the source code to its Windows NT Server 3.51 operating system to a little-known company called Citrix Systems. Based out of Ft. Lauderdale, Florida, Citrix intended to take the source code and turn Windows NT Server into an application server.

By setting up NT as an application server, Citrix could enter the thin client marketplace with a best-of-breed product. At the time, thin client technology was emerging with mediocre results. One of the biggest disadvantages to the technology was that users had to learn a new interface.

Citrix saw the opportunity to revolutionize the thin-client marketplace. When its work was completed on the source code, it would bring to market a thin-client solution that had a Windows interface, which most users had become accustomed to. It would be true thin-client technology: All processing would occur on the server and would be able to run on many different platforms.

It’s been many years since Citrix created its solution, WinFrame. Microsoft has since licensed the code back and applied it to its Windows NT Server 4.0, providing a thin- client solution that has the Windows 95/98 interface. Called Windows NT Server 4.0 Terminal Server Edition, it is a technology that is finding its place in organizations of every size. And now with the advent of Windows 2000, Microsoft is shipping Terminal Server embedded in every copy of Win2K Server edition. Microsoft has changed the licensing strategy for Terminal Server and has dramatically improved application support and client support in the Win2K edition. In this article, you will see how this technology works and how it can benefit your organization.

What Is Terminal Server?

For most AS/400 customers, the best way to understand Terminal Server is to compare it with the AS/400. As odd as that sounds—comparing an IBM platform with a Microsoft platform—it actually makes quite a bit of sense. Terminal Server is an application server. It serves a data stream, which is rendered on the Terminal Server client in the form of a

Windows-based desktop. All the same qualities exist for this data-stream-rendered desktop, including the infamous Start button, icons, context-sensitive help, and all applications that are loaded onto the Terminal Server.

All processing occurs on the Terminal Server. Any mouse movements or keystrokes from the client are sent to the server to be processed. All new applications are loaded on the Terminal Server, not on the device connected to the Terminal Server, and the results of the server processing—screen displays and printouts—are sent back to the requesting client to be viewed or printed. Administration occurs on the Terminal Server, and any patches to the applications are viewed by the user the next time they log in.

Connecting to the Terminal Server can be a thin-client hardware device or a small piece of software that runs a Terminal Server session within a window. This software is available for Windows, Apple, UNIX, and Linux and can be embedded within a Web browser.

Compare this now with the AS/400. Before the AS/400 became a Domino server, a Web server, and an ODBC data server, it was strictly an application server. PC5250 terminals would connect through a twinax connection, or PCs would connect through a network. A PC5250 data stream would be sent to the device from the AS/400, and the screen would be rendered on the device. This would take the shape of the block mode interface to which we’ve become so accustomed.

The point to remember is that the AS/400 provided all the brains. When the user hit the Enter key or one of the function keys (F1 to F24), all the data on the screen would be sent to the AS/400 for processing. The results would then be sent back to the terminal for rendering. It’s somewhat ironic that the AS/400 started out as an application server and expanded, while NT Server has been out on the market for several years but has just recently started to function as an application server.

Now the two platforms offer very similar functionality in terms of application serving. Both platforms provide central administration, server-based processing, and a low total cost of ownership. And, with the installation of Independent Computing Architecture (ICA), an add-on product by Citrix, you can serve Terminal Server out to as many different clients as with the AS/400.

To ICA or Not to ICA?

While part of the emphasis on Citrix has been removed as Microsoft markets and sells Terminal Server, Citrix still plays a key roll. When Citrix was originally re-creating the NT operating system as an application server, it also created the ICA protocol. Like the PC5250 data stream, ICA handles the rendering of screen images on the client computer and information transfer to and from the server.

When Microsoft released Terminal Server, it included its own version of ICA entitled Remote Desktop Protocol (RDP). True to form, Microsoft’s implementation of RDP lagged behind Citrix’s ICA, required more bandwidth, and supported only Windows- based clients. Citrix also significantly enhanced ICA at around the same time that Microsoft released Terminal Server.

Some of the new features that Citrix included were the ability to print directly to locally attached printers, lower bandwidth requirements, an encryption add-on, and a bevy of other options that provide a robustness unparalleled in any other thin-client implementation.

So how do you get Citrix ICA support on a Terminal Server? Well, Citrix sells a Terminal Server add-on product called MetaFrame that provides all the benefits of ICA. As shown in Figure 1, MetaFrame installs on your Terminal Server and communicates directly with the Terminal Server operating system. This provides a way of bypassing the RDP protocol, which can be beneficial in many scenarios.

So in what instances would you decide to use the ICA protocol? In my opinion, you would always want to use the ICA protocol. ICA demands less from your network,

can be used from within DOS or UNIX, and can even be embedded within a Web browser. Similar to RDP, you can run ICA from legacy-based PCs and still receive great performance that’s dependent on how your server is sized. Also, you have native audio support, meaning that if your client device (PC, Network Station, etc.) has a sound system, the audio from the applications installed on the Terminal Server will be heard on the client device.

In reality, budget woes may stop the purchase of MetaFrame. Depending upon the number of users connecting to the Terminal Server, it can become expensive. See my sidebar, “Terminal Server and MetaFrame Licensing,” on the MC Web site at www.midrangecomputing. com/mc/.

Although you can install MetaFrame after the original server and client installation, it is best to do it up front if you intend to do it at all. Also, client devices require a different application to connect to the server through ICA. If you install MetaFrame during the initial server and client installation, you will avoid going to your client workstations twice during your rollout.

Integration into the AS/400 Environment

The easiest way to integrate Terminal Server into your environment is simply to install one of IBM’s Client Access for Windows products. (For more information on running Client Access under Terminal Server, see “See Client Access Run—on Windows TSE!” Jeff Van Heuklon and Ana Tomko, MC, July 1999.) Every device connecting to Terminal Server will then be able to connect to the AS/400 through a PC5250 green-screen, graphical access, Operations Navigator, or even ODBC. The only task required of your department is configuration of the AS/400 connection(s).

Client Access can be substituted for many Windows applications that provide AS/400 access. One primary benefit of this is that your Terminal Server can be placed in close proximity to your AS/400, allowing all communications between the two systems to be on the same network. WAN-connected devices speak only with the Terminal Server, and the bandwidth considerations are minimal. Bandwidth-intensive applications will actually perform better in this environment, as only keystrokes, mouse movements, and print data are sent over what could be slow WAN links.

One downside is that Terminal Server can be very sensitive to the applications you install. Do the legwork up front and ensure that the applications you run in-house have been tested to run on Terminal Server. I have just run into this with VisualAge for RPG (VARPG). IBM has not tested it with Terminal Server and will not say that it works. Because of this, VARPG will not be installed on Terminal Server in our organization.

Other Pros and Cons

Having used Terminal Server for the past year and a half, I have come into contact with all that it has to offer—the good and the bad. Knowing up front what it has to offer will help you initially sell the technology to your superiors and avoid common pitfalls down the implementation and support road.

The Good News

Let’s get to the good news before the bad. The pros are as follows:

• Central administration—An AS/400 environment that has gone to PCs allows IS to regain control in a central server. Many AS/400 shops hesitated to adopt PCs, as they were used to doing everything on the AS/400, and were not familiar with installing or willing to install applications on many different systems. Terminal Server allows you to install your Windows-based applications on the server and maintain them there. If there is a new version or a fix to an application, you install it once—on the server. You are not required to go to every system and apply the fix.

• Lower cost of ownership—Having a central server serving your applications saves you time, period. Using complex formulas, the total cost of ownership (TCO) applies a cost to your man-hours. Your man-hours are significantly reduced with the central administration features of Terminal Server, thereby reducing your TCO. When pitching a Terminal Server solution, you can use the reduced TCO to develop an ROI scenario that will be much less than two years in most cases. In addition, because your client devices do little or no processing, they are easily interchangeable. If there is a hardware problem, simply swap out the faulty machinery, and the user will still have the same user interface as on the previous device.

• Lower learning curve—Terminal Server puts a Windows 9x desktop on the client device. A majority of consumer PCs ship with one of these two operating systems. Users who have home computers (roughly 40 percent of American households have a home computer) know how to get around Windows 9x and will not have to be trained on the desktop. This leaves you more time to construct your line of business applications.

• Predictable bandwidth—Certain materials on Microsoft’s Web site indicate that users will typically consume 2.5 kilobytes per second (KBps) to 6.0 KBps of bandwidth when using Terminal Server. In reality, that figure should be more along the lines of 16 KBps to 64 KBps, depending upon the computer literacy of the users and how fast they can type. This is still a relatively low figure when compared with the current computer application marketplace. With Terminal Server, the bandwidth consumption is fairly steady—there is always data moving back and forth. It is simply optimized for low-bandwidth connections. Installing a PC with AS/400 software, email support, Web browsing, and other database applications is typically a “bursty” implementation. Every time a standard PC performs a network task, there is a high bandwidth requirement for a short and sporadic period of time.

• Wider client support—With the addition of Citrix MetaFrame, users can connect with thin clients, Macs, Windows desktops, DOS, UNIX, Linux, and anything else you can think of. The greatest thing about this is that the interface will always be the same. You can have a user communicating with a Terminal Server on a Linux workstation using Windows- based applications—all running on the server!

The Bad News

At some point, I must bring out the bad news. The only consolation I can provide is that knowing these drawbacks is half the battle! Preparing yourself for the following cons will lessen their effect on your network:

• Less application support—There is a certain harmony that you must ensure when installing applications on Terminal Server. A stray application can bring down your entire server and lead to downtime for your users. Each application you consider installing must be researched. Be sure that the vendor has tested it successfully on Terminal Server. If the vendor hasn’t, do not install it. Terminal Server supports fewer applications than a typical Windows PC, and you must know ahead of time what works and what doesn’t. One other item to remember is that DOS applications do not run well on Terminal Server. Stick to true Windows-based, 32-bit applications.

• Central point of failure—If your Terminal Server fails, then your users will not be able to work. This is a painful truth that must be considered and planned for. Those of you with big budgets will be able to benefit from clustering technology that is currently available for

both Windows NT Server and MetaFrame. If you can afford it, do it. The cost will be less for the additional hardware than for all the man-hours lost during a server outage.

• Hefty server requirements—You have to consider that if you have 10 users running on a Terminal Server at one time, there are 10 Windows desktops that must be maintained by one server. This translates into a lot of RAM, disk, and processing power. Also, because this architecture creates one central point of failure, you should have RAID disks, redundant power supplies, and everything else available. Microsoft has some white papers and information on its Web site that relate to server sizing. Whatever you read, consider doubling it. I personally recommend 32 to 64 MB of RAM per user, one Pentium III-based CPU per 15 to 30 users, and the fastest and largest disk you can find that is RAID-5- protected. Always oversize because you don’t always know what applications will be installed in the future.

• Expensive initial procurement cost—This comes into play because of the hardware requirements listed above and the licensing that is associated with Terminal Server. The details of licensing are visited in my sidebar at www.midrangecomputing.com/mc/, but what I can say outright is that it is expensive. Couple the expense of the licensing with the expense of the server hardware, and you may have a tough sell to upper management.

Looking Back

The dust has had a year and a half to settle, and now that all is said and done, I am very pleased with Terminal Server. Though I experienced some minor software hitches along the way, which required an actual reinstallation, I still stand behind Terminal Server as a very viable platform.

For me, the most impressive aspect was the installation of Client Access for Windows 95/NT. The early days of getting Client Access for Windows 3.11 to work under Windows 95 had left me somewhat afraid of this stage. Much to my delight, however, the installation ran perfectly, and I haven’t had a problem with it yet. I recommend that if you install Client Access, you communicate with your AS/400 using TCP/IP. I have not heard of anyone using the SNA NetManage NS/Router.

Throughout the last 18 months, we have seen our Terminal Server implementation evolve from enabling a small satellite location of five users to serving a specialty application to 15 users over a slow WAN link (256 KBps). In the future, we are looking to use it to provide virtual private networking (VPN) and extranet capabilities to closely held external entities.

Windows 2000 now has Terminal Services built into the core of the operating system, which will provide better stability and more performance. I expect that as our use of Terminal Services continues to evolve, Windows 2000 will ensure that we do not reach a ceiling. Windows 2000 also changes some of the restrictive licensing aspects of publishing single applications over the Internet, which will probably lead to early adoption of Windows 2000 for terminal services rather than Windows NT Terminal Server.

With Terminal Server only getting better, you will find that it can complement your AS/400 environment while being more like your AS/400. Call it a return to a much simpler time!

References and Related Materials

• Citrix MetaFrame for Windows 2000 Servers home page: www.citrix.com/products/metaframe/

• Citrix Systems Web site: www.citrix.com

• Microsoft Web site: www.microsoft.com

• Microsoft Windows NT Terminal Server Edition home page: www.microsoft.com/ntserver/terminalserver/default.asp

• “See Client Access Run—on Windows TSE!” Jeff Van Heuklon and Ana Tomko, MC, July 1999

• “The Dumb-Terminal-to-IBM Network Station Replacement Roadmap,” Ed Krath, AS/400 Network Expert, September/October 1999

Terminal

Server MetaFrame ICA

Terminal Server RDP

Thin Client Laptop

Mac Workstation Linux

Figure 1: Terminal Server provides a Windows desktop on many different clients over many different networks.

Modem Ethernet/ Token-Ring Frame Relay/ATM

Internet Wireless

ICA

RDP