RemoteApp and Desktop
2008–based Terminal Services introduced a new feature called RemoteApp
(TS RemoteApp) or “Seamless Windows.” This feature allows applications
that are accessed through Terminal Services to appear as if they are
running locally on an end user’s machine. By using this feature, a user
would run their remote application side by side other applications
allowing them to minimize, maximize, and resize the application window
as if it were a location application. In addition, if a user were to
launch more than one RemoteApp, each RemoteApp would reuse the existing
Terminal Services session.
In Windows Server 2008
R2 Remote Desktop Services, the RemoteApp feature has been expanded to
include the ability to group and personalize RemoteApp programs,
session-based desktops, and virtual desktops while making them available
to users on the Windows 7 or Windows Server 2008 R2 Start menu. As a
result, the expanded RemoteApp feature has been renamed to RemoteApp and
To deploy RemoteApp
and Desktop Connection, an administrator must first deploy and configure
both the RD Connection Broker and the RD Web Access role services.
Then, once RemoteApp programs have been defined on a source,
administrators can use the Remote Desktop Connection Manager tool to
configure virtual desktops or define which RemoteApp sources will be
used for RemoteApp and Desktop Connection.
Once configured by and
deployed by administrators, users on Windows 7 or Windows Server 2008 R2
machines are able to use RemoteApp programs, session-based desktops,
and virtual desktops that were defined as part of the RemoteApp and
Desktop Connection. The items from the connection can be found by users
on the Start menu. As changes are made to RemoteApp and Desktop
Connection, such as adding or removing RemoteApp programs, these changes
are then automatically reflected on the Start menu. Additionally, users
can use the RemoteApp and Desktop Connection notification area icon in
the taskbar to do the following:
With the addition of many
great features in Remote Desktop Services also comes the ability for an
administrator to granularly control the configuration of Remote Desktop
sessions. All the features available to the end user’s Remote Desktop
session can be managed, limited, and overridden by the
administrator. Configuring administrative settings through Group Policy
or Remote Desktop Management tools can override/control most
user-configurable settings. This can greatly benefit an RD Session Host
server by freeing up valuable server resources for features that might
not be required in an enterprise deployment, such as audio redirection
or high-color resolution. With this granular administrative capability,
the administrator can also improve RD Session Host server or virtual
desktop security by requiring high encryption for sessions, force
certain types of strong authentication, or even lock the session down to
prevent users from making operating system changes.
Session 0 Isolation
In Windows Server 2003,
Windows XP, and earlier versions of Windows, a console session was
called Session 0. In addition to being an interactive logon session,
Session 0 was also the session where all services were running.
Unfortunately, having services run within the same session that hosted
interactive logons presented a possible attack vector. Services run with
elevated rights. Because of this, Session 0 services were a target for a
malicious agent attempting to elevate their rights.
Microsoft addressed this
threat in Windows Vista and Windows Server 2008 (and carried over to
Windows 7 and Windows Server 2008 R2) by making Session 0 a
non-interactive session. Now, when a user logs on to an interactive
session, they are given Session 1, the next parallel user is given
Session 2, and so on. As a result of this change, there are a number of
consequences with how Remote Desktop for Administration works in Windows
7 and Windows Server 2008 R2. These consequences are as follows:
switch— The /console switch
does not work when connecting to a Windows 7 or Windows Server 2008 R2
Remote Desktop session.
Only two Remote Desktop
sessions can connect at the same time—
In Windows Server 2003, two Remote Desktop sessions and one remote
console session were allowed at any given time. With the Session 0
change, there is now only a maximum of two parallel Remote Desktop
sessions allowed in Windows 7 or Windows Server 2008 R2.
Session 0 user interface
(UI) interaction— What if a service presents a
user with a UI to interact with? Because Session 0 is no longer
interactive, Windows 7 and Windows Server 2008 R2 allow the user to
interact with the Session 0 UI in a special desktop.
Disconnected session dialog
box— In the new Remote Desktop
Connection client, there have been some changes in how a connection made
to a Terminal Server with too many sessions is handled. In Windows
Server 2003, the client just displayed a message: “The Terminal Server
has exceeded the maximum number of connections.” Now, when there are too
many parallel sessions, the client displays a selection dialog box that
allows an administrator to disconnect an existing session.
are restricted to one session by default— By default in Windows Server 2008 R2 Remote Desktop
Services, all users are restricted to one interactive session. This
setting can be changed through the management console or Group Policy.
When connecting to a Windows Server
2003 Terminal Server, the /console
switch can still be used.
Remote Desktop Services
enables an RDC client to redirect many of the local resources so they
can be easily used within a Remote Desktop session. Serial and printer
ports can be made available in Remote Desktop sessions to allow a user
to send RD Session Host server print jobs to locally configured
printers, as well as access serial devices such as modems from within
the Remote Desktop session. Audio can also be redirected from a session
to local sound cards to enable sound from the Remote Desktop session to
be heard from local speakers. Also, the Windows Clipboard can be
redirected to allow cutting and pasting between the Remote Desktop
session and the local workstation console.
Each of these
resource redirections works only if the operating system and the RDC
client on the end user’s workstation support these configurations. Some
of these local resource redirections require user modification or
reconfiguration for proper use.
The various redirection
support features built in to Remote Desktop Services are described in
the following sections.
Disk Drive Redirection
Local disk drives can be
redirected to Remote Desktop sessions and appear in Windows Explorer as
networked drives using the naming convention local drive letter on
computer name—for example, C on workstation5. To access from a graphical window, simply browse
the drive as you would a local or networked drive. Accessing this drive
from the command prompt requires a little bit of education. Within a
command prompt, the redirected local drives are referenced as
\\tsclient\Drive letter. Directory listings can be created using this
Universal Naming Convention (UNC), but for file transfer or quick
browsing, a client should map a network drive letter to this local drive
resource. To do so, follow these steps:
use * \\tsclient\c, where the local C: drive is the disk
you want to access within the Command Prompt window. The local drive is
automatically mapped to the next available drive letter, starting from
drive letter Z: and working backward through the alphabet.
At the command prompt, type Z: and press Enter
to connect directly to the mapped local drive and begin using this
finish working with this resource, disconnect the drive by typing net
use Z: /delete, where the Z: drive is the local mapped
Command Prompt window.
The preceding steps
refer to a machine called tsclient.
You should not replace this name with the actual machine account name.
The Remote Desktop session recognizes the machine’s local disk resources
only from within a command window as tsclient,
so do not consider this a substitute for the actual machine name.
Locally defined print
devices can also be redirected. This includes printers directly attached
to the client workstation as well as network printers. When a client
opens a Remote Desktop session that is configured to redirect Windows
printers as well as LPT ports, the RD Session Host server attempts to
install each printer for use in the Remote Desktop session.
In Windows Server 2003,
managing printer drivers for printer redirection was the bane of
administrators. Either a client’s printer had to be using a printer
driver native to Windows Server 2003 or the printer driver had to be
manually installed beforehand by an administrator. If neither of these
were true, printer redirection would fail. In Windows Server 2008, a new
feature called TS Easy Print was introduced to reduce the difficulties
involved with managing Terminal Services printer redirection.
TS Easy Print (renamed RD Easy
Print in Windows Server 2008 R2) enables users to reliably print from a
Remote Desktop session to their printer on their client computer. RD
Easy Print does this by accomplishing the following things:
It uses a
universal printer driver. Because it is universal, this driver supports
legacy and new printer drivers without the need for administrators to
install these drivers on the RD Session Host server.
The RD Easy Print driver
allows users to view their local printer driver’s printing preferences.
This is accomplished because the driver acts as a proxy and redirects
all calls for the GUI to the actual driver on the client side. The
result is the RDC client actually just launches the GUI for the
client-side printer on top of the remote session.
In Windows Server 2008
Terminal Services (and carried over to Windows Server 2008 R2 Remote
Desktop Services), other changes were also introduced aimed at improving
a user’s experience with printer redirection. These changes are as
for redirected printers— In Windows
Server 2003, if a user had multiple sessions open, all the redirection
printers from all the sessions were visible to each individual session.
Furthermore, administrators could see all the redirected printers for
every user connected to a Terminal Server. In Windows Server 2008, the
visibility of redirected printers is limited to the session where they
are installed. With this change, the spooler service doesn’t need to
enumerate as many redirected printers. This reduction both improves the
time when a user tries to enumerate their printers during a session and
during initial logon.
Per-session default printers— In Windows Server 2008 or later, a user’s default
printer is on a per-session basis. This is a change from Windows Server
2003 where the default printer for a user was the same for all
Redirected printer names are shorter— In Windows Server 2003, redirected printer
names were “%PRINTER_NAME% (from %CLIENT_MACHINE_NAME%) in session
%Session_ID%.” In Windows Server 2008 or later, these names have been
shortened to “%PRINTER_NAME% (%SESSION_ID%).”
Clients must meet the following
requirements to use the RD Easy Print driver:
Local Time Zone
Remote Desktop Services
also supports local time zone redirection. This feature allows RDC
clients connecting from a separate time zone to have the session time
reflect the user’s local time, enabling users to more easily comprehend
the times, especially when reviewing emails.
Plug and Play Device
Using Plug and Play
Device Redirection, a user can redirect Windows Portable Devices that
support the Media Transfer Protocol (MTP) and digital cameras that
support the Picture Transfer Protocol (PTP). Plug and Play Device
Redirection works so that when a terminal session is launched, a user’s
plug-and-play devices are automatically installed on the RD Session Host
server, virtual machine, or remote computer if just Remote Desktop for
Administration is being used. After being connected, any plug-and-play
notifications will then appear above the taskbar in the Remote Desktop
Users can also configure Plug
and Play Device Redirection so that devices connected after a session
has already been established are then redirected. To do this, a user
would select the Devices That I Plug in Later check box in the Remote
Desktop Connection client before connecting to a remote machine. Then
after a device has been redirected, it will become available for use
within the current session. For example, if a digital camera is
redirected, that device would be directly accessible from an application
such as the Scanner and Camera Wizard on the remote machine.
Plug and Play Device
Redirection is not supported over cascaded Remote Desktop sessions. A
cascading session is when a user connects to one remote machine and then
from within that session connects to a second remote machine.
.NET Device Redirection
.NET Device Redirection
allows a device that uses Microsoft Point of Service (POS) for .NET 1.11
to be redirected in a Remote Desktop session. This redirection feature
is important to organizations that are deploying Remote Desktop Services
to clients that use POS peripheral
devices, such as bar-code scanners, biometrics, magnetic card readers,
receipt printers, and so on.
.NET Device Redirection is
only supported on Terminal Servers or RD Session Host servers running
an x86-based version of Windows Server 2008 or Windows Server 2008 R2.
The following are new
redirection features that are introduced in Windows Server 2008 R2
Remote Desktop Services:
Multimedia redirection— This feature redirects multimedia files and
streams such that audio and video content is received in its original
form from the server to a client. By doing this, multimedia content is
then rendered using a client’s local media playback capabilities.
Audio input and recording— This feature enables audio recording
support for remote clients using Voice over IP (VoIP) or
Language bar redirection— Users can now control the language setting (for example,
right to left) for RemoteApp programs using the local language bar.