Windows Server 2008 R2: Remote Desktop Services - An Owner’s Manual

  • Article

Using Remote Desktop Services with Windows Server 2008 R2 opens a whole range of deployment scenarios using the new server roles and other features.

Kristin Griffin

It’s not uncommon for people experienced with Terminal Services on Windows Server 2003 to be unsure of which Remote Desktop Services (RDS) role services support which use cases. Not everyone has time to fully design a deployment, either—it’s often a case of “deploy first, ask questions later.”

RDS in Windows Server 2008 R2 is quite different from Terminal Services in Windows Server 2003. That earlier version only supported a Terminal Server and a license server in the Standard edition.

RDS supports sessions and license management, with many improvements to the user experience and license management functions. It also includes native virtual machine (VM) support, as well as server roles to facilitate discovery, connection brokering, server farms (for larger-scale deployments and redundancy) and secure WAN access.

Over the next few months, you’ll learn how to best get started using RDS, starting with familiar scenarios like single-server session delivery, and then moving to Virtual Desktop Infrastructure (VDI), which is new in Windows Server 2008 R2. Then you’ll learn about larger deployment scenarios using RD Session Host server farms and RD Connection Broker, enabling discovery using RD Web Access, and enabling WAN scenarios with RD Gateway.

Single-Server Session Delivery

Formerly known as Terminal Server, Remote Desktop Session Host (RD Session Host) server is the RDS server role. It can deliver both full desktops and individual applications, known as RemoteApp programs. It’s ideal for highly scalable application delivery. Multiple users can log into an RD Session Host server and run applications independently of each other.

Although any Windows server can accept up to two concurrent incoming RDP connections for administrative purposes, only an RD Session Host server can support more than two remote connections, while still enabling all the advanced features of Remote Desktop Protocol (RDP) 7.

A single-server deployment is best suited for smaller environments such as a small business or branch office. A single server is also the easiest RDS scenario to deploy. You’ll need to keep the following in mind:

  • The single server limits the number of sessions that can be accommodated.
  • A one-server deployment is a single source of failure. If you lose the server, all connections are affected. There’s no redundancy.

Enabling RD Session Host

To enable an RD Session Host server, you must first install the RDS role on the Windows server. Then install the RD Session Host role service. As you go through the installation, you’ll have to:

  • Choose whether to require Network Level Authentication (NLA) for logons. NLA enables user authentication before creating a full session on the RD Session Host server. This provides both faster logon and protection from intentional connection storms that could lead to a Denial of Service (DoS).
  • Add the user groups you wish to allow access to the RD Session Host server on the Remote Desktop Users group on the server.
  • Configure user experience options by allowing (or disabling) audio and video playback, audio recording and Desktop Composition (enabling Desktop Composition enables Aero features).
  • Specify a license mode for the server. Each user or device needs a license to connect to an RD Session Host server. Choose licensing Per User or Per Device for these connections. You don’t have to set up a license server right away because there is a grace period.

Setting up the client side is easy. The Remote Desktop Connection (RDC) client is part of the Windows OS. To ensure that you have the best user experience, you should install the latest RDP client if you’re using a version of Windows prior to Windows 7. You can download the most recent clients from the Microsoft Web site.

Licensing Requirements

Once the licensing grace period is past, you must have a license for each connecting user or device to connect to an RD Session Host server. You’ll also need to install an RD Licensing server. You can install the RD Licensing role service on the same server—the service isn’t very demanding—or on a separate server.

You’ll need to purchase RDS Client Access Licenses (CALs) and install them on the RD Licensing server. These RDS CALs are tied to the server, but RDS lets you move them to new hardware if needed. Remember that RDS supports both per-user and per-device licensing. The model you choose should depend on whether you have more users or computers. RDS does not have concurrent-user licensing, and the licenses you choose must match the mode for which you configure the RD Session Host server.

Install the RD Licensing role service just as you did the RD Session Host role service. Then you must:

  • Activate the RD Licensing server
  • Install RDS CALs so the RD Licensing server can allocate them to users and devices
  • Tell the RD Session Host server to use the RD Licensing server (you must do this even if the two role services are located on the same machine)

Server Sizing

One of the most common questions from people new to session hosting is how many people can use the server at the same time. Unfortunately, there’s no easy answer to this question. It depends entirely on conditions such as, but not limited to, which applications people are running, and the type of data with which people are working.

Many people estimate size based on a pilot to get real-world numbers for themselves. To help with usage modeling, the RDS product group has created a white paper and a load-simulation tool. Fortunately, Windows Server 2008 R2 is 64-bit only, so memory is not a bottleneck as it can be on a 32-bit OS.

You can virtualize an RD Session Host server, but you’ll likely see a reduction in the number of simultaneous sessions it can support. Be sure to model on the same machine type (physical or virtual) you intend to use. If you do build a virtual RD Session Host server, you should probably use a server with a processor supporting second-level address translation (SLAT) to reduce the overhead of memory mapping between the physical machine and the VMs. To reduce overhead, it’s also advisable to use a Type 1 hypervisor like Hyper-V, not a Type 2.

Full Desktop Sessions vs. RemoteApps

RD Session Host servers support two application delivery models: full desktops separate from the local desktop or RemoteApp programs that visually integrate with the local desktop. The latter appear to the user as local applications. RemoteApp programs are best for environments where users run a mix of local and remote applications because they won’t have to switch between two desktops.

RemoteApp programs launched by the same user and on the same server will all run in the same session. You’ll only need one copy of the profile opened. This will reduce the overhead on the server, because you’ll only have to launch one copy of the core processes needed to run a session.

This is a relatively quick overview of single-server deployment, what you’d use sessions for, some differences between RemoteApps and sessions, and the RDS licensing model. Next month, you’ll be introduced to Microsoft VDI.

For detailed instructions on how to deploy RDS and design guidance, look for the Windows Server 2008 R2 Remote Desktop Services Resource Kit, from Microsoft Press.

Kristin Griffin

Kristin Griffinis a Remote Desktop Services MVP. She moderates a Microsoft forum dedicated to helping the server-based computing community (social.technet.microsoft.com/Forums/en-US/winserverTS/threads/) and maintains an RDS blog at blog.kristinlgriffin.com. She’s a contributor to Mark Minasi’s Mastering Windows Server 2008 and 2008 R2 books (both from Wiley), she also coauthored the “Microsoft Windows Server 2008 Terminal Services Resource Kit” (MS Press, 2008) and the “Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit” (released in December 2010), with Christa Anderson.

Related Content

SIDEBAR

RDS FAQs

Here are several common questions I hear regarding configuring and using Remote Desktop Services (RDS), and answers to resolve them.

Q. I noticed different executables running in Task Manager when I start a RemoteApp from when I run a full desktop. Why?

A. RemoteApps and full desktops use different shells and logon mechanisms. Full desktops use EXPLORER.EXE to present the user with the desktop, whereas RemoteApps use RDPSHELL.EXE. RemoteApps use RDPINIT.EXE, the RemoteApp equivalent of USERINIT.EXE used in full desktop sessions, which in turn both launches RDPSHELL.EXE and updates the client-side taskbar and handles logoff logic.

Q.  Do you still need to lock down the server when you use RemoteApp programs?

A. Absolutely. RemoteApp programs are a display convenience, not a security feature. If a user can get to the file system, they can run any executable they have access to, so you’ll need to lock down the server. You can use AppLocker (or Software Restriction Policies), NTFS permissions and Group Policy to lock down your servers.

Q. Can you configure a server to only permit users to connect via RemoteApps, and block a user from connecting to the desktop?

A. No, this option is not supported.

—K.G.