11. Terminal Services

IN THIS CHAPTER

• Remotely controlling servers across the enterprise

• Managing Terminal Services

• Understanding Terminal Services client features and performance

• Using terminal server clusters or farms

What's New

Terminal Services in Windows Server 2003 provides significant new features designed for improved manageability, usability, performance, security, and scalability. With all the changes, it might seem like the Terminal Services model has been completely redone. In reality, the model is very much the same as in previous versions of Windows. It still has a Terminal Services client component and a Terminal Services server component. Also, the server component still has two possible modes—Remote Administration mode and Application Server mode—just like in Windows 2000. However, these modes are implemented somewhat differently and have different names.

The Terminal Services client component is now called Remote Desktop Connection (RDC), just like in Windows XP. The biggest change that makes Terminal Services look different is the server-side component. The former Remote Administration mode is now called Remote Desktop for Administration and is treated separately from the Terminal Server application mode component. Although Remote Desktop for Administration and Terminal Server appear to be two separate things, they are in reality two facets of the same technology, like in Windows 2000. The difference is in the way they appear and how they are installed.

With the new name come several new features for both administrators and end users. There are new methods for administration (Group Policy, WMI, and ADSI), and the Terminal Services client is now the RDC application and uses a new version of Remote Desktop Protocol (RDP): RDP 5.2. The updated protocol provides several client enhancements for usability and performance, such as access to local resources and customization settings for low-bandwidth environments, which brings it up-to-date to rival Citrix's Metaframe client and the Independent Computing Architecture (ICA) protocol. There are also a number of new security features, such as easier management of accessibility permissions, client encryption policies, and support for stronger encryption to help administrators secure their Terminal Services environments. To top it all off, the new Terminal Server Session Directory enhances scalability by fixing problems with running terminal server clusters or farms.

Terminal Services Overview

Terminal Services is simply a technology for providing access to remote servers via a graphical interface. Terminal Services allows multiple users to simultaneously access a given machine—the terminal server. Each user connects to the terminal server via a Terminal Services client and gets his or her own environment as if he or she were the only user. All processing is performed on the terminal server. Applications run from the server, and only the screen shots and keyboard/mouse input pass between the client and the server. This transfer between the Terminal Services client and the terminal server is handled by RDP. RDP controls the session between the client and the server and determines which features are available. Terminal Services is ideal for remote administration because with it, you can access a server as if you were physically there. Terminal Services is also ideal for centralizing applications. By simply installing an application on a terminal server, you can make it immediately available to the entire enterprise. You don't have to deal with complicated deployments to the various clients. In addition, because all the processing is performed on the terminal server, Terminal Services is ideal for making applications available to users who use low-bandwidth connections or have low-end hardware clients.

Remote Desktop for Administration

Remote Desktop for Administration is the new name for the former Terminal Services Remote Administration mode, with a few improvements, of course. With Windows 2000, Terminal Services is integrated into the operating system as an optional service. It can be installed using Add/Remove Windows Components under Add/Remove Programs, and when it is installed, you are prompted to indicate the Terminal Server mode. The two choices are Remote Administration mode and Application Server mode. You use Application Server mode if the server is to be used in the role of a traditional terminal server or Winframe/Metaframe server. In this role, applications are to be installed on the box for use by remote users; making these applications available to remote users is the primary purpose of the box. Traditionally, Citrix Metaframe has offered several additional features that make it more worthwhile as an enterprise application hosting solution than Microsoft's Terminal Server.

Windows 2000 Remote Administration Mode

Remote Administration mode was something new for Terminal Services introduced in Windows 2000. Installing Terminal Services in Remote Administration mode allows up to two (free) concurrent connections. Plus, when using Terminal Server in this mode, you don't have to worry about keeping track of licenses, as you do in Application Server mode and previous versions of Terminal Server.

The purpose of Remote Administration mode is to allow system administrators to remotely access Windows 2000 servers. By installing Terminal Services in Remote Administration mode, administrators can get much of the same functionality as with third-party applications such as pcAnywhere—namely access to the server desktop via a graphical interface, right out of the box. This provides for a lower total cost of ownership for managing remote servers. Remote Administration mode meant that an administrator no longer had to be physically at the server to perform various types of maintenance, nor was it necessary to buy expensive third-party software. (Management likes this because it improves the bottom line, but poor administrators no longer have an excuse to fly out to Hawaii for server maintenance—at least not as often.)

