Using Remote Desktop Services with Windows Server 2008 R2 opens a whole range of deployment scenarios using the new server roles and other features.
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.
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:
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:
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.
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:
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.
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 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.
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.