To successfully deploy a Remote Desktop Services
environment requires thorough planning and testing prior to production
rollout. Criteria such as application resource usage, security
requirements, physical location, network access, licensing, fault
tolerance, and information indicating how
users will be utilizing their sessions all contribute to the way Remote
Desktop Services implementation should be designed.
Planning for Remote
Desktop for Administration
Unless Remote Desktop
Services is viewed as a security risk, it is recommended to enable
Remote Desktop for Administration on all internal servers to allow for
remote administration. For servers that are on the Internet and for
demilitarized zone (DMZ) networks, Remote Desktop Services can be used,
but access should be limited to predefined separate IP addresses using
firewall access lists to eliminate unauthorized attempts to log on to a
server. In addition, those servers should be closely monitored for
unauthorized attempts to access the system.
Planning for RD Session
Host Requirements
Deploying RD Session Host
servers can require a lot of planning. Because the goal is to make
applications and entire desktops available to end users, server hardware
specification and application compatibility are key components to test
before a production rollout.
User Requirements
It is important to
determine user requirements based on typical usage patterns, the number
of users accessing the system, and the number of applications that are
required to run. For instance, the more applications that a user will
run in a session, the more processing power and memory will be required
to optimize session performance. On average, a Remote Desktop user who
runs one application might take 10MB of RAM and use little more than 3%
of a server’s total processing time per session. A power user who runs
three or more applications simultaneously might require 40MB of RAM or
much more, depending on the applications and features being used. Use
the Performance Monitor MMC snap-in to test and validate usage
statistics. The key is to not overload the server to the point where
performance is too slow to be cost effective. Additionally, the
bandwidth required by each user session will also affect how well the
system performs under various workloads.
Antivirus on Remote
Desktop Services
Just as standard servers require
operating system (OS)–level antivirus software, so do Remote Desktop
Services servers. When choosing an antivirus product, be sure to choose
one that is certified to run on Windows Server 2008 R2 Remote Desktop
Services. Additionally, for RD Session Host servers, install the
antivirus software after adding the role service so that scanning will
work for all Remote Desktop sessions.
Application
Compatibility
In Remote Desktop Services,
application compatibility is a term used to describe a number of issues
that might be encountered when trying to deploy an application on an RD
Session Host server. For example:
1. | Some
applications are written such that only a single user can use the
application at a time. With such applications, conflicts with system
resources—such as files, Registry
entries, pipes, IP addresses, and ports, which are used concurrently by
multiple instances of applications—might prevent an application from
being concurrently executed on an RD Session Host server.
|
2. | In some cases, an application’s preferences might
persist or manifest from one user to the next. When this scenario
occurs, there is concern with user data privacy because settings (data)
are transiting from one user to the next.
|
3. | Additionally, an application might be written such that
execution of the application requires administrative privileges.
However, in most Remote Desktop Services deployments, regular users are
not granted administrative access on an RD Session Host server.
|
4. | Applications might also be written such that network
bandwidth or hardware constraints cause application performance to
suffer in a multiuser usage scenario. For example, a large amount of
video or animation content might overwhelm the RD Session Host’s network
connection, video card, and so on, thus reducing response time. Or, the
application was simply written such that it requires a large amount of
CPU or memory, thus monopolizing resources.
|
5. | In some cases, an application might require devices
that are not redirected by default, for example, devices such as CD
drives, hard disk drives, and other special devices that are not
available as native devices.
|
6. | Or, an application is written for a particular version
of Windows and, thus, its API usage and behavior might differ on Windows
Server 2008 R2.
|
To help administrators
determine if an application is compatible before it is deployed on an RD
Session Host server, Microsoft provides a tool called the Remote
Desktop Services Application Analyzer. When this tool is executed
against an application, it uses Microsoft Application Verifier to
analyze an application via intercepted function calls from that
application into the operating system and notes the calls and the
parameters passed. Then based on the information returned from the
Microsoft Application Verifier, the Remote Desktop Services Application
Analyzer generates a summary report of any RDS incompatible behavior and
recommendations about deploying the application on an RD Session Host
server. For example:
1. | Any
shared resources such as files and Registry entries that the application
might require
|
2. | Any type
of access privileges issues that might be encountered
|
3. | Any API usage requirements that might conflict with RDS
|
Planning for RD Session
Host Sizing and Optimizing
An RD Session Host server
can be sized to deliver high-performance Remote Desktop sessions by
estimating the amount of resources each user will require and the number
of users who will utilize Remote Desktop Services. Performing frequent
performance testing on the RD Session Host server helps generate
accurate information on Remote Desktop session usage. You should perform
performance testing during both peak and nonpeak times to ensure proper
data collection. Increase memory and processors or introduce additional
RD Session Host servers as necessary. Understanding the users’ resource
needs and the number of users will help you decide how to specify the
server hardware requirements and determine how many RD Session Host
servers you need to support the load.
Scaling RD Session Host
Servers
Scaling RD Session Host
servers can be achieved by increasing server resources, such as the
number of processors and the amount of memory, as well as by increasing
the number of servers that are servicing requests. When determining how
to scale, also consider manageability, cost, and how end users might be
affected if a server goes offline. For instance, using a greater number
of servers might decrease manageability (such as updating applications,
keeping up with operating system updates, and other maintenance), but if
a server goes down, fewer users will be affected. The solution will
vary depending upon your organization’s needs and circumstances.
Another
consideration is the amount of flexibility your organization requires.
Using more instead of bigger servers gives more flexibility because of
the redundancy as well as the capability to take servers offline for
maintenance. In this scenario, it is important to use servers with
enough power to sustain slightly greater workloads during those times
when other servers in the farm go offline.
Note
For more information on
scaling Terminal Services, refer to Microsoft’s “Windows Server 2003
Terminal Server Capacity and Scaling” whitepaper. Although the
information found in this whitepaper refers to Windows Server 2003
Terminal Servers, the information provided in this document is still a
good base until Microsoft releases updated information.
Optimizing RD Session
Host Performance
Optimizing performance on an RD
Session Host is a challenging task because of the complexities in any
environment. Hardware resources, applications, usage, the number of
users to support, and much more can affect how well a Remote Desktop
session responds to user interaction. There are rarely cases where there
is one “silver bullet” that can improve overall performance; it takes a
combined approach. For instance, from a user perspective, video, color
depth, audio redirection, printer redirection, and encryption level all
affect how well a system performs.
The following are best
practices for ensuring that an RD Session Host server runs as
efficiently and effectively as possible:
Limit users to a
single session.
Log off disconnected or idle sessions after a specified
period of time.
If
using vendor printer drivers, only use drivers that have been certified
for Windows Server 2008 R2.
Use applications that are certified to run on Windows
Server 2008 R2 RD Session Host servers.
Use System Center Operations Manager 2007 or other
operations management software to monitor an RD Session Host server
farm.
For medium
and enterprise deployments, use a separate server or group of servers
with a fast disk subsystem to store redirected folders.
Block Internet websites
that use a lot of animation.
Prevent the usage of applications that use a lot
animation.
Prevent users from installing applications such as
games or desktop enhancements/themes.
Utilize folder redirection to roam user data
between RD Session Host servers.
Monitoring RD Session
Host Servers
The Performance Monitor MMC
snap-in can be used to monitor a Remote Desktop Session Host server and
to gather session statistics. The two specific performance monitoring
objects for an RD Session Host server are Terminal Services and Terminal
Services Session.
Note
These performance monitoring
objects have not been renamed in Windows Server 2008 R2 and as such
reflect the old “Terminal Services” naming convention.
The first object,
Terminal Services, has only three counters: active sessions, inactive
sessions, and total sessions. Gathering this session data and teaming it
with information such as Server Memory\Available Bytes and Processor\%
Idle can give an administrator a clear understanding of RD Session Host
usage and load. This information can be used to determine whether
additional resources or servers need to be added to accommodate load or
enhance performance. For example, one adjustment that can be made after
taking readings from these counters is the implementation of
disconnected session time limits to free server hardware resources for
active sessions. The second performance object, Terminal Services
Session, has a number of different performance counters available in
relation to Remote Desktop sessions. When using this performance object,
an administrator can then gather statistical information, such as how
much memory and processor time the average Remote Desktop session uses.
Lastly, be sure to also monitor network interfaces for available
bandwidth to ensure that the RD Session Host server is not creating a
bottleneck between clients and other back-end servers.
Using Windows System
Resource Manager to Control Resources
The Windows System Resource Manager (WSRM) can be used to
limit the amount of CPU and memory an application can use. On a Remote
Desktop Session Host server, you can assign distinct settings based not
only on an application, but also on a specific user or group as well.
This helps to enforce consistency among user sessions and prevent rogue
applications or sessions from negatively affecting other user sessions.
Planning for RD Session
Host Upgrades
Upgrading an RD Session Host server can be tricky
and should be handled with caution. Before any operating system or
application updates or patches are applied on a production RD Session
Host server, they should be thoroughly tested in an isolated lab server.
This process includes knowing how to properly test the application
before and after the update to be sure the update does not cause any
problems and, in some cases, adds the functionality that you intended to
add.
When an RD Session Host server’s
operating system is to be upgraded to the next version, many issues can
arise during the upgrade process. Applications might not run properly in
the next version because key system files might be completely
different. Even printer drivers can be changed drastically, causing
severe performance loss or even loss of functionality. Lastly, you need
to consider that the existing RD Session Host server could have been
modified or changed in ways that can cause the upgrade to fail,
requiring a full restore from backup.
Note
Complete disaster
recovery and rollback plans should be available during upgrades. This
way, if problems arise, the administrator does not have to create the
plan on the spot, ensuring that no important steps are overlooked.
As a best practice and to
ensure successful upgrades of RD Session Host servers, replace existing
servers with cleanly built RD Session Host servers with the latest
updates. This includes re-creating each of the file shares and print
devices and using the latest compatible drivers to support each of your
clients. If necessary, an existing server can also be rebuilt from
scratch and redeployed to the production environment if the hardware can
still meet performance requirements.
Planning the Physical
Placement of Remote Desktop Services
Place your Remote
Desktop Services servers where they can be readily accessed by the
clients that will primarily be using them. Also, to keep network
performance optimized, try to place RD Session Host and RD
Virtualization Host servers on the same network segment as other servers
that clients might use in their session, such as domain controllers,
database servers, and mail servers. This way, you can reduce traffic on
the network and improve Remote Desktop session performance. However, if
security, as opposed to performance, is of concern, you should also take
any appropriate steps needed to secure a Remote Desktop Services
deployment such as deploying Application-layer firewalls like Forefront
Threat Management Gateway or any other needed network controls.
Planning for Networking
Requirements
To keep Remote Desktop
sessions running efficiently, adequate available network bandwidth is a
must. Additionally, it’s important to remember that a Remote Desktop
session not only requires network access to the RD Session Host, but
might need access to other servers depending on the application being
used. For optimum performance for multitiered applications, install two
or more network cards on an RD Session Host server and either configure
the server to use one exclusively for Remote Desktop session
connectivity and the other(s) for back-end server communication or
consider leveraging teaming technology to aggregate the bandwidth
provided by all the network cards.
Planning for RD Session
Host Tolerance
A fault-tolerant RD Session
Host farm can be created using NLB, using other hardware vendor
load-balancing technologies, or using the RD Connection Broker. If the
RD Connection Broker is being used, an administrator needs to create the
correct DNS records for the RD Session Host farm and all of its
servers. Additionally, an administrator will need to add each RD Session
Host server to the RD Connection Broker’s Session Broker Computers
Local Group. If a third-party load-balancing technology is being used, a
preference should be for a technology that can either manage Remote
Desktop sessions or use information from the RD Connection Broker.