Windows 2000 lacked the ability to directly control the server console, which led many organizations to continue using applications—such as pcAnywhere and VNC—which provide that functionality.

Windows Server 2003 Terminal Services Modes

Window Server 2003 no longer has a Terminal Services Remote Administration mode. The former Remote Administration mode and Application Server mode are now treated as two separate entities and are installed differently. Under the hood, they are both still technically part of Terminal Services—they just have different names now and are installed differently. The former Remote Administration mode is now called Remote Desktop for Administration. Windows Server 2003 comes preinstalled with Remote Desktop for Administration, although it is disabled. There is still an optional Windows component for installing Terminal Services, but it is now called Terminal Server. Installation of this service converts the Remote Desktop for Administration installation into a full-blown Terminal Server (Application Server mode) installation; uninstalling Terminal Server returns the system to Remote Desktop for Administration. Once again, Remote Desktop for Administration is always installed. You can enable it simply by selecting Allow Users to Connect Remotely to This Computer in the Remote Desktop section on the Remote tab of the System Properties screen, as shown in Figure 11.1. To highlight this distinction, Windows Server 2003, Web Edition does not have Terminal Server (it cannot be an application server); however, it does have Remote Desktop for Administration, so it can be accessed remotely via a Terminal Services client.

Figure 11.1. You can enable Remote Desktop for Administration from the Remote tab of the System Properties dialog box.

When Remote Desktop for Administration is enabled, a security message pops up, warning that local accounts might not have passwords and that a port on the firewall might need to be opened to allow communication. This is just an informational message to remind you that enabling Remote Desktop for Administration is a potential security risk because it allows direct access to your machine across the network.

In addition to selecting the check box to enable Remote Desktop, you must also designate who is permitted to use Remote Desktop for Administration. By default, the Administrator account is the only one that has access. To grant additional users (domain or local) permissions to be allowed to connect to the server via Remote Desktop for Administration, you open the Remote tab of the System Properties dialog box, click the Select Remote Users button, and then simply add the user or group accounts, as appropriate. The users on this list are then added to a local group called Remote Desktop Users, which has permissions to log on to the terminal server.

New Windows Server 2003 Clients

Windows Server 2003 has two installed clients that can be used for connecting to Remote Desktop for Administration (or Terminal Server). You find the RDC application by selecting Start, All Programs, Accessories, Communications—just like in Windows XP. The Terminal Services client application appears, and it is used for connecting to a single Terminal Server/Remote Desktop for Administration machine. In fact, RDC is the same Terminal Services client application that Windows XP uses. This client uses the RDP 5.2 protocol (and is backward-compatible with older RDP versions), which provides several enhancements over the previous Terminal Services. (See the section “RDP 5.2,” later in this chapter, for more information.)

