In This Chapter
Remotely Control Servers across the Enterprise.
Managing Terminal Services.
Terminal Services client features and performance.
Terminal Server Clusters or Farms.
Terminal services in Windows Server 2003 provide 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. 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 and application server mode—just like in Windows 2000.
The terminal services client component has been renamed and is now called Remote Desktop Connection, 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 comes several new features for both administrators and end users alike. There are new methods for administration (Group Policy, WMI, and ADSI), and the terminal services client is now the Remote Desktop Connection application and uses a new version of the Remote Desktop Protocol (RDP 5.1). 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 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.
What is terminal services? 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 own environment as if he 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 the Remote Desktop Protocol (RDP). RDP controls the session between client and server and determines which features are available. Terminal services is ideal for remote administration because 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 your entire enterprise. You don't have to deal with complicated deployments to the various clients. Additionally, because all the processing is performed on the terminal server, terminal services is ideal for making applications available to users across low-bandwidth connections or with low-end hardware clients.
Remote Desktop for Administration is 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 Programs, Add/Remove Windows Components, and when installed, the administrator is prompted for the terminal server mode. The two choices are Remote Administration Mode and Application Server Mode. Application Server Mode is designed for installing the server 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.
Note
For a comparison of terminal services and Citrix Metaframe, go to the book's product page at www.informit.com/store/product.aspx?isbn=0789728494. Click the Extra tab and locate article ID# A011101.
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.
Note
For information on terminal services licensing for Application Server Mode, go to the book's product page at www.informit.com/store/product.aspx?isbn=0789728494. Click the Extras tab and locate article ID# A011102.
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. No longer do you have to be physically at the server to perform various types of maintenance, nor do you have 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.)
Window Server 2003 no longer has a Terminal Services Remote Administration Mode. The so-called 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 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 2003 Server 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 the Remote Desktop for Administration mode. Once again, Remote Desktop for Administration is always installed. It can be enabled 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. 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, click the Select Remote Users button and then simply add the user or group accounts as appropriate. This adds the users on this list to a local group called Remote Desktop Users, which has permissions to log on to the terminal server.
Windows Server 2003 has two installed clients that can be used for connecting to Remote Desktop for Administration (or Terminal Server). The Remote Desktop Connection application is found by selecting Start, All Programs, Accessories, Communications—just like in Windows XP. This is the terminal services client application, and it is used for connecting to a single Terminal Server/Remote Desktop for Administration machine. In fact, Remote Desktop Connection is the same terminal services client application Windows XP uses. This client uses the RDP 5.1 protocol, which provides several enhancements over the previous terminal services. (See “Remote Desktop Protocol 5.1,” 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.1 protocol, 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 the terminal server allows it) when selected. Both clients also have the capability to connect to the server console session. This can be accomplished with the Remote Desktops MMC simply by selecting the Connect to Console check box, as shown in Figure 11.2. You can also connect to the console session via the Remote Desktop Connection application by launching mstsc.exe/console from a 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 it in Application Server Mode), applications must be installed via the server console session so that they can be made available for all user sessions.
Another benefit of the Remote Desktop MMC console is that it is an MMC snap-in. Just like any other MMC snap-in, it can be used to create customized administrative consoles.
Note
If you're not familiar with the MMC and would like a quick tutorial, go to the book's product page at www.informit.com/store/product.aspx?isbn=0789728494. Click the Extras tab and locate article ID# A011301.
Either client can be used for connecting to Windows Server 2003 Remote Desktop for Administration or Terminal Server sessions. In fact, the RDP 5.1 protocol is backward-compatible to previous versions, so these 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 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 new RDP 5.1 protocol when connecting to a Windows 2000 or NT 4 terminal server, they can get the new features when connecting to Windows Server 2003 by installing the Remote Desktop Connection client application. This client can be installed on the Windows 9x platform (Windows 95, 98 Special Edition, and Millennium) as well as Windows NT 4 and Windows 2000. To install it and thereby gain the new features, simply run the Remote Desktop Connection installation program from the Windows XP CD (SupportToolsmsrdpcli.exe) or download it from http://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 (http://www.microsoft.com/mac/DOWNLOAD/MISC/RDC.asp). With this 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 new Remote Desktop 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 Remote Desktop Client, you can expand to full screen, so it feels like you are actually on the box. Additionally, 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 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 Client is installed on an IIS server and enables machines with IE 5 or better to connect to terminal server sessions. To allow Remote Desktop Web Clients to connect to your terminal server, simply install the Remote Desktop Web Connection component on the server. This component is installed just like any other component, by selecting Add or Remove Programs, Add/Remove Windows Components. After the Windows Components Wizard screen displays, select Web Application Server and click the Details button. On the Web Application Server screen, select Internet Information Services (IIS) and click the Details button. Next, select World Wide Web Service and click the Details button. Finally, select Remote Desktop Web Connection, click OK three times, and then click Next.
The Remote Desktop Web Client opens in a browser window, which is obviously different from the normal Remote Desktop Connection Client. However, if you choose to log on in Full Screen mode, the view is just like that of the Remote Desktop client.
In addition to a new name and a new client, terminal services in Windows Server 2003 provides new features for administration. Terminal services settings can be configured with the usual Terminal Services Configuration MMC snap-in and administered 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, 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 shows the settings under the Computer Configuration section of Group Policy. In addition, a few group policy settings can be configured 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 Terminal Services Configuration (for per-server settings) or Active Directory Users and Computers (for per-users settings). Because many administrators are already familiar with the Windows 2000 settings and enumerating all the available group policy settings is too lengthy, we will concentrate here on the new settings. Just remember that for almost every setting you could configure manually in Windows 2000, you can now configure it with group policy. I will point out a couple of notable exceptions.
The new settings in the main Terminal Services policy section include the following:
Keep-Alive Connections—. 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 she is allowed more than one connection), and it would appear as though what she 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, but it prevents the scenario mentioned here.
Automatic Reconnection—. Designates whether to allow clients to automatically attempt to reconnect dropped sessions.
Restrict Terminal Services Users to a Single Remote Session—. Just as it says, users are allowed 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—. Allows control of the number of colors available to all clients. This is generally used 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—. Disables modification of the security tab in Terminal Services Configuration. This prevents modification of the discretionary access control list (DACL) that specifies which users/groups have which levels of access to the server. Access can still be granted and revoked by modifying the membership of the groups specified on the DACL; the DACL itself just can't be modified (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 he 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). This is one way to prevent users from shutting down or restarting the entire server.
Remove Disconnect Option from Shut Down Dialog—. This feature is set up to try to force users to log off rather than disconnecting. This is an attempt at preventing 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 settings in this new section determine the types of resources that are allowed to be redirected to the client:
Allow Time Zone Redirection—. Changes the session time zone to be the time zone on the client instead of the server (if different). Personally, I like to keep the time zone of the server so I know what the local time is for the box on which I am working.
Do Not Allow Smart Card Device Redirection—. Essentially prevents using a smart card to connect to the terminal server. By default, this 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 then 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.
These settings are covered later in this chapter in the section “Security Enhancements.”
These settings are used to configure the behavior of a terminal services license server:
License Server Security Group—. Allows control over to which terminal servers a terminal services license servers will issue licenses. Enabling this setting creates a Terminal Services Computers local groups. The terminal server license server will issue licenses only to those terminal servers that are a member of this group.
Prevent License Upgrade—. Prevents the terminal services license server from issuing Windows .NET Client Access Licenses (CALs) to clients attempting to connect to Windows 2000 terminal servers.
These settings are covered later in this chapter in the section “Terminal Server Session Directory.”
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—. Tells the 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 Terminal Services Configuration.
Enable TS per NIC—. Tellsthe 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 Terminal Services Configuration.
In addition to being able 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, the previously listed settings can be configured 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 them centrally much easier. They can also be used for managing Remote Desktop settings on Windows XP. This is particularly useful for implementing Remote Desktop for Administration throughout your organization.
The Remote Desktop Protocol is the communication protocol used by terminal services and remote desktop. The protocol determines what is sent between client and 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 the RDP protocol (RDP 4.0 in Windows NT 4 Terminal Server and RDP 5.0 in Windows 2000) were limited in functionality as to the type of traffic it could pass. This usually meant that corporations purchased the Citrix Metaframe add-on to gain the additional functionality and performance. Windows Server 2003 uses version 5.1 of the RDP protocol, which provides several new features and enhancements.
One of the new features 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 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, as shown in Figure 11.5 (provided the appropriate options are selected on the client and the terminal server allows it).
In addition to allowing the remapping of other local resources, the mapping of printer drivers has been enhanced. Now it not only provides for detection and automatic installation of local printers if the print driver is installed, but 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. Additionally, 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 the RDP 5.1 protocol. Each of these options can be configured in the Remote Desktop Connection clients. 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 to Bring To This Computer. This redirects the sound from the server to the local machine and enables you to run applications with sound on the server and hear them. The other options are to Leave At Remote Computer and Do Not Play.
Enhanced Color and Resolution—. Now supports up to true (24-bit) color and the maximum resolution supported by client video(640×480 to 1600×1200). Additionally, the client automatically detects the color and resolution supported by the local computer and attempts to size appropriately. As mentioned previously, a Full Screen mode is available that 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. For that matter, 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.1 and are configurable in the Remote Desktop Connection application for improving performance, particularly over low-bandwidth connections. These are configured via the Experiences tab of the Remote Desktop Connection client, as shown in Figure 11.6.
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.
So, is RDP 5.1 good enough to rival the Citrix Metaframe protocol, Independent Computing Architecture (ICA)? Certainly. But will it completely replace ICA in all implementations? Probably not. RDP 5.1 now provides most of the commonly used features that made ICA superior to RDP. There are still some features that Metaframe provides 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 as to whether the extra cost is worth the extra features. Generally, for simple remote administration of your servers, the Remote Desktop for Administration and the RDP 5.1 protocol are usually 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. Currently, no Metaframe add-on to Windows Server 2003 is available. But then, as of this writing, Windows Server 2003 hasn't been released yet either. Look for Citrix to make a Metaframe add-on soon after Windows Server 2003 is released. Then you can make your final determination.
In Windows 2000, to give a user access to connect to a terminal server, you must modify the permissions on the RDP Connection Configuration 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 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. This adjusts 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 2003, the choice is between Full Security or Relaxed Security. It is, of course, recommended that you use the Windows 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 or High Level. High Level 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 PolicySecure Server (Require Security) group policy settings allows 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.
Additionally, you can configure the server (via group policy or the Terminal Server Connection Configuration) to always prompt clients for a password on connection. This is available in Windows 2000 (but not as a 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 users to type in a password to authenticate.
The RDP 5.1 protocol 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. By redirecting the local smart card reader 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 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 Software Restriction Policies. Although not specifically a terminal server enhancement, the new Software Restriction Policies section of group policy can be used to protect the terminal server environment. Software Restriction Policies can be used to specify whether certain file types are allowed to run, as well as to specify certain levels of permissions for various Registry keys.
For more information on Software Restriction Policies, see “New Group Policies,” p. 93.
Windows Server 2003 provides enhancements to terminal services to scale it for the enterprise. A new feature available in Enterprise Server and Datacenter Server is called Terminal Server Session Directory, and it provides the capabilities to use network load balancing or other third-party load balancing services. This enables the creation of terminal server clusters, or farms. The network load balancing service 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).
For more information on network load-balanced clusters, see Chapter 12, “Clustering,” p. 199.
The problem with load balancing terminal servers is 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 applications continue to run. When the user attempts to connect to the terminal server again, she is reconnected to her disconnected session. It essentially is as if the user simply walked away from the console for a while and came back. She is still logged on, and any applications she was running are still running. This is particularly useful for kicking off long-running applications or reports. The user logs on, kicks it off, 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 she attempts to reconnect to the cluster, her request is load-balanced among all available servers again. Thus there is no guarantee that she will be routed back to the server with 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 she would connect to a different server, establish a new session, log on to the new server, and get a fresh console as if she were logging on for the first time. This can be disconcerting for the user, especially if she had been running an application in the previously disconnected session. Not only would it probably cause her to panic, but she might take action (such as rerunning the application or report) that could interfere with what's going on in the other session (remember 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, 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.
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 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 or Datacenter Edition—it can be a Standard server, although the cluster members (terminal servers) that will be querying the Session Directory database do need to be Enterprise or Datacenter 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.
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, it 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 itself is fairly straightforward. Simply start the Session Directory service on the Windows Server 2003 that you want to maintain the database. You should also set the service startup to automatic (the default is disabled), so 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, it 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 to the Session Directory Computers group.
The terminal servers themselves also need to be configured to use Session Directory to tell them to use the Session Directory and provide cluster naming information. The terminal servers are configured to use Session Directory by any of the management methods mentioned earlier in this chapter (group policy, WMI [either script or WMIC command line], or the Terminal Services Configuration console). As shown previously, configuration with group policy provides more centralized control and is the recommended method. Several settings must be configured; in group policy, they are found by selecting Computer Configuration Settings, Windows Components, Terminal Services, Session Directory. They are as follows:
Join Session Directory—. Tells the terminal server to use a Session Directory.
Session Directory Server—. Tells the terminal server which Session Directory server to use.
Session Directory Cluster Name—. 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—. Determines how the client actually connects to the terminal servers in the cluster. If enabled (the default), you should still configure the particular NIC (IP address) for client redirections on the individual terminal servers.
The purpose of Terminal Server IP Address Redirection needs further explanation. When a client attempts to connect to a terminal server cluster, the normal process is as follows:
A client connects to the IP address of the cluster; let's call it
CLUSTER1.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 fromTS1.Later, the user tries to reconnect to
CLUSTER1.The request is load balanced, but this time it is directed to
TS3.The client logs on directly to
TS3, which (because it is configured to use a Session Directory) sends a query to the Session Directory server to see whether a previous connection exists. One does (the one onTS1), so the Session Directory responds and tellsTS3to redirect the client's logon request toTS1.The user's session is redirected to
TS1, he is logged on directly toTS1, and he picks up his disconnected session.
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 he 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 this case, the client must connect to the terminal servers 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 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.
Terminal Server Session Directory makes operating terminal servers in a clustered configuration more viable. This improvement, combined with the capability to centralize administration with group policy and the enhancements to the underlying communications protocol (RDP), make the new terminal services in Windows Server 2003 more attractive for enterprise deployments. These are just some of the many improvements in Windows Server 2003 for scaling Windows for larger organizations. As you'll see in the next chapter, Microsoft has further enhanced its clustering offerings.
