Putting Terminal Server to Work

MANY HATS FIT THIS OS

DURING THE PAST YEAR, MICROSOFT HAS INTRODUCED ITS CUSTOMERS TO WINDOWS NT SERVER 4.0, Terminal Server Edition. Terminal Server's code evolved from a beta to a final release. The product's white papers appeared on Microsoft Web sites. And the Terminal Server Microsoft Official Curriculum (MOC) courseware became available. (For more information about Terminal Server and the product's development, see "Related Articles in Windows NT Magazine," page 120.) However, many network administrators remain unaware of Terminal Server's capabilities. In speaking to network professionals about Terminal Server and thin-client technology, I have heard many comments such as "I haven't implemented Terminal Server because I don't want to replace my PCs" and "I thought I had to use network computers (NCs) to connect to Terminal Server."

You can use Terminal Server to replace your PCs and create a purely Windows-based terminal network. The Terminal Server model in which all of a company's business applications reside in a central repository and users access those applications via Windows-based terminals comes to many administrators' minds when they think of thin-client solutions. But thinking that a Terminal Server network can contain only Windows-based terminals seriously underestimates the OS's possibilities. Terminal Server is most powerful when you run standard, Microsoft Office-type applications on your network's PCs but move your company's business-critical applications from local hard disks to a central server.

My company, QA Training, runs a mixed network that includes Terminal Server. Since my company installed the new OS, I have discovered several interesting possibilities for this technology. Installing Terminal Server on certain crucial NT systems can provide you with functionality that a standard NT implementation doesn't offer.

Central Web-Download Server
The castle that is QA Training headquarters in Cirencester, England, has a 2MBps link to a local Internet Service Provider (ISP). This link is the company's primary Internet connection. Its 2MBps is usually adequate; however, major downloads of Web content can overload the connection at particularly busy times, such as when the company is running several Internet fundamentals courses.

Before Terminal Server, I overcame my company's limited bandwidth by coming in early whenever I needed to download large files from the Internet. As long as the downloads finished before classes started, they didn't strain the company's ISP connection. However, this solution required me to arrive at the office at around 7:00 a.m. I'm not a morning person, so I was happy to discover that Terminal Server offers another solution to my download problem.

I installed Terminal Server on my office server. Now, whenever I need to download a large file, I can dial up the company's Remote Access Service (RAS) server from home at 7:00 a.m. After I connect to the RAS server, I start a session on my Terminal Server system and fire up Internet Explorer (IE) within that session. I then download the file as I would if I were surfing the Internet on my home computer, but I save the file to the Terminal Server system's hard disk. (I can also save the file to a network drive on another server.) After I start the download, I disconnect the RAS session. My Terminal Server machine continues to download the file, and I return to my breakfast. When I arrive at the office, I connect to the Terminal Server system via my office PC and retrieve the downloaded file from the server's hard disk. Figure 1 illustrates the network configuration that makes this type of download possible. Because Terminal Server is the same price as standard NT Server 4.0 with 10 Client Access Licenses (CALs), and because I already used Windows NT Workstation 4.0 on my home computer and my office PC, this solution cost me nothing extra.

If you want to implement this solution and plan to use it often, consider adding Citrix's MetaFrame extension to your Terminal Server configuration. MetaFrame includes the Independent Computing Architecture (ICA) protocol, which uses bandwidth more efficiently than the Remote Desktop Protocol (RDP), which Microsoft supplies with Terminal Server. In addition, MetaFrame lets you bypass your RAS server by dialing the Terminal Server system directly. Terminal Server is faster via this type of direct connection, and you can set your ICA client to automatically dial the Terminal Server system when you click an icon on the desktop. (For more information about MetaFrame, which Citrix originally named pICAsso, see Mark Smith, "Thin Client/Server Computing Works," November 1998, and John Enck, "Spawn of the Hydra," March 1998.)

Internet Access Through Terminal Server
After I began to use Terminal Server for Web downloads, I realized that this solution opens up other Terminal Server possibilities. One of these possibilities is regulation of users' Internet access.

If you are considering providing Internet access to your network's users, you face a daunting task. You can configure firewalls, routers, and antivirus software to help mitigate the Internet's security risks, but none of these solutions lets you control your users' access to the Internet. However, if you route your network's Internet traffic through a Terminal Server system, you can clamp down on Internet access and reduce your company's exposure to security risks.

Figure 2 shows a network in which clients access the Internet through a Terminal Server system. To create such a network, set up a Terminal Server system with two NICs. (Before you set up service packs on a Terminal Server system, see the sidebar, "A Word of Warning.") Disable IP routing on the Terminal Server machine by clearing the system's Enable IP Forwarding check box on the Routing tab in the Microsoft TCP/IP Properties dialog box, which you reach by selecting Protocol, TCP/IP Protocol, Properties in Control Panel's Network applet. Then, install IE on the Terminal Server machine. (If you are using IE 4.01, make sure you install it without the Active Desktop components; Active Desktop isn't compatible with Terminal Server's multiuser desktop. The version of IE that comes on the Terminal Server CD-ROM does not include Active Desktop.)

After you configure IE on the Terminal Server system, you can use the Client Connection Manager (CCM) to configure the connection icons on individual client machines. CCM installs as part of the Terminal Server Client installation routine; CCM lets you set up different properties for each connection. Start CCM on your Terminal Server client. Select File, New Connection. A wizard walks you through the client configuration.

In the wizard's first window, you provide a description of the connection and specify the name of the Terminal Server system you want to connect to. In the wizard's second window, you can set up the client to log on to the server automatically by specifying a username, password, and domain. If you want to let the user enter this information, leave the Automatic Logon box empty, and click Next. In the wizard's third window, you configure your client's display options. In the wizard's fourth window, you specify which application opens when the client's Terminal Server sessions begin. Enter the path to the Terminal Server's version of IE (e.g., D:Program FilesPlus!Microsoft Internet) so that your users will see only IE in their Terminal Server sessions. The wizard's fifth window lets you change the icon that opens Terminal Server on user desktops. Click Change Icon, and browse to find the IE icon. Then, click OK, Next, and Finish to complete the client desktop configuration.

When your users select the IE icon, their machine will open IE on the Terminal Server system—instead of the local machine—and iexplore.exe will replace explorer.exe as the shell in the session. When a user closes IE, the user's Terminal Server session ends. Alternatively, you can use the Terminal Server Connection Configuration program to set up your server to open IE automatically when any client starts a Terminal Server session, rather than setting up the IE icon on every client system. Or, you can set the Terminal Server system to open IE every time a specific user starts a Terminal Server session via the server's User Manager for Domains.

These methods configure Terminal Server to open IE without showing users the Terminal Server system's desktop, but they don't stop users from accessing files on the Terminal Server system's hard disk. A user on a client system can enter file:/C: in the browser's address bar to browse the server's hard disk. Therefore, you need to install Terminal Server only on NTFS partitions so that you can use file permissions to lock Internet users out of crucial local files.

In addition, you can use the Application Security utility that comes with Terminal Server to let only applications that you specifically approve run in a server's Terminal Server sessions. To open the utility, select Application Security from the Administrative Tools menu on the Terminal Server system's desktop. Screen 1 shows the Authorized Applications list box that appears. Select the Enabled option button in the Authorized Applications list box's Security section. Select Add and add the path to iexplore.exe in the Add Authorized Application dialog box. Remove from the Authorized Applications list any applications you don't want users to be able to run in Terminal Server sessions. Terminal Server will check each application that a user tries to run in a Terminal Server session against this list. (Application Security doesn't affect application access for members of the Terminal Server system's local Administrators group.) After you set up your Terminal Server machine to provide clients access to IE, you can use your users' standard NT accounts to restrict their access to the Internet and to limit the hours users can log on to the Terminal Server system (and thus the hours they can use the Internet).

After Microsoft releases Windows 2000 (Win2K), you might be able to take this approach to Internet access a step further by using Routing and Remote Access Service (RRAS) to turn your Terminal Server system into your network's Internet router. (For information about using RRAS as an Internet router, see Douglas Toombs, "Poor Man's Firewall," December 1998.) Terminal Server doesn't currently support RRAS; I have tried to make RRAS work on the OS, but Terminal Server's kernel-mode routing tables don't seem to accept the static routes that RRAS requires for a server's second NIC. However, Win2K Advanced Server (Win2K AS) will come with both the Terminal Server and RRAS services, so running RRAS on a Terminal Server system will probably be a viable option under Win2K AS.

Going to Jupiter with Windows CE
I've had a pipe dream since I first started using Terminal Server, and my dream now looks like it might become a reality. I envisaged a sub-notebook computer with a decent-sized color screen, a usable keyboard, a NIC, a modem, Windows CE versions of Office applications, and a Windows CE version of CCM. Such a system would let users work with the Office applications offline on a notebook that boots almost instantly. Then, when the users needed more serious business applications, they could use CCM to connect to their Terminal Server system and run any NT application. The device could use a built-in modem to dial in to the Terminal Server system or connect to the server's LAN via a PC Card NIC.

This dream became more realistic when Microsoft announced a new form factor for Windows CE devices, which the company code-named Jupiter and which now has the snappy title Windows CE Handheld PC, Professional Edition. (For information about this new version of Windows CE, see http://www.microsoft.com/windowsce/hpcpro/default.asp.) Citrix already produces an ICA client that lets handheld PCs connect to MetaFrame. At press time, Microsoft produces no RDP equivalent. Only Windows-based terminals, such as NCD ThinSTARs, can use Microsoft's RDP client for Windows CE; you can't install the RDP client on handheld PCs that run Windows CE Professional, because the RDP client runs only as embedded code. However, if Microsoft releases an RDP client for Windows CE Professional, handheld PCs that can connect to Terminal Server systems will make powerful devices for the mobile professional.

Finally, the Future
This article provides an example of a different way in which companies can use Terminal Server to expand NT's functionality. For a few more suggestions of Terminal Server uses, see the sidebar "Food for Thought." Because of these approaches and because of Terminal Server's potential reduction in networks' total cost of ownership (TCO), increasing numbers of firms are adding Terminal Server to their networking environment.

I predict that 1999 will be the year of Terminal Server technology. I can back up this prediction with two facts. First, many companies will use Terminal Server as a major component of their Year 2000 (Y2K) solution. Most of these companies have run pilot projects during the past few months, and many are starting their Terminal Server rollouts now. Second, Terminal Server will come bundled as a network service in Win2K AS, so every Win2K AS server will be able to run the Terminal Server service. And Win2K AS's Terminal Server service will offer more features than Microsoft's current RDP clients offer.

What do NT administrators need to know about Terminal Server? You need to understand that the OS is here to stay. You'll almost certainly have to run Terminal Server in the future (if you're not already running it). I hope this article will inspire you to look into Terminal Server's possibilities sooner rather than later.