The other client installed by default is the Remote Desktops MMC, which is installed under Administrative Tools. Although it too uses the RDP 5.2 protocol (and is backward-compatible with prior versions of RDP), the interface limits the configurable options. This console can be particularly useful for enterprise administrators because it has a tree-pane view of remote desktop connections, which enables an administrator to create several connections in the left pane and then connect and view them in the right pane. It makes switching between sessions and keeping track of multiple sessions much easier. These connections can also be configured to automatically connect (and even log on, provided that the terminal server allows it) when selected. Both clients also have the capability to connect to the server console session. You can do this with the Remote Desktops MMC simply by selecting the Connect to Console check box on the General tab of the server Properties dialog box, as shown in Figure 11.2. You can also connect to the console session via the RDC application by launching mstsc.exe /console from the command line. The console session is a special session that shows what's actually displayed on the server's monitor (although the physical monitor gets locked when the console session is accessed remotely). With Terminal Server installed (thus putting the server in the equivalent of Windows 2000's Application Server mode), applications must be installed via the server console session so that they can be made available for all user sessions.

Figure 11.2. You can connect to the terminal server console session by using the Remote Desktops MMC snap-in.

Another benefit of the Remote Desktops MMC snap-in is that it is an MMC snap-in. Just like any other MMC snap-in, it can be used to create customized administrative consoles.

Either client can be used for connecting to Windows Server 2003 Remote Desktop for Administration or terminal server sessions. In fact, RDP 5.1/5.2 is backward-compatible with previous versions, so that Windows Server 2003 clients can be used to connect to Windows 2000 (RDP 5.0) or even NT Terminal Server 4.0 (RDP 4.0). Of course, you won't get the new features of the RDP 5.1/5.2 protocol when connecting to these down-level servers. Similarly, previous versions of the Terminal Services client can connect to Windows Server 2003 Remote Desktop for Administration or terminal server sessions.

Although down-level clients can't get the features of the RDP 5.2 protocol when connecting to a Windows 2000 or Windows NT 4.0 terminal server, they can get some of the new features when connecting to Windows Server 2003 if you install the RDC client application. Not all the new features are available: Some, such as time zone redirection and better color support, require Windows XP or Windows Server 2003. This client can be installed on the Windows 9x platform (Windows 95, Windows 98, Special Edition, and Windows Me) as well as Windows NT 4.0 and Windows 2000. To install it and thereby gain the new features, you simply run the Remote Desktop Connection installation program from the Windows Server 2003 CD (SupportToolsmsrdpcli.exe) or download it from www.microsoft.com/windowsxp/remotedesktop. A version for Windows CE is available in the Windows CE .NET Platform Builder, and there is even a version available for the Macintosh (www.microsoft.com/mac/DOWNLOAD/MISC/RDC.asp). With the Remote Desktop Connection client, you can have a Windows “window” on a Macintosh (although some might consider this blasphemous).

One particularly nice feature of the RDC client is Full Screen mode, which enables you to use the full screen when connected to a terminal server. Windows 2000 terminal server client sessions show as a window that cannot be maximized. With the RDC client, you can expand to full screen, so it feels like you are actually on the box. In addition, you can configure how control keys (except Ctrl+Alt+Del) function: on the client, on the server, or in Full Screen mode only. With these settings, you can get the same look and feel as if you were on the server—even the keys behave the same (except Ctrl+Alt+Del, of course).

The last Terminal Services client, the Remote Desktop Web Connection client, allows connections to a terminal server via a Web browser, as shown in Figure 11.3. The name is somewhat deceptive because you don't actually install a client. Remote Desktop Web Connection client is installed on an IIS server and enables machines with Internet Explorer 5 or better to connect to terminal server sessions. To allow Remote Desktop Web Connection clients to connect to your terminal server, you simply install the Remote Desktop Web Connection component on the server. You install this component just as you do any other component, by opening Add or Remove Programs and then selecting Add/Remove Windows Components. After the Windows Components Wizard screen displays, you select Web Application Server and click the Details button. On the Web Application Server screen, you select Internet Information Services (IIS) and click the Details button. Next, you select World Wide Web Service and click the Details button. Finally, you select Remote Desktop Web Connection, click OK three times, and then click Next.

Figure 11.3. You can log on to a remote computer by using the Remote Desktop Web Connection client.

The Remote Desktop Web Connection client opens in a browser window, which is obviously different from the normal RDC client. However, if you choose to log on in Full Screen mode, the view is just like that of the RDC client.

New Windows Server 2003 Connections

Windows Server 2003 also supports a new type of RDP connection: Console. Just like Windows 2000 Server's Remote Administration mode, Windows Server 2003's Remote Desktop for Administration supports two incoming connections to virtual desktops.

Unfortunately, these virtual desktops aren't the same as the actual console desktop that you'd see if you walked up to the server in the data center. That's bad because a lot of error messages and other information is only output to the console. In Windows Server 2003, therefore, you can also connect directly to the console, effectively creating a third remote connection possibility and eliminating the need to install pcAnywhere, VNC, or other console-based remote control utilities.

To connect to the console by using the Remote Desktop for Administration console, you simply select the appropriate check box when creating the connection.

New Windows Server 2003 Administration

In addition to having a new name and a new client, Terminal Services in Windows Server 2003 provides new features for administration. You can configure Terminal Services settings with the usual Terminal Services Configuration MMC snap-in, and you can administer them with the Terminal Services Manager MMC snap-in. Plus, these settings have now been exposed so they can be configured with Windows Management Instrumentation (WMI) through scripts, the WMIC command-line utility, or Active Directory Services Interface (ADSI). Probably the most useful enhancement is the addition of a number of Group Policy settings for configuring these Terminal Services settings, as shown in Figure 11.4.

Figure 11.4. You can use Group Policy settings to configure Terminal Services.

Figure 11.4 shows the settings under the Computer Configuration section of Group Policy. In addition, you can configure a few Group Policy settings under the User Configuration section.

A lot of the new Terminal Services Group Policy settings are available simply for centrally managing settings previously available in Windows 2000. These settings can still be managed via the Terminal Services Configuration snap-in (for per-server settings) or Active Directory Users and Computers (for per-user settings). Because many administrators are already familiar with the Windows 2000 settings and enumerating all the available Group Policy settings would take too long, the following sections concentrate on the new settings. Just remember that for almost every setting you can configure manually in Windows 2000, in Windows Server 2003 you can configure it with Group Policy. In the following sections we point out a couple notable exceptions.

The Terminal Services Section

The new settings in the main Terminal Services Group Policy section include the following:

• Keep-Alive Connections— This setting maintains persistent terminal server connections. By default, this is off. In certain cases, if a client loses connection to the terminal server, the server might not detect it, so the connection might stay in an active state. When the client attempts to reconnect, the terminal server will treat it as a new connection. The user would then have a fresh sign-on (assuming that he or she is allowed more than one connection), and it would appear as though what the user was previously working on is gone. This is particularly annoying in Remote Desktop for Administration because now the user is using both available connections and preventing anyone else from getting in. Enabling Keep-Alive Connections adds more overhead on the terminal server because it is more actively monitoring the link state; however, it prevents the scenario mentioned here.

• Automatic Reconnection— This setting designates whether to allow clients to automatically attempt to reconnect dropped sessions.

• Restrict Terminal Services Users to a Single Remote Session— Just as this setting says, it allows a user only one connection to the terminal server, which prevents a user from leaving a bunch of disconnected sessions and wasting terminal server resources.

• Limit Maximum Color Depth— This setting allows control of the number of colors available to all clients. You generally use this setting to improve performance. Higher color depths require more data to be transferred across the session and put more of a burden on the terminal server.

• Do Not Allow Local Administrators to Customize Permissions— This setting disables modification of the Security tab in the Terminal Services Configuration snap-in. This prevents modification of the discretionary access control list (DACL) that specifies which users/groups have which levels of access to the server. You can still grant and revoke access by modifying the membership of the groups specified on the DACL; the DACL itself just can't be modified (it is read-only) . In other words, an administrator could look at the list to see which group has access and then add or remove a user from that group (assuming that he or she has access to modify the group). This is essentially an enforcement of Microsoft's recommendation of assigning permissions to resources based on groups and then managing those permissions by adding and removing users to and from those groups.

• Remove Windows Security Item from Start Menu— Just as it sounds, the Windows Security item is basically like pressing Ctrl+Alt+Del (because pressing Ctrl+Alt+Del in a terminal server session affects your client machine, not the actual terminal server session). Using this setting is one way to prevent users from shutting down or restarting the entire server.

• Remove Disconnect Option from Shut Down Dialog— This setting is meant up to try to force users to log off rather than disconnect. You use this setting to prevent users from leaving disconnected sessions active on the terminal server. Even with this setting, users can still disconnect without logging off by simply closing the Remote Desktop window. However, if they do that, they will at least be prompted with a reminder that their sessions will still be active.

The Client/Server Data Redirection Section

The settings in the new Client/Server Data Redirection section determine the types of resources that are allowed to be redirected to the client:

• Allow Time Zone Redirection— This setting changes the session time zone to be the time zone on the client instead of the time zone on the server (if the two are different). We like to keep the time zone of the server so we know what the local time is for the box on which we are working.

• Do Not Allow Smart Card Device Redirection— This setting essentially prevents you from using a smart card to connect to the terminal server. By default, this setting is disabled, so you can use a smart card to log on to the server by inserting the card in your local card reader (redirected so the server can view it). If this smart card redirection is disabled, to use a smart card to log on, you would have to put the smart card in a card reader physically attached to the terminal server, which kind of defeats the purpose.

The Encryption and Security Section

These settings are covered later in this chapter, in the section “Security Enhancements.”

The Licensing Section

The settings in the Licensing section are used to configure the behavior of a Terminal Services license server:

• License Server Security Group— This setting allows control over which terminal servers a Terminal Services license servers will issue licenses to. Enabling this setting creates a Terminal Services Computers local group. The terminal server license server will then issue licenses only to the terminal servers that are members of that group.

• Prevent License Upgrade— This setting prevents the Terminal Services license server from issuing Windows Server 2003 Client Access Licenses (CALs) to clients attempting to connect to Windows 2000 terminal servers.

The Session Directory Section

The settings in the Session Directory section are covered later in this chapter, in the section “Terminal Server Session Directory.”

Special Settings

The following settings cannot be configured via Group Policy:

• Permission Compatibility–Full Security or Relaxed Security— This setting determines the Terminal Services compatibility level and is configured when Terminal Server is installed. Full Security increases the security of the terminal server by restricting user access to various Registry keys.

• NIC for Session Directory to Use for Redirection— This setting tells the Terminal Services Session Directory which IP address to use for client connections. Because this is server specific, it has to be configured on a per-server basis, using the Terminal Services Configuration snap-in.

• Enable TS per NIC— This setting tells the server which NIC to listen to for terminal server requests. Because this is server specific, it has to be configured on a per-server basis, using the Terminal Services Configuration snap-in.

In addition to enabling you to centrally manage terminal server settings with Group Policy, Windows Server 2003 server provides interfaces for configuration with WMI and ADSI. By querying and manipulating the appropriate objects, you can configure the previously listed settings in batch files or scripts. For more information on WMI or ADSI scripting, see www.microsoft.com/technet/scriptcenter.

All these new management interfaces make configuring Terminal Services and managing it centrally much easier. You can also use these new management interfaces for managing Remote Desktop for Administration settings on Windows XP. This is particularly useful for implementing Remote Desktop for Administration throughout your organization.

RDP 5.2

RDP is the communication protocol used by Terminal Services and Remote Desktop for Administration. RDP determines what is sent between the client and the server. At a bare minimum, it passes the video display from the server to the client and the keyboard and mouse inputs from the client to the server. Previous versions of RDP (RDP 4.0 in Windows NT 4.0 Terminal Server, RDP 5.0 in Windows 2000, and RDP 5.1 in Windows XP) were limited in functionality as to the type of traffic they could pass. This usually meant that corporations purchased the Citrix Metaframe add-on to gain the additional functionality and performance needed. Windows Server 2003 uses RDP version 5.2, which provides several new features and enhancements.

One of these enhancements is support for logging on to terminal servers by using a smart card. This is a tremendous new feature for organizations that are standardizing on smart card logon. RDP 5.2 also supports redirection for local resources, creating a more consistent experience for users.

Local Resource Redirection

One of the new features of Windows Server 2003 is the capability to redirect client resources to the remote terminal server. Windows 2000 allows mapping of the local client's printer to the terminal server (provided that the appropriate printer driver is installed). This is still supported in Windows Server 2003, but the new protocol supports remapping of other resources—local drives, COM ports, and printers. For example, a client (CLIENT1) with a C: drive (COM1) and LPT1 can connect to a terminal server (NETSERVER) and have those resources available from the remote system (provided that the appropriate options are selected on the client and the terminal server allows it), as shown in Figure 11.5. As already mentioned, not all these capabilities are available on older operating systems; only Windows XP and Windows Server 2003 support the full range of RDP 5.2 features.

Figure 11.5. You can Access local resources from the remote terminal server.

In addition to allowing the remapping of other local resources, Windows Server 2003 provides enhanced mapping of printer drivers. Now it not only provides for detection and automatic installation of local printers if the print driver is installed, but it also attempts to locate near-miss printer drivers. Therefore, it attempts to install a compatible driver even if the exact driver for the local printer is not installed on the remote machine. In addition, you can put the drivers you want it to use in a particular directory and tell it to use that directory by specifying the trusted driver path Registry setting.

The following are some additional improvements to the client experience provided by RDP 5.2. Each of these options can be configured in the RDC client. Some of these options can also be enabled or disabled or configured with default settings via Group Policy:

• Sound Card Redirection— With this option, you can choose Bring to This Computer to redirect the sound from the server to the local machine. This enables you to run applications with sound on the server and hear them on a client. The other options are Leave at Remote Computer and Do Not Play.

• Enhanced Color and Resolution— Windows Server 2003 now supports up to true (24-bit) color and the maximum resolution supported by client video(640×480 to 1600×1200). In addition, the client automatically detects the color and resolution supported by the local computer and attempts to size it appropriately. As mentioned previously, Full Screen mode is available, and it gives the look and feel of being at the remote computer.

• Shared Clipboard— This server-side configurable option enables clients to cut and copy items on the local system and paste them in the terminal server session, or vice versa. For example, you could be working in a document on the terminal server, copy a paragraph, and then paste it in a document on your local system. You could even cut or copy the entire document file itself and paste it to the local system. This, coupled with the ability to access your local drives (via drive redirection), makes working on remote systems much easier because you still have access to local resources.

• Enhanced Performance in Low Bandwidth Environments— Additional options are available in RDP 5.2 and are configurable in the RDC application for improving performance, particularly over low-bandwidth connections. These are configured via the Experiences tab of the RDC client, as shown in Figure 11.6.

Figure 11.6. You can configure experience settings for low-bandwidth environments.

To help the user choose the appropriate settings based on the connection speed, there are default recommended settings for certain environments: Modem (56Kbps), Broadband (128Kbps–1.5Mbps), and LAN (10Mbps or higher), or you can create your own (Custom). For example, the Modem (56Kbps) setting enables themes and bitmap caching but disables all the rest.

• Time Zone Redirection— When you use this setting, the remote virtual session adopts the time zone of the client, creating a more consistent experience for users. No longer will users call the help desk, asking why the time on their local taskbar and the time on the remote taskbar are different!

Is RDP 5.2 Ready for Prime Time?

So, is RDP 5.2 good enough to rival the Citrix Metaframe protocol, ICA? Certainly. But will it completely replace ICA in all implementations? Probably not. RDP 5.2 now provides most of the commonly used features that made ICA superior to earlier versions of RDP. Metaframe still provides some features that might be of benefit, such as support for protocols other than TCP/IP, the capability to directly dial in to the application server without connecting to a network first, and so on. The determination of whether to use Citrix Metaframe (and the ICA protocol) or stick with Terminal Services is a judgment call that involves consideration of whether the extra cost is worth the extra features. Generally, for simple remote administration of servers, Remote Desktop for Administration and the RDP 5.2 protocol are more than adequate. For terminal server application servers, on the other hand, serious thought needs to be given to how they will be used before a determination can be made.

Windows Server 2003 Security Enhancements

In Windows 2000, to give a user access to connect to a terminal server, you must modify the permissions on the RDP Connection Configuration console of each terminal. This usually means creating a group (or groups) and granting them the appropriate access on each and every terminal server. In Windows Server 2003, this is already done for you. By default, a local group called Remote Desktop Users has User Access and Guest Access permissions to the terminal server. By simply adding users or groups to this local group, you can grant users access to log on to the terminal server. Of course, you can still manually modify the individual server configuration settings to get more granular control. To get further centralized control, you can manage the membership of the Remote Desktop Users group by using the Restricted Groups Group Policy at the domain level.

As with Windows 2000, when installing Terminal Services (Application Server mode), you are given the option for compatibility level. By using this option, you can adjust the permissions on Registry keys, system files, and so on. With Windows 2000, the choice is between Permissions Compatible with Windows 2000 Users and Permissions Compatible with Terminal Server 4.0 Users. With Windows Server 2003, the choice is between Full Security and Relaxed Security. It is, of course, recommended that you use the Windows Server 2003 compatibility mode to provide a more secure environment.

By default, Windows Server 2003 terminal servers attempt to encrypt client sessions with 128-bit (RC4) bidirectional encryption. Whether the terminal server will respond to clients that don't support 128-bit encryption can be configured with the Set Client Connection Encryption Level Group Policy setting. After it's enabled, the options are Client Compatible and High Level. High Level means the server accepts connections only from clients that support 128-bit encryption; Client Compatible allows connections with whatever encryption algorithm the client supports. By specifying 128-bit security, you can ensure that the communications between client and terminal server are secure.

In addition to configuring the encryption level the terminal server will use, you can also use Group Policy to configure the RPC session security. The RPC Security Policy/Secure Server (Require Security) Group Policy settings allow RPC connections only with trusted clients and only over authenticated and encrypted sessions. This prevents unauthorized machines (outside your organization) from even establishing a connection.

In addition, you can configure the server (via Group Policy or the Terminal Server Connection Configuration console) to always prompt clients for a password on connection. This is available in Windows 2000 (but not as Group Policy) and prevents users from being able to connect to the terminal server via passwords stored in the client settings. This therefore helps to secure the Terminal Services environment by forcing a user to type in a password to authenticate.

RDP 5.2 adds another enhancement to make authentication to the terminal server more secure: smart card redirection support. This feature enables the terminal server to use the local machine's smart card reader. If the local smart card reader is directed to the terminal server, a remote user can log on to the terminal server by inserting a smart card (in the local card reader) and typing in the PIN. The smart card reader verifies that the PIN matches the PIN stored on the card and then transmits the digital certificate for the user ID to be authenticated against the domain. This is a more secure form of authentication than simple passwords and user IDs because the user's ID and password are never transmitted on the network, and the physical card must be inserted.

Another new security feature for Terminal Server is the ability to use the Software Restriction Policies settings. Although it's not specifically a terminal server enhancement, the new Software Restriction Policies section of Group Policy can be used to protect the Terminal Server environment. You can use the Software Restriction Policies settings to specify whether certain file types are allowed to run and to specify certain levels of permissions for various Registry keys.

Terminal Server Session Directory

Windows Server 2003 provides enhancements to Terminal Services to scale it for the enterprise. A new feature available in Windows Server 2003, Enterprise Edition and Datacenter Edition is called Terminal Server Session Directory. It provides the capabilities to use Network Load Balancing (NLB) or other third-party load balancing services. This enables the creation of terminal server clusters, or farms. NLB provides a virtual network interface card (NIC) that is shared among up to 32 cluster members. This provides TCP/IP load balancing across all machines in the cluster. When a request comes in to the virtual NIC (the cluster NIC), it is directed to any of the servers in the cluster (presumably the least busy).

The Problem with Clustering Terminal Servers

When you use load balancing with terminal servers, you need to determine how to handle disconnected sessions. If a user drops a terminal server connection (either voluntarily or involuntarily) without logging off, the session remains active on the terminal server as a disconnected session. The disconnected session is still active, and any open applications continue to run. When the user attempts to connect to the terminal server again, he or she is reconnected to the disconnected session. It is essentially as if the user simply walked away from the console for a while and came back. He or she is still logged on, and any applications he or she was running are still running. This is particularly useful for kicking off long-running applications or reports. The user logs on, kicks off the application or report, and then comes back a couple hours later to obtain the results.

In a load-balanced cluster, if a user disconnects from one terminal server, that session is still active on the server. When he or she attempts to reconnect to the cluster, the request is load balanced among all available servers again. Thus there is no guarantee that the user will be routed back to the server with his or her disconnected session. Depending on the number of servers in the cluster, the probability could be as low as 1 in 32. The net result is that the user would connect to a different server, establish a new session, log on to the new server, and get a fresh console, as if he or she were logging on for the first time. This can be disconcerting for the user, especially if he or she was running an application in the previously disconnected session. Not only would it probably cause the user to panic, but he or she might take action (such as rerunning the application or report) that could interfere with what's going on in the other session (remember that it is still running). At the very least, it wastes resources because now two sessions are running—one on the original server and one on the new server. If the user disconnects and then reconnects, he or she could start a session on another cluster member, and another, and so on. The Terminal Servers Session Directory is designed to prevent this problem.

The Solution to Clustering Terminal Servers

Terminal Server Session Directory is simply a database that resides on a server. It could be any server—not necessarily a member of the cluster. In fact, it is recommended that the Terminal Server Session Directory be located on a highly available server outside the load-balanced cluster, so all members of the cluster can easily access it. The Session Directory server does not need to be a Windows Server 2003, Enterprise Edition server or Datacenter Edition server; it can be a Standard Edition server, although the cluster members (terminal servers) that will be querying the Session Directory database do need to be Enterprise Edition or Datacenter Edition servers. Figure 11.7 shows a typical terminal server cluster configuration with multiple clusters accessing a single Session Directory server. The Session Directory server itself could be a Microsoft Cluster Server (MSCS) cluster, in which case you would need Enterprise Edition or Datacenter Edition.

Figure 11.7. The Terminal Server Session Directory architecture provides flexibility for large deployments.

The database on the Session Directory server maintains a list of disconnected user sessions and the terminal servers to which they are connected. When a client attempts to connect to a terminal server that is a member of a load-balanced Session Directory–enabled cluster, the Terminal Services Connection Manager queries the Session Directory the cluster is configured to use to determine whether any disconnected sessions exist for the user. If so, the Terminal Services Connection Manager routes the logon to the terminal server with the disconnected session and updates the Session Directory database; if not, the logon request is load balanced as usual.

Installing the Session Directory server is fairly straightforward. You simply start the Session Directory service on the Windows Server 2003 server that you want to maintain the database. You should also set the service startup to automatic (the default is disabled) so that it will restart whenever the computer is rebooted. When the Session Directory service starts, it looks for a local group called Session Directory Computers. If the group doesn't exist, the Session Directory service creates it. This group is used to grant access to the Session Directory, so you should add the computer accounts of all the terminal servers that will use this computer for their Session Directory service to the Session Directory Computers group.

The terminal servers themselves also need to be configured to use Session Directory and provide cluster-naming information. You configure the terminal servers to use Session Directory by using any of the management methods mentioned earlier in this chapter: Group Policy, WMI (either script or WMIC command line), or the Terminal Services Configuration snap-in. As discussed previously, configuration with Group Policy provides the most centralized control and is the recommended method. Several settings must be configured; you find them in Group Policy by selecting Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Session Directory. They are as follows:

• Join Session Directory— This setting tells the terminal server to use a Session Directory server.

• Session Directory Server— This setting tells the terminal server which Session Directory server to use.

• Session Directory Cluster Name— This setting associates the terminal server with a particular terminal server cluster. Session Directory maintains connection information based on the terminal server clusters. This enables a single Session Directory server to support multiple load-balanced terminal server clusters.

• Terminal Server IP Address Redirection— This setting determines how the client actually connects to the terminal servers in the cluster. If it is enabled (the default), you should still configure the particular NIC (IP address) for client redirections on the individual terminal servers.

Terminal Server IP Address Redirection

The Terminal Server IP Address Redirection setting mentioned in the preceding section needs to be further explained. When a client attempts to connect to a terminal server cluster, the normal process is as follows (illustrated in Figure 11.8):

1. A client connects to the IP address of the cluster; let's call it CLUSTER1.

2. This request is load balanced and directed to the IP address of one of the terminal servers in the cluster; let's call it TS1. The client then logs on directly to TS1. The user disconnects from TS1.

3. Later, the user tries to reconnect to CLUSTER1.

4. The request is load balanced, but this time it is directed to TS3.

5. The client logs on directly to TS3, which (because it is configured to use a Session Directory server) sends a query to the Session Directory server to see whether a previous connection exists. One does (the one on TS1), so the Session Directory server responds and tells TS3 to redirect the client's logon request to TS1.

6. The user's session is redirected to TS1, the user is logged on directly to TS1, and the user picks up the disconnected session.

Figure 11.8. Terminal Services IP address redirection ensures that disconnected clients reconnect to the proper server.

Note that throughout this process, the client was logging on directly to the terminal server in question (TS1 or TS3). The load balancing was simply providing the IP address with which the user should connect. In certain load-balance solutions or scenarios, the client might not be able to directly connect to the terminal server IP address. In such a case, the client must connect to the terminal servers by using the virtual NIC of the cluster. The way this is accomplished is through the use of tokens: When the terminal server queries the Session Directory server and a disconnected session exists, that information is passed to the client via a token. The client then presents the token to the virtual NIC of the cluster and gets routed to the appropriate server (through the virtual NIC). To use this method, the terminal servers and the load-balancing technology need to support the passing of tokens (Windows Server 2003 and the Remote Desktop for Connection client, of course, do), and you need to disable the Terminal Server IP Address Redirection setting.