Planning and Deploying Session-based Virtual Desktops

Planning infrastructure for session-based desktops

The planning for implementing RDS for session-based desktops can be fairly complex compared to other Windows-based role services. Most Windows-based role services require only one server. RDS requires at least three role services and, in most cases, the role services are spread across multiple servers. You should be aware of the functionality that each role service provides. You also should be aware of how an RDS deployment uses each role service. You need to know role service requirements and which hardware resources are most critical for each role service.

Assessing RDS infrastructure requirements

Before you implement RDS, you must determine your organization’s requirements. To do so, you first must evaluate if RDS is the appropriate solution for your needs, and then you must choose between session-based and VM-based desktop deployments. If necessary, an RDS deployment can include both session-based and VM-based desktop deployments. You also must evaluate the existing server infrastructure and estimate the required server hardware, network bandwidth, client types and requirements, and connectivity needs for a successful RDS deployment.

Determine your RDS needs

To determine if RDS is an appropriate solution for your needs, you should assess and analyze the types of users, hardware, and applications in your organization. Areas of consideration include the following:

• User types Do you have users in remote locations, single-task users, contractors, and other types of users who would benefit from remote applications or virtual desktops?
• Hardware What client hardware currently is deployed in your organization? Would it be beneficial to move from traditional desktops to thin clients for some users? Do you allow users to bring their own devices into the organization’s network? Do users wish to use mobile devices to run certain applications?
• Application compatibility Can the applications run in a multiuser environment? If not, will the applications run in a virtual environment?
• Application performance How do the applications perform in a remote or virtual environment? Keep in mind that many applications perform better as RemoteApp programs on RDS because processing takes place on a server.
• Application support Do vendors support the applications in a virtual or multiuser environment? Do vendors provide support to multiple users?
• Licensing Can the applications be licensed for a virtual or multiuser environment?
• Business benefits Are there justifiable business reasons to implement this solution? Potential benefits include cost savings, reduced deployment time, centralized management, and reduced administration costs.
• Legal requirements Because of financial and legal requirements, some organizations mandate that applications and data remain on-premises. RDS enables users to connect to a standard virtual desktop to use familiar applications and to work with data from almost any device, while organizational data stays in the data center.

Choosing between session-based and VM-based desktop deployments

RDS has two deployment types:

• Session-based virtual desktop deployment This provides users the ability to connect to an RD Session Host and use a full desktop or run remote applications and present them on a client as if they were installed locally.
• VM-based virtual desktop deployment This provides users with access to a full Windows client operating system that runs on a VM, for example, Windows 7 or Windows 8.1.

You need to decide which RDS deployment type is best for your environment based on various requirements. For example, you must consider if users must be completely isolated or if they must have administrative access. You should consider whether the applications work properly in a multiuser environment. In addition, you must consider whether you can install and run applications on Windows Server. Remember that a VM-based virtual desktop deployment typically requires a more powerful server infrastructure and more disk storage than a session-based virtual desktop deployment for the same number of users. For some applications, VM-based virtual desktops might be the only viable solution.

Generally, you should choose session-based virtual desktops if possible. Session-based virtual desktops support a larger number of users than VM-based virtual desktops on the same hardware.

Determine server hardware and network resource requirements

Once you determine the RDS deployment benefits for your organization, you must consider the hardware requirements to support your users, including the following:

• Number of users How many users will use RDS, and where are they located?
• User types How many users run CPU-intensive and bandwidth-intensive applications? Will you have to provide more bandwidth and server hardware to support expected usage?
• Connection characteristics How many concurrent connections do you expect? Can your server and bandwidth resources handle peak usage times?
• Application silos Will you have to create multiple server collections to support different applications that might not be able to run on the same server?
• Load balancing Will you have to include multiple servers in a collection to spread the load among the servers? This increases available resources and provides redundancy.
• High availability What is the organization’s tolerance for downtime? Do you need close to zero downtime, or could your organization tolerate the time it would take to restore from backups?
• Expansion considerations What are the growth expectations? At what point will new resources need to be brought online?

Determine user requirements

Another aspect to consider is user requirements. A large organization with multiple locations might have a number of mitigating factors to consider, such as the following:

• Languages Organizations with a global presence need to support multiple languages. You might need to install language packs on all of your RDS servers.
• Profile management How will you store user states? Do users require the same user state when they sign in locally and to an RDS session? Which type of Windows user state virtualization will be used?
• Printing Will existing printers function properly in a remote desktop environment? Will there be problems finding printer drivers to support existing printers? Is there a budget to replace older printer models?

