Windows Server 2008 R2 Unleashed (185 page)

session usage. You should perform performance testing during both peak and nonpeak

times to ensure proper data collection. Increase memory and processors or introduce addi-

tional RD Session Host servers as necessary. Understanding the users’ resource needs and

950

CHAPTER 25

Remote Desktop Services

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 manage-

ability, 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 applica-

tions, 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 orga-

nization’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

ptg

For more information on scaling Terminal Services, refer to Microsoft’s “Windows

Server 2003 Terminal Server Capacity and Scaling” whitepaper. Although the informa-

tion 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 effi-

ciently 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.

Planning for Remote Desktop Services

951

. Use System Center Operations Manager 2007 or other operations management soft-

ware 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.

25

NOTE

These performance monitoring objects have not been renamed in Windows Server

ptg

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 read-

ings 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 avail-

able 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

As mentioned previously

in this chapter, 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. For

more information on using the Windows Resource Manager, refer to Chapter 34,

“Capacity Analysis and Performance Optimization.”

952

CHAPTER 25

Remote Desktop Services

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 function-

ality 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 func-

tionality. 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

ptg

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 compati-

ble 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 fire-

walls 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 band-

width 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

Deploying Remote Desktop Services

953

servers depending on the application being used. For optimum performance for multi-

tiered 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 tech-

nology 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 prefer-

ence should be for a technology that can either manage Remote Desktop sessions or use

information from the RD Connection Broker. Lastly, if NLB is being used, load balancing

of the Windows Server 2008 R2 servers should be configured per best practices that are

outlined in Chapter 29, “System-Level Fault Tolerance (Clustering/Network Load

25

Balancing).”

ptg

Deploying Remote Desktop Services

After the Remote Desktop Services deployment has been planned, it is a best practice to

then install and configure RDS in a lab environment. Then after the deployment has been

verified, the next step is to install it into production and have it tested by IT personnel or a

designated pilot group. Lastly, after being tested by these groups, the deployment can

finally be released into full production to end users. By following this best-practice method,

administrators can reduce many of the inherent risks associated with deploying Remote

Desktop Services while also verifying the infrastructure is ready to support end users.

The following subsections contain detailed instructions on how to install and configure

Windows Server 2008 R2–based Remote Desktop Services for a typical enterprise deploy-

ment that only includes several RDS servers.

Enabling Remote Desktop for Administration

Remote Desktop for Administration is installed on all Windows Server 2008 R2 servers by

default and only needs to be enabled. To enable this feature, follow these steps:

1. Log on to the desired server with local administrator privileges.

2. Click Start, and then click Run.

3. In the Run dialog box, type in ServerManager.msc and click OK.

4. After the Server Manager console is displayed, select the Configure Remote

Desktop task.

5. In the Systems Properties dialog box, on the Remote tab, and in the Remote Desktop

section, select the Allow Connections Only from Computers Running Remote

954

CHAPTER 25

Remote Desktop Services

Desktop with Network Level Authentication (More Secure) option button, as shown

in Figure 25.1.

ptg

FIGURE 25.1

Allowing users to connect to the system remotely.

6. Click OK in the Systems Properties dialog box to complete this process.