The ultimate purpose of remote access services in a network is to provide remote users access to LAN-based resources. Although traditional RAS connections, such as those that Windows 2000 and Windows NT provide, work well for basic user connectivity needs (e.g., email, Web browsing), problems arise when you try to extend this usage to let users remotely access business productivity applications. The cause is limited bandwidth. A huge chasm exists between applications that work well over low-bandwidth RAS links (i.e., 24Kbps to 128Kbps) and applications that expect LAN-style connections (i.e., 10Mbps to 100Mbps). Passing over a RAS link the large executable or data files that most applications use is too time-consuming to be practical. This limitation isolates RAS users from most network resources. This constraint is even true of PPTP-based RAS connections over faster connections, such as T1 lines, Digital Subscriber Lines (DSLs), and cable modems.
A popular solution to this problem is to combine RAS with remote control software. An advantage of these applications is that they're fairly inexpensive and provide users with full access to office-based PC and LAN-based applications. These products work well over low-bandwidth links because they pass only screen and keyboard data over the remote link rather than an application and its data. A disadvantage is that they require users to completely take over the remote PC on a one-user-to-one-computer basis, which isn't cost-efficient.A better solution is to deploy remote control through thin-client products. These solutions offer users the benefits of remote control, manageability, and the ability to host many sessions per server. Terminal Services is a particularly attractive solution because it's available on any version of Win2K Server. You simply install Terminal Services, acquire a license, and you're ready to go.
Although Terminal Services sports respectable performance and a decent feature set, the introduction of Win2K Service Pack 1 (SP1) takes Terminal Services to a new level of usefulness. The service pack isn't responsible for this improvement; the benefactor is a hidden gem on the SP1 CD-ROM called the Terminal Services Advanced Client. TSAC provides what has been a missing link in the RDP equation: a Web-based RDP client, which TSAC provides as an ActiveX control (i.e., a COM object). Until TSAC, using Terminal Services has meant installing and using the client that Win2K includes. This setup is fine if you're accessing Windows applications on the company network from your laptop or home PC. But what if you have only a Web browser available? To offer users Web-based terminal server access, you had to purchase a third-party Web-based solution (e.g., Citrix's pricey MetaFrame add-on for Win2K or NT's terminal services and a corresponding Web-based ICA client). Although Citrix's solution is powerful and robust, its cost is beyond the reach of many organizations. With TSAC, Microsoft provides a free RDP Web-access solution for Terminal Services.
You can install TSAC from the Win2K SP1 CD-ROM's \\Valueadd\Tsac folder or download the tool from http://www.microsoft.com/ windows2000/downloads/recommended/tsac. (This tool isn't part of the service pack installation and doesn't come with the Web-downloadable version of SP1.) Setting up TSAC is a simple task that involves installing the TSAC Web package on a Microsoft IIS 4.0 or later Web server. (This server doesn't have to be the system running Terminal Services.) When clients use Microsoft Internet Explorer (IE) 4.0 or later browsers to connect to the IIS server, the system will ask whether they want to download and install TSAC. If they say yes, the system displays a basic Web page that lets users enter the name of the terminal server to which they want to connect. If you install TSAC on a Web server that isn't the terminal server, the IIS server hosting the TSAC files acts only as a client distribution and access gateway—the actual terminal server connection will be directly between the client and the terminal server. As a result, make sure that you properly configure your firewall to permit the traffic required for a TSAC connection. To do so, permit port 80 (HTTP) traffic to any IIS servers hosting the TSAC HTML files and port 3389 (RDP) traffic to any terminal servers that you want TSAC-based clients to connect with. TSAC is an amazingly powerful yet simple tool for your remote access toolkit—I recommend checking it out.