Determine how clients access RDS

Clients can connect to RDS in various ways. You probably will need to provide different access methods for different groups of users. Areas to consider include the following:

• Will you allow users to connect over the Internet from remote locations? If so, you will need to set up an RD Gateway and obtain certificates.
• How will you handle Secure Sockets Layer (SSL) certificates—by using certificates from non-Microsoft certification authorities (CAs) or by using certificates that an internal CA issues?

Based on your assessment results, start designing your RDS deployment. You should identify RDS role services that are required and that you will deploy. You also should determine the number and hardware configuration of servers that are required, in addition to planning required storage, connectivity, and firewall configuration.

Planning for the RD Session Host role service

The RD Session Host role service provides Windows-based apps or full Windows desktops for RDS clients. This role service is mandatory for every RDS deployment that provides users with session-based desktops or RemoteApp programs. An RD Session Host server accepts incoming RDP requests, and after a client authenticates, it provides a desktop-based or application-based session to the client. An RD Session Host server is the central location where remote applications are installed, accessed, and maintained.

To plan the deployment of an RD Session Host server, you must consider the number of installed applications, the type of applications, resource use, the number of connected clients, and the type of user interaction. While connected to one RD Session Host, users might run a simple application that has low resource utilization and rarely runs, for example, an old data entry application. On another RD Session Host, users often might run a resource-intensive graphical application that requires many CPU resources, a considerable amount of RAM, intensive disk I/O operations, and that causes a lot of network traffic. If the hardware configuration on both of the RD Session Hosts is the same, the second server is considerably more utilized and can accept fewer user connections.

RD Session Host planning focuses on the number of concurrent users and the workload they generate. A server with a particular hardware configuration might support many simultaneous users or only a few, depending on their usage patterns and the applications that they are running on the RD Session Host.

The following are the main resources that you should consider when estimating RD Session Host utilization:

• CPU Each remote application that users start runs on an RD Session Host and utilizes CPU resources on the RD Session Host. In an environment where many users are connected to the same host, CPU and memory typically are the most critical resources.
• Memory Additional memory must be allocated to an RD Session Host for each user who connects to the RD Session Host, whether connecting to a full Windows desktop or running a RemoteApp program.
• Disk Because user state typically isn’t stored on an RD Session Host, disk storage usually isn’t a critical resource. However, many applications run simultaneously on an RD Session Host, and the disk subsystem should be able to meet their disk I/O needs.
• Network The network should provide enough bandwidth for connected users and for the applications that they run. For example, applications that use a SQL database use the network to connect to that SQL database. Also remember to consider the network bandwidth required to support the user connectivity to the RD Session Host server.
• GPU Applications that are graphically intensive, especially those that include three-dimensional graphics, might require vGPU support and RemoteFX to perform well. Without such support, graphics render on the server’s CPU and may limit the number of users on the RD Session Host to a relatively small number.

When estimating the required resources for an RD Session Host, you can use one of the following methods:

• Pilot deployment This is a common and a simple approach. You first need to deploy RDS in a test environment and capture its initial performance. After that, you start increasing server load by increasing the number of users and monitoring response times and user feedback. You can find out how many users can connect to an RD Session Host and still have an acceptable user experience based on the number of users and the system response time. Based on the findings, you can estimate the number of servers that are needed for a production environment. This approach is reliable and simple, but it requires initial investments for the pilot deployment.
• Load simulation This method also uses an initial RDS deployment in a test environment. You need to gather information about applications that users operate and how users interact with the applications. After that, you can use load simulator tools to generate various levels of typical user loads against an RDS deployment. When a load simulator tool runs, you need to monitor server utilization and responsiveness. This method is similar to the pilot deployment method, but it uses a load simulation tool instead of real users to generate user load. It also requires an initial investment, and its results depend on the initial estimation of actual user usage.
• Projection based on single-user systems This method uses data that is collected from a single-user system for projecting expected utilization on an RD Session Host with multiple user sessions. This method requires detailed knowledge of applications that are used, and it usually is not very reliable because a single-user system has a different overhead than a multiuser system.

It is critical that you plan for future scalability of an RDS deployment. User needs for applications will change over time, and you need to be ready to expand your RDS deployment to meet those needs. In some cases, you may be able to scale up the capacity of the individual servers with additional processors or additional memory. Scaling up by using more powerful servers tends to be expensive. Scaling out by adding servers generally is less expensive.

