- 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
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 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.
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):
o Allow this computer to be controlled remotely - Determines whether to
allow or deny remote control once connected.
o 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
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
Figure 8.26: Group Policy controls for Remote Assistance
- Figure 8.27: Example illustrating Group Policy configuration for Remote Assistance