Windows 2000 Terminal Services RC1

A tool for implementing terminal services in your network

Microsoft's July 1998 release of Windows NT Server 4.0, Terminal Server Edition (WTS) was the company's entrance into supporting multiuser NT 4.0. Unfortunately, WTS was bound to disappoint anyone experienced with Citrix WinFrame, a standalone product that turned NT 3.51 into a multiuser program. WTS lacked WinFrame's functionality and provided only basic functionality for Win32 and Windows CE-based terminals. To match WinFrame's functionality, you needed to buy Citrix MetaFrame (to use client-side audio I/O and session shadowing and to access client-side COM and LPT ports) or install NCD ThinPATH Plus (to get support for client-side audio I/O and redirect client-side COM, LPT, and Universal Serial Bus—USB—ports).

All three server versions of Windows 2000 (Win2K—i.e., Win2K Server, Win2K Advanced Server—Win2K AS— and Win2K Datacenter Server—Datacenter) will add new functionality to the core Windows terminal services. Changes in the RDP that Win2K Server Terminal Services uses will add features that WTS's RDP version doesn't have. Other products, such as MetaFrame and NCD ThinPATH Plus, will still provide capabilities that Terminal Services doesn't provide, but WTS users will welcome Terminal Services' changes.

Windows-based terminal services aren't new, and the functionality in Terminal Services isn't unique. However, Win2K represents the first time that Windows makes support for server-based computing an intrinsic part of the OS. Terminal services are the same as any service that you turn on or off, making them another handy tool in the OS. And they are handy.

Why Use Terminal Services?
If you're moving to Win2K Server, many reasons exist to seriously consider adding terminal services to your network. First, because terminal services don't have stringent client-side hardware requirements, you can run Win2K on client machines that wouldn't otherwise be able to run this demanding OS. Terminal services let you access the Win2K interface without updating the requisite hardware on every client desktop. Second, people running applications from a terminal server can use Windows-based terminals (WBTs) to run Win32 applications. Doing so brings PC functionality to users who work in an environment not congenial to PC usage, such as mobile users or users who must work in dusty places. Third, many people use several computers, rather than relying on one desktop computer. If these users run some or all of their applications from a terminal server, they can be sure of having access to the same suite of applications wherever they are, even if they're using a hand-held PC that can't run full-fledged Win32 applications. Fourth, centralized application deployment makes it easier for a central office to support computer users in branch offices that might not have local administrators to help the users install or upgrade applications. Finally, even if you don't need terminal services for application serving, terminal services provide an easy way for you to remotely administer a Win2K server without having to be present at the console or load remote control software.

The Latest in Terminal Services
Excepting the differences that exist elsewhere between Win2K and NT 4.0 in the user interface (UI), at first glance, terminal services in Win2K and WTS look similar. Both versions have command-line and graphical-management tools that you can use to manage sessions from the console (or from a terminal connection), and both install applications in such a way that as new users connect to the applications, a set of default settings passes to the per-user Registry settings for further customization without interfering with other user settings.

Win2K's terminal services aren't just a rehash of WTS's capabilities. First, terminal services are a part of Win2K, just as Internet Information Services, DHCP, or any other optional part of the OS is part of Win2K. Terminal services is no longer a companion product to the core OS but are part of the core. Second, RDP in Win2K supports communication between client and server—or between client and client—that RDP in WTS didn't support. This support means you can now take control of one session from another session (a feature that MetaFrame calls shadowing and Win2K calls remote control). Local and remote applications now share a Clipboard so that, for example, you can copy text from Microsoft Word running in a terminal session to Notepad on the local machine. Clients can now use automatic printer redirection with Win2K, NT, or Windows 9x clients to print to their locally connected COM or LPT printer from a terminal session, or they can manually redirect the printer from the terminal server for WBT and Win16 clients. Win2K improves bitmap caching, which accelerates screen redraws on the client. RDP still runs only with TCP/IP and supports only Win32 clients, but the new features enhance RDP's usability. To see what Win2K doesn't yet provide, see the sidebar "What's Missing in Terminal Services?" page 112.

Installing Terminal Services Support
Installing support for terminal services on the server is a matter of adding one more service. During Win2K setup, the OS prompts you to select additional services. Two of these services are Terminal Services and Terminal Services Licensing (you can run the licensing service either on the Win2K Server computer providing terminal services or on another Win2K domain server). Make sure that you select all the services you want to install to add all multiuser capabilities. The setup program lets you install terminal services as an administrative tool (giving you two connection licenses for administrative purposes) or as an application server.

To add terminal services support after installing Win2K, go to the Control Panel Add/Remove Programs applet. Select Add/Remove Windows Components in the opening screen to start the Windows Components Wizard. You'll see a list of available components to add or delete, as Screen 1 shows. Select Terminal Services and click Next. (Terminal Services Licensing is another component in this list. You don't need to install this service on the terminal server, but you do need to install it on a Win2K domain controller in the Win2K domain or on a Win2K member server in an NT 4.0 domain to keep track of license usage.) In the resulting screen, Setup asks whether you want to install terminal services in remote administration mode (which permits only two administrative connections to the server and is only for remote administration purposes) or application server mode (the mode you'll need to let people access applications from the terminal server). After Win2K installs and configures Terminal Services, the software prompts you to close the wizard and reboot. When you restart the machine, the terminal server administration tools will appear in the Programs folder's Administrative Tools section. If you install terminal services in application server mode, the server will be tuned to give more CPU time to applications running in the foreground.

You still need to deliver the RDP client to the PCs and hand-held PCs that will use terminal services. (WBTs with Windows CE or NT Embedded 4.0 will have RDP support installed.) You can install this support either by creating installation disks from the terminal server or by sharing the RDP setup files on the network. You can deliver RDP to the PC in two ways—by using the Terminal Services Client Creator terminal services component or by using Microsoft Systems Management Server (SMS) or other software-publishing techniques.

The Administrative Tools program group contains the Terminal Services Client Creator, which opens the Create Installation Disks dialog box that Screen 2 shows. Terminal Services Client Creator is as cumbersome in Win2K as it is in WTS. Win16 clients need four 3.5" disks to hold all the setup files, and Win32 x86 clients need two 3.5" disks. Regardless of how many disks the client requires, you have to walk back and forth to install client-side RDP support. If you could create setup files on a medium other than 3.5" disks, using the Terminal Services Client Creator might make more sense, but 3.5" disks are the only allowable medium. Clients with network connections to WTS can simplify the RDP installation process by sharing the contents of the %systemroot%system32 clients et directory.

The Net folder contains three folders, each of which holds the installation files for one RDP client type: Win16, Win32 Alpha, or Win32 x86. To set up RDP client support, open the folder containing the appropriate setup files and run a short setup program. Supply the username and your company's name, agree to the licensing requirements, and choose a new destination directory for the files if you don't like the default directory. After you begin the copying process, a message box will announce a successful client installation. Click OK. You can now use the client in the Terminal Services Client program group on the Win32 client—no reboot is necessary.

What if WTS's RDP version is already installed on the client side? Technically, you don't need to upgrade the display to connect to the Win2K terminal server, but upgrading is a good idea. You can't reap the full benefits of Terminal Services' capabilities without the Win2K client. Win2K's terminal services use RDP 5; WTS uses RDP 4. If you want the complete functionality that Win2K's terminal services promise, you need to upgrade the client-side protocol to RDP 5. For example, a discrepancy in RDP versions prevents me from using a client-side printer on my NCD ThinSTAR 300. The RDP client on the NCD ThinSTAR 300 is version 4, and RDP 4 doesn't support the data transfers required for client-side printing. I'll need the updated RDP client for Windows CE, when it's available, to support printer redirection.

Getting Connected
As does WTS, the Terminal Services Client program group includes two tools that clients can use to connect to the terminal server. The Terminal Services Client tool that Screen 3 shows offers default connection settings to all terminal servers in the domain or in trusted domains. Select a server from the Server list and choose the screen resolution you want the client session to use (or the resolution that the client's desktop is using). If the server you want isn't listed, try typing its IP address in the Server drop-down list box. Click Connect, and the client should find the selected terminal server, display a logon screen for users to supply their usernames and domain passwords, and begin a session. However, if the session doesn't work for some reason, the error-reporting feature doesn't help much. Regardless of the problem, error reporting always reports that the terminal server is too busy and the user needs to try again later—which sounds like an invitation to bug the Help desk.

The Terminal Services Client is easy to use, but you might need to change the default settings. To set up client custom settings, go to the Client Connection Manager, which Screen 4 shows, from the Terminal Services Client program group and choose File, New Connection. When you create a new client, you're prompted for the server's name and IP address (you can identify a terminal server by either), username and domain password, and session display settings, such as screen resolution. You must also use the Client Connection Manager to run one application in a terminal session, rather than display the entire desktop. The client information is easy to configure, and running the Client Connection Manager wizard will save that session information with a user-defined name so that you can use the information again. When you finish using the wizard, the client information is ready to use.

You can reuse connection information on another computer by saving the connection to a file. Highlight the connection in the Client Connection Manager and select File, Export. Create a filename and click Save. When password information is part of the connection settings, the program asks whether you want to save the password with the connection's configuration information. If you save the password, anyone logging on to the terminal server with that connection will use that password for authentication. The saved exported connection has a .cns extension and is approximately 1KB. You can import the file from another PC's Client Connection Manager.

Managing Terminal Sessions
After you configure the client, you might need to do more configuring on the server side. First, what access to the terminal server should domain users get? Win2K supports optional but useful settings that let you define how long a session lasts, whether someone can take remote control of a user's terminal session (a capability previously available only with MetaFrame), and how to configure the RDP protocol, client path, and profile information. You can also selectively disable client access to locally connected devices if you don't want the automatic printer redirection to work for some users. To access these settings, you must configure the client's domain account properties from the Local Users and Groups (for servers) or Active Directory Users and Computers (for domain controllers) tools in the Microsoft Management Console (MMC). The settings you're looking for are on the Remote Control, Sessions, Environment, and Terminal Services Profiles tabs of the user accounts properties page. Unfortunately, Win2K requires you to configure user accounts individually, rather than in groups.

To apply security settings to anyone accessing the terminal server with RDP, you need the Terminal Services Configuration tool in the Administrative Tools program group. The tool is available as an MMC snap-in. If you run only Terminal Services, then Terminal Services will be the only RDP connection in this folder; any other multiuser Windows components (e.g., MetaFrame or direct video support) that you install will also reside in this folder. Double-click an installed protocol to edit its properties. As you do so, you'll notice that many of the settings overlap the per-user settings. Usually, the per-user settings prevail, but you can choose to override the per-user settings and replace them with the settings you apply to RDP.

Win2K maintains the session-management tools that WTS contains. Screen 5 shows these tools in the Terminal Services Manager in the Administrative Tools group. Terminal Services Manager is available as an MMC snap-in. The session-management tools let you view processes running in each session, send messages to users, take control of remote sessions, and view total session information for all terminal servers in trusted domains. However, sometimes the GUI tools aren't as fast as the Terminal Services command-line management tools. Experienced WinFrame users will find in these tools the same functionality available in WinFrame's tools. However, Terminal Services wraps its tools into one tool (such as Query), and the WinFrame options make switches to the main Microsoft tool. The command-line tools are fairly easy to use; after you experiment with them, you can accomplish the same tasks that you use the GUI to accomplish. WTS users need to get used to some new syntax and new command names, but after you allow for the greater capabilities of the management tools that the new RDP contains, the functionality is similar.

Licensing Terminal Services
Licensing terminal services in Win2K is more complicated than it was in WTS. The licenses themselves aren't too difficult to understand. To access a terminal server, you need a 2000 Client Access License (2000CAL) to access a Win2K network and a Terminal Services Client Access License (TSCAL) to access the terminal server. Win2K Professional (Win2K Pro) comes with a TSCAL, so Win2K users need only an additional 2000CAL; every other type of RDP client needs a 2000CAL and an additional TSCAL. If nonemployees need to access terminal services via the Internet, you can get the per-user Internet Client License (ICL) to supply up to 200 simultaneous anonymous connections. Only people who don't work for your organization can use an ICL, so you can't use ICLs to give employees remote access to Windows applications from their homes. Thus, the ICL is useless unless you become an application service provider (ASP).

The licenses aren't the complicated part. The complicated part is the procedure you must go through to make the licenses legal. If you're used to MetaFrame's licensing system, you've already had to deal with license activation; thus, the additional steps to license terminal services in Win2K might not seem too bad. However, having to take the additional steps of activating the licenses and installing client license key packs is annoying. When you first install Terminal Services Licensing (typically, you'll want to have one Terminal Services Licensing server per domain), the license servers aren't activated and can't keep track of how you use licenses, which means you can't demonstrate that you're using licenses properly. You need to activate the licenses by providing your product ID via telephone, Internet, or fax and receiving an activation code. Then, you need to use that activation code to get a Client Access License (CAL) pack from Microsoft. The process isn't difficult, but it's one more step in setting up the terminal server. If you use MetaFrame for Win2K with terminal services, you'll need to go through the activation process twice.

Performance Pressure
One disadvantage to upgrading WTS to terminal services in Win2K is that Win2K is much more resource-hungry (especially RAM-hungry) than WTS is. If you install Win2K on a computer that was previously running WTS, you'll notice client sessions responding a little more slowly, even with the improved caching in RDP 5. In addition, because of the RAM that Win2K is using, you'll be able to support fewer users. To match WTS's performance, at a minimum you'll need to install additional RAM. Although the base system requirements for Win2K Server call for 64MB of RAM, Microsoft recommends 128MB for the base even without the strain of supporting terminal users. Terminal servers can easily use 512MB of RAM or more.

Would I use Terminal Services if I bought Win2K Server? Absolutely. Aside from the advantages of doing at least some application serving, Terminal Services is a great tool for remotely managing servers, and it's easy to set up. Because of the complexity of upgrading the core OS, I don't recommend upgrading Win2K just to use Terminal Services. However, if you already have this feature available, there's no reason not to use it.