Fortunately, you can scale out an RDS deployment for session-based virtual desktops and RemoteApp programs by adding RD Session Host servers. For example, if you have an RDS deployment for session-based virtual desktops that uses two RD Session Host servers, and those two servers are experiencing frequent peaks of 100 percent CPU utilization, you can add a third RD Session Host server. The RD Connection Broker then automatically load balances the connections across three servers instead of two and reduces the CPU utilization on the two existing servers.

Planning for the RD Connection Broker role service

During RDS deployment planning, you must designate a server on which to install the RD Connection Broker role service. The RD Connection Broker role service is required in each RDS deployment. It provides users with access to RemoteApp programs, session-based virtual desktops, and VM-based virtual desktops. The RD Connection Broker role service manages all aspects of session connectivity. Functions performed by the RD Connection Broker role service include the following:

• Routes connection requests Determining the most appropriate RD Session Host or virtual desktop to which to send a connection request, based on a user’s identity and the current load on RD Session Host or RD Virtualization Host servers.
• Stores information about connections to VMs and sessions By default, connection information is stored in the Windows Internal Database (WID) on an RD Connection Broker server. By storing this information, the RD Connection Broker role service can reconnect users to the same session in an RDS deployment with multiple RD Session Host servers.
• Configures RDS servers in the same group (collection) You configure settings—for example, session settings or certificates—once, and RD Connection Broker applies the settings to servers in the collection.
• Manages VM creation and deletion In VM-based desktop deployments, RD Connection Broker manages VM creation and deletion for managed collections, and it assigns personal virtual desktops to users.
• Provides information to RD Web Access servers The RD Connection Broker role service gathers collection information about RemoteApp programs, session-based virtual desktops, and VM-based virtual desktops.

When a user initiates a session, the session request is received by the RD Connection Broker role service, which queries the database to determine if there is an existing disconnected session for that user. If so, the user is directed to the disconnected session. If not, the RD Connection Broker role service determines the server in the collection that is best able to handle the new connection, based on the load-balancing algorithm.

A single RD Connection Broker server can handle a large number of connection requests, and for performance, your RDS deployment may require only one. A more critical consideration for the RD Connection Broker role service is availability.

The RD Connection Broker role service is an entry point to an RDS deployment, and it is critical that it is available all the time. If the RD Connection Broker role service isn’t available, then clients can’t connect to RemoteApp programs or virtual desktops, but existing connections to RemoteApp programs and virtual desktops continue to function properly. When an RDS deployment only has one RD Connection Broker server, the server represents a single point of failure. To make the RD Connection Broker role service highly available or to increase scalability, you can add RD Connection Broker servers.

• Configuring high availability for the RD Connection Broker role service is covered in more detail later in this chapter in the section titled “Understanding high availability for RDS.”

Planning for the RD Web Access role service

The RD Web Access role service is a mandatory part of each RDS deployment, and it installs the Web server role, Internet Information Services (IIS), as its prerequisite. The benefits of RD Web Access include the following:

• From almost anywhere, authorized users quickly can access a list of available RemoteApp programs, remote desktops, and virtual desktops on a webpage.
• A list of available RDS resources publishes automatically via an RDWeb feed, and it can integrate with the Start screen on the client.
• Changes in available RDS resources update automatically on clients that have subscriptions to an RDWeb feed.
• Users can launch the RDC client from the RD Web Access portal, which enables them to connect remotely to the desktop of any computer on which they have Remote Desktop access.
• RD Web Access and RDWeb feeds are personalized and show only RDS resources for which users have permissions.
• Administrators can customize an RD Web Access portal without programming.

• More information about customizing RD Web Access is provided in Chapter 9, “Configuring RemoteApp programs and client connectivity.”

It’s important to remember that the RD Web Access role service only provides a link to launch RemoteApp programs or to connect to a Remote Desktop session. The RD Web Access role service doesn’t proxy client requests. When a user connects to a RemoteApp program or a virtual desktop, the client establishes a direct connection to the target server.

Performance considerations for an RD Web Access server are similar to those for an RD Connection Broker server because the RD Web Access role service provides only initial connectivity to RemoteApp programs and virtual desktops. After users are connected to requested resources, the RD Web Access role service is no longer used. Therefore, RD Web Access server performance needs to be designed to accommodate usage at peak times like morning arrivals and after lunch. If required for high availability or scalability, you can implement multiple RD Web Access servers and load balance them.

Planning for preserving user state

