Terminal Services

Since its introduction in the early 1990s, Windows Terminal Services was developed in parallel with the evolution of the Windows platform itself. Similar to UNIX and X Windows, Windows Terminal Services provide a server-centric computing model, but ensure much greater flexibility for accessing Win32 applications. The main benefit of Windows Terminal Services deployment is the fact that it enables you to provide access to specific Win32 applications without the necessity of installing those applications on every workstation within your Windows environment. Windows Terminal Services have been popular since 1995, when Citrix introduced its WinFrame product that provided full access to Windows NT 3.51 for the users of Windows terminals - so-called thin-client devices specially designed to provide users with access to Windows Terminal Services.

Note 

Windows terminals or thin-client devices are solid-state devices that have their OS burned into ROM (i.e., they have no moving parts). Such devices are exclusively used for communicating with terminal servers, UNIX servers, or mainframes. Typically, they run Windows CE or embedded Linux.

Unfortunately, up to now many administrators have considered Terminal Services to be rather difficult to deploy and limited in functionality and application support. This is mainly due to the fact that Windows NT 4.0 Terminal Server Edition (WTS) represented a separate operating system rather than a Windows NT 4.0 Server add-on. However, with the release of Windows 2000, Terminal Services became an integral part of the OS itself, including Windows 2000 Server, Windows 2000 Advanced Server and Windows 2000 Datacenter Server. Products of the Windows Server 2003 family, in turn, offer several enhancements to Terminal Services, which will be covered later in this chapter. Furthermore, most contemporary programs that comply with the Windows Logo requirements can run in a terminal server environment with little or no modifications. Therefore, in today's computing environment Terminal Services can be successfully utilized for achieving the following administrative goals:

• Desktop replacement. Windows 2000/Windows Server 2003 Terminal Services can allow you to completely eliminate standard PCs and replace them with thin-client devices. When considering this approach, one must carefully weigh its benefits (such as the elimination of end-node support, reduced power consumption, increased security, and rapid application deployment) against its potential drawbacks (for example, increased initial deployment costs for purchasing thin-client devices and robust servers, reduction of end-user personalization, limited sound and multimedia capabilities).

• Remote Access and Remote Administration. Remote access can be rather beneficial for large corporations having a large number of remote or migrating users, such as telecommuters, travelling executives, and so on.

Currently, there are many changes being introduced into Terminal Services technology. One of the most obvious ones, introduced with Windows Server 2003, is the fact that now it is not necessary to install Terminal Server for remote administration of your server. Remote Desktop for Administration is installed by default. To use Remote Desktop for Administration, you must first enable remote connections. To enable or disable remote connections to your server, proceed as follows:

1. Start the System applet on the Control Panel, and go to the Remote tab (Fig. 8.22).

   
   Figure 8.22: The Remote tab of the System Properties window

2. In the Remote Desktop option group, set the Allow users to connect remotely to your computer check box, and then click OK.

Note 

You must be logged on as a member of the Administrators group to enable or disable Remote Desktop for Administration.

Among the most significant changes that have been made in Terminal Services technology is the addition of the new Remote Desktop client, included with Windows XP and products of the Windows Server 2003 family (Fig. 8.23). This new client is based on the newer version of the Microsoft RDP protocol (Microsoft RDP v. 5.2).

Figure 8.23: The Remote Desktop Connection window

Note 

The traditional computing model is based on the TCP/IP protocol stack for transferring data between workstations and servers. Terminal services, however, have very specific needs for network link im-plementation, since only video information, keyboard, and mouse clicks are communicated, while all data processing takes place on the server. Two main protocols have been developed for this model - ICA (developed by Citrix) and RDP (developed by Microsoft). Windows 2000 Terminal Services uses RDP v. 5, which provides additional functionality to its predecessor, RDP v. 4.0 (implemented in Windows NT 4.0 Terminal Server Edition).

New features implemented by RDP5 included support for:

• Windows CE clients

• Remote control of user sessions

• Bitmap cashing to disk (RDP4 supported caching only to RAM)

• Client clipboard mapping

The newer versions of RDP (RDP v. 5.1 in Windows XP and RDP v. 5.2 in Windows Server 2003) additionally provide native support for client drive mapping, audio, enhanced video resolution and color depth, and a new feature - a connection bar that allows the user to "pin" the chosen part of large full-screen display to a specific part of their small PDA-sized screen during full-screen Terminal Services sessions (Fig. 8.24). Furthermore, the new Remote Desktop client can be used to access both RDP connections to Windows XP and Windows Server 2003 computers as well as for accessing the existing RDP4 and RDP5 Terminal Servers. Finally, the new client allows you to save connection settings to RDP files, thus eliminating the necessity to edit the registry.

Figure 8.24: The Display configuration tab of the new Remote Desktop client

Note 

Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Edition also implement a new technology known as Terminal Services Session Directory, which enhances user ability to reconnect to an active session on a terminal server cluster.

Remote Assistance

Remote Assistance is a feature of Windows Server 2003 and Windows XP that allows remote control over a desktop session. Rest assured that there are controls that you can use to ensure that only authorized individuals and computers can participate in. Let's take a brief tour of the Remote Assistance possibilities, then I'll explain the controls and what I consider to be the best practices.

Note 

Notice the difference between Remote Assistance and Remote Desktop! Remote Desktop provides an administrator with the ability to remotely connect to a computer for troubleshooting or management purposes or to access the network remotely. A Remote Desktop session does not allow a user present at the remote system to see the activity on the screen. The machine is locked and cannot be accessed while the remote session is active. Unlike the Remote Desktop, which starts a separate session, Remote Assistance allows the participation in an existing session by an individual logged on to the system (called the novice) and someone (called the expert) from a remote computer. Both novice and expert can see what's happening on the novice's computer, and both can participate. The expert can watch the novice to see a demonstration.

Similar to Remote Desktop, the default security settings in Windows XP and Windows Server 2003 allow you to enable the Remote Assistance feature via the Control Panel. To do so, the user who needs assistance can proceed as follows:

1. Start the System applet on the Control Panel, and go to the Remote tab (see Fig. 8.22).

2. Set the Turn on Remote Assistance and allow invitations to be sent from this computer checkbox. After you enable this option, the Advanced button will become available, allowing you to specify advanced settings for Remote Assistance sessions. A Remote Assistance session can be either "view-only" or allow remote control. Although one can choose to refuse the expert's request for control during the session, this choice and others can be configured via settings on the Remote tab of the System Control Panel applet. Clicking Advanced on this tab presents the following choices (Fig. 8.25):

   • Allow this computer to be controlled remotely - Determines whether to allow or deny remote control once connected.

   • Set the maximum amount of time invitations can remain open (in days, minutes, and hours).

   
   Figure 8.25: The Remote Assistance Settings window

However useful this function may be, allowing a user to control it via the Control Panel is not realistic. Although many users are capable of choosing good mentors, others have no common sense at all. Likewise, well-meaning but ill-advised "experts" can do a lot of harm.

Group Policy does offer a solution; it allows different degrees of control for different computers and can be centrally managed. By default, Remote Assistance settings in Group Policy are not configured and therefore have no impact on the settings made on the Control Panel. However, like other Group Policy settings, once you set the Group Policy settings, they will override any local settings.

Group Policy controls for Remote Assistance are located under Computer Settings | Administrative Templates | System | Remote Assistance (Fig. 8.26). To control Remote Assistance solicitations, select the Solicited Remote Assistance node, and select the settings appropriately. In Figure 8.27, Remote Assistance, including remote control, is allowed, but invitations are valid for 24 hours. Notice that a 24-hour interval (the default setting) is rather long, since long-term invitations increase the risk of compromise. Thus, in order to increase security it is recommended that you decrease this setting to, say, 3 hours.

Figure 8.26: Group Policy controls for Remote Assistance

Figure 8.27: Example illustrating Group Policy configuration for Remote Assistance