1. New Remote Desktop Services Features
Windows Server 2008 R2 Remote Desktop Services (RDS) is a significant update from the Terminal Services
in Windows Server 2008 or Windows Server 2003. Not only has the name
changed, but some significant new capabilities were added as well. The
three major new features (when compared to Windows Server 2003) are
Remote Desktop (RD) Gateway, RemoteApps, and RD Web Access. For most SBS
environments, the first two of these are the most important. RD
Gateway is used by the new Remote Web Access (RWA), and RemoteApps gives you the ability to use specific
applications running on a terminal server as if they were local. RD
Web Access is also useful, but rather than setting up a traditional
web server to provide access to applications, we’ll integrate them
directly onto Companyweb, the SBS intranet.
1.1. RD Gateway
The RD Gateway role service is not installed on the main
SBS 2011 server, but the functionality is enabled to support
RWA. In SBS 2003, Remote Web Workplace (RWW) acted as a proxy for the Remote Desktop Protocol, using port 4125 as the
incoming port to connect remote users to clients in the SBS domain.
This worked well and was the big application in SBS 2003. In fact,
it was so successful that a lot of enterprise networks were envious
of the technology.
Windows Server 2008 R2 uses RD Gateway to allow a similar
functionality, but instead of using an RDP proxy across port 4125,
RD Gateway tunnels traffic over HTTPS to help form a secure,
encrypted connection between remote users on the Internet and the
remote computers on which their productivity applications run, even
if their use is located behind a Network Address Translation (NAT)
Traversal–based router.
The SBS team chose to use the RD Gateway functionality of
Windows Server 2008 R2 for Remote Web Access. Which allows us to do
some really cool things with RWA, including adding links to
applications that can be run directly from RWA across the
Internet.
1.2. RemoteApps
RemoteApps was the single best feature added to
Windows Server 2008, except for Hyper-V. But Hyper-V isn’t
exciting—it just makes our jobs easier. RemoteApps is actually
exciting, and it gives us a way to give our users a better
experience.
Terminal Services has always enabled us to allow users to run
entire desktops as if they were local while actually using the power
of the server. But RemoteApps takes this to a whole new level,
allowing us to run just specific applications on the RemoteApp
server and have them behave just as if they were local applications.
This makes the entire process transparent to the user. The
application runs on the server, using the server’s memory, CPU, and
resources, but it displays on the user’s computer just as if it were
running locally. It’s uncanny how natural it feels. We use it here
in our office all the time. Because we’re constantly building and
rebuilding new computers and virtual machines, it’s a nuisance to
try to have a single, predictable and accessible location for data
files—especially when we have multiple domains here. But by enabling
RemoteApps, we always have the same view of our environment.
Because RemoteApps lets you create .msi files for deployment,
you can use Group Policy to deploy the remote applications. The
applications can even be configured to take over the file
association for a file type, just as if they were local
applications—again making the user experience completely
natural.
1.3. RD Web Access
RD Web Access provides a web-based front end that allows you
to publish applications to a web page for easier user access. In SBS
2011, you can use RD Web Access to publish the application links
directly in the SharePoint Companyweb site.
2. Concepts
Remote Desktop Services is a new concept for many system
administrators who expect systems to be essentially single-user. It
brings true multiuser capability to Windows. Each user who connects to
a Windows Server 2008 R2 server using Remote Desktop or a RemoteApp is
actually using the resources of the server itself, not the particular
workstation at which he or she is seated. The user’s experience
doesn’t depend on the speed of the workstation—the user’s workstation
is actually sharing the processor, RAM, and hard disks of the server
itself.
Each user gets his or her RDS session, and each session is completely isolated
from other sessions on the same server. An errant program in one
session can cause that session’s user to have a problem, but other
users are unaffected.
Each user who connects to a Windows Server 2008 R2 server using
Remote Desktop is actually functioning as a terminal on that server.
RDS supports a wide variety of computers as terminals—from diskless
display stations running a version of Windows entirely in memory, with
no hard disk at all, to legacy Windows desktop computers that are
otherwise too underpowered for satisfactory use. Because the terminal
is responsible solely for the console functions—that is, the keyboard,
mouse, and actual display—the processing and RAM requirements for the
terminal are minimal. All other functioning resides on and is part of
the server, although the disks, printers, and serial ports of your
local workstation can be connected to the remote session.
Warning:
IMPORTANT Versions of
Windows prior to Windows XP SP3 can’t install the latest version of
the Remote Desktop Client software. All client workstations should
be updated to Windows XP SP3 or later to take full advantage of the
features of Windows Server 2008 R2 Remote Desktop Services, and to
protect the security of the network.
2.1. Remote Access
RDS provides an ideal solution for the mobile user who needs
to be able to run network-intensive or processor-intensive
applications even over a dial-up connection. Because the local
computer is responsible only for the actual console, the
responsiveness and bandwidth requirements are substantially better
compared to trying to run applications across a slow connection. The
actual bandwidth used for Remote Desktop Services can be tuned by
enabling or disabling certain graphics features to improve
responsiveness over a slow connection.
2.2. Central Management
Because all applications in an RDS session are running on the server, management of
sessions and applications is greatly simplified. Any changes to
applications or settings need only be made once, on the server, and
these changes are seen by all future RDS sessions.
In addition, RDS allows an administrator to view what is
happening in a user’s session, or even to directly control it. Help
desk personnel can actually see exactly what the user is seeing
without leaving their desks. If the user is configured accordingly,
the Help desk person can share control of the session, walking the
user through a difficult problem.
|
The requirements for an RD Session Host (terminal server) depend on the
number of users and the type of applications they run. Because
each user will be executing his or her programs on the server
itself, you need to determine exactly how your users work and what
their real requirements are. Microsoft publishes a detailed white
paper on capacity planning for an RD Session Host (which you can
see at http://www.microsoft.com/downloads/en/confirmation.aspx?displaylang=en&FamilyID=ca837962-4128-4680-b1c0-ad0985939063)
that has far more details than we can cover here and yet still
manages to hedge its recommendations. And rightly so—capacity
planning is subject to an enormous number of variables. So take
the following as merely basic guidelines, and carefully consider
how your environment affects these numbers.
Warning:
IMPORTANT Numbers in
this sidebar are not intended to be definitive, but are a
reflection of the authors’ experience in real-world usage.
System administrators and consultants should refer to the “RD
Desktop Session Host Capacity Planning in Windows Server 2008
R2” white paper referenced above before making final
recommendations.
RAM
Each session on the RD Session Host for a typical knowledge
worker of Microsoft Office 2010—including Microsoft Word, Outlook,
Excel, and PowerPoint—consumes roughly 70 Mb per session. If the
available memory per user drops below this point, excessive paging
can occur, causing an unacceptable user experience. Thus, a server
or virtual machine running Windows Server 2008 R2 with 6 GB of RAM
will easily support all the users you can have in an SBS
environment.
CPU
Predicting exactly how much CPU power will be required per
user is difficult because each user has a different mix of
applications and expectations. A physical server with a single
quad-core processor Windows Server 2008 R2 with sufficient RAM
present to avoid swapping can realistically host somewhere between
100 and 150 users—in other words, more than an SBS network has to
worry about. Even when that server is a virtual machine, the
numbers are quite similar if the CPU supports Second Level Address
Translation (SLAT). Without SLAT, the maximum number of users drops to roughly 50–70 users for a
four-processor virtual machine—still enough to handle the vast
majority of SBS environments.
One factor that affects the number of users per CPU core is
the color depth used for each RDS session. Limiting the maximum color depth to
16-bits per pixel (bpp) significantly improves the capacity of the
RD Session Host server. However, if your RD Session
Host is supporting no more than 50 users, enabling Desktop
Composition (Aero) and 32-bit color should not be an issue.
Network
A typical SBS network with 1 Gbps networking has more than
sufficient network bandwidth to support as many Remote Desktop
clients as necessary. If your network is limited to older 100 Mbps
networking, you might end up with network bandwidth issues if your
RDS users run graphics-intensive applications, even
on an SBS-sized network. Remote users can tailor their RDP
settings to limit bandwidth use over slow connections.
RemoteApps
The maximum number of RemoteApp users that a given server
can support is actually slightly fewer than if the users were
running full sessions with the same application mix. But the
difference is small and is caused by higher CPU usage for
RemoteApp scenarios.
|
2.3. Licensing
Remote Desktop Services use requires special licensing
considerations. In addition to normal Client Access Licenses (CALs),
which are covered by your SBS licensing, you also need to have an
RDS CAL for each user or device that uses RDS functionality. Note
that this includes RD Gateway or RD Web functionality beyond that
included in Windows Small Business Server 2011 Standard.
Unfortunately, RDS CALs are not included as part of either SBS or
the Premium Add-on.
You’ll need to install an RD Licensing server in the SBS 2011 network within 120
days of initially enabling the RD Session Host role, and you’ll need
to choose either per user or per device licensing mode for that RD
Session Host server. The RD Licensing role service can be enabled on the same
server as the RD Session Host role service. It should not be enabled
on the main SBS server.