In a session collection with multiple RD Session Host servers, the connections from clients are load balanced across the RD Session Host servers by the RD Connection Broker server. By default, when a user connects to a specific RD Session Host server, a local profile is created for that user on the RD Session Host server. The next time a user connects, the RD Connection Broker may direct the client to a different RD Session Host server, where a different local profile is created. Each time users sign in, they may be using a different profile on a different RD Session Host server. This means that user state information such as application configuration, Desktop configuration, Favorites, and Documents are not the same across sessions. To provide a consistent user experience, you should preserve user state across multiple RD Session Host servers.

If users have desktop computers and session-based virtual desktops, you also need to consider whether you want user state to be preserved between desktop computers and the virtual desktops. This can be complicated by the fact that session-based virtual desktops may not have the same configuration as the desktop computers, and, consequently, it may not make sense to synchronize all of the user state information. For example, synchronizing Desktops may result in desktop shortcuts appearing that point to applications that are not available on the RD Session Host servers.

Roaming profiles

Roaming user profiles can be used to synchronize user state, but they synchronize entire user profiles. This typically is not desired for session-based desktops because not all user state information needs to be synchronized between desktop computers and RD Session Host servers. If you use roaming profiles for the desktop computers in your organization and you want to ensure that roaming profiles are not used on the RD Session Host servers, then you can configure the msDS-PrimaryComputer attribute for users and enable the Download Roaming Profiles On Primary Computers Only Group Policy setting.

You also can set user properties for roaming user profiles that are specific to RD Session Host servers, as shown in Figure 8-7. If you configure the Profile Path, then a user connecting to a session-based virtual desktop uses the specified profile path rather than a roaming profile configured on the Profile tab. Effectively, the RDS user profile becomes a roaming profile used only when connected to an RD Session Host server.

Instead of configuring individual user accounts with RDS-specific profiles, you can use Group Policy. In a Group Policy object that applies to the RD Session Host servers, you can configure settings in Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Profiles. There are two relevant settings:

• Set Path For Remote Desktop Services Roaming User Profile Specify a UNC path for storing all user profiles. A subfolder for each user is created automatically.
• Use Mandatory Profiles On The RD Session Host Server Indicates that the path specified in the Set Path For Remote Desktop Services Roaming User Profile setting contains a mandatory profile that can’t be modified. When this setting is enabled, the UNC path for profiles does not contain subfolders for each user.

Folder redirection

Folder redirection also is an option for users with session-based virtual desktops. You can redirect only the folders that are suitable for use on the virtual desktops and desktop computers. Commonly redirected folders include Documents, Favorites, and AppData\Roaming.

If you use folder redirection for desktop computers and don’t want folder redirection used when users sign in to the RD Session Host servers, you can use the msDS-PrimaryComputer attribute in user accounts just as you can for roaming profiles. In addition to configuring the attribute, you need to enable the Redirect Folders On Primary Computers Only Group Policy setting.

User profile disks

RDS in Windows Server 2012 and newer offers the option to configure user profile disks to preserve user state across sessions. A user profile disk is a VHDX file that is mounted to the user’s profile path at C:\Users\%username% on the RD Session Host. The user profile disk is mounted during sign in. During a user’s session, all changes to the profile write in his or her VHDX file, and when the user signs out, his or her profile disk is unmounted. The administrator specifies the maximum size of user profile disks and can limit which folders in a user profile are included in or excluded from a user profile disk.

User profile disks are configured individually for each session collection and can’t be shared among collections. A share is specified in the collection configuration to store the user profile disks. All RD Session Host servers in the collection have access to the user profile disks in the share. This provides users with consistent user state from any RD Session Host server in the collection.

User profile disks can be used in conjunction with folder redirection and roaming user profiles. Folder redirection will reduce the size of user profile disks and allow the redirected folders to be accessed from desktop computers. Roaming user profiles are synchronized with the user profile disk.

From a server management perspective, one benefit of user profile disks is controlling the amount of data stored on the C drive of RD Session Host servers. Large user profiles stored on RD Session Host servers can cause the C drive to run low on space and cause performance issues. Because user profile disks are stored on a network share and mounted in C:\Users, the C drive never is used to store profile data.

The primary consideration when planning user profile disks is ensuring that the necessary disk space is available for network storage. To ensure that network storage is sufficient, you need to determine the average user profile size. The amount of storage that you need to allocate for user profile disks is the average user profile size times the number of users plus an allowance for growth in both the number of users and the average profile size.

User profile disks are dynamically expanding VHDX files. By default, the maximum size of a user profile disk is 20 GB, but you can set this to be larger or smaller depending on the needs of your users.

When you configure the share for user profile disks, all RD Session Host servers need to have Full Control permissions. This allows the RD Session Host servers to create and manage the user profile disks. When you configure a collection with user profile disks, these permissions are assigned automatically.