There have been a number of new features introduced to Remote Desktop Services in Windows Server 2012 that make the deployment of desktop virtualization an attractive option for businesses looking to enhance the experience of their desktop users. This post will briefly review the concept of desktop virtualization and the two primary deployment models but will focus primarily on session-based desktop virtualization architecture. This post is intended for administrators or engineers considering desktop virtualization deployment options.
Desktop virtualization allows you to abstract the desktop and application environment from the endpoint device, centrally manage and deploy applications and offer flexibility to your end-users. There are two primary deployment models: session-based and virtual machine-based desktop virtualization. Regardless of which deployment model (or combination) you choose, you can realize a number of benefits. Users can securely access their corporate desktop and applications from a thin-client, from a tablet in a coffee shop or from their computer at home.
Instead of deploying full desktop computers which require you to maintain support agreements and pay for OS and application licenses, you can simply deploy thin client devices with no moving parts to each desk. By providing a standardized desktop environment and removing hardware support from the equation, you also reduce support overhead. Centralized OS and application management improves security and reduces the risk of malware infections or other compromises due to misconfiguration.
Provisioning a new desktop environment becomes a simple task of setting up a new user and placing a thin client device on their desk. Centralizing the desktop environment in the data center, or the cloud, also allows you to reduce licensing costs as well as deploy or remove resources based on user-demand.
RDS Role Services
The Remote Desktop Services server role in Windows Server 2012 is comprised of multiple role services that can be deployed together for small deployments or spread across multiple servers for fault-tolerance and scalability. The six available roles services are described below (some are supplemental or not required for the deployment of session-based desktop virtualization):
Session Host: This is one of the core role services and allows a server to host session-based virtual desktops or RemoteApp applications (more on this later) – this role service was formerly known as terminal services in legacy versions of Windows Server.
Virtualization Host: This is another core role service that allows a server to host virtual machine-based virtual desktops by integrating Remote Desktop Services with the Hyper-V server role. This is the counterpart role service to the session host role service and is required when you wish to support user connections to either pooled virtual desktops or personal virtual desktops.
Licensing: This is a core role service that is required in all deployments and allows administrators to centrally manage the licenses required for users to connect to session host or virtualization host servers. This role can often be placed on a host running additional Remote Desktop Services role services due to its lightweight nature.
Connection Broker: This role service is critical to enterprise deployments because it allows administrators to build high-availability by load-balancing incoming connection requests across available session host or virtualization host servers. The connection broker role service keeps track of sessions and routes connection requests to available hosts based on host load – in the case of existing connections, the connection broker will re-connect the user to their existing session. In Windows Server 2012, this role service now supports Active/Active operation allowing you to meet scalability requirements in addition to fault-tolerance in the connection broker layer of the infrastructure.
Gateway: This is a supplemental role service that allows users to securely connect to their session-based desktops, virtual machine-based desktops or RemoteApp published applications on an internal corporate network from any device.
Web Access: Another supplemental role service that allows users to securely connect to their session-based desktops, virtual machine-based desktops or RemoteApp published applications through a web browser.
VDI Enabling RDS Features
RemoteFX: RemoteFX provides end-user experience enhancements to the Remote Desktop Protocol that allow RDP to operate as a truly viable desktop virtualization platform. A few of the RemoteFX components that provide critical capabilities when it comes to desktop virtualization are full USB redirection support for all desktop virtualization workloads, vGPU hardware acceleration (the ability to use a physical GPU in Hyper-V hosts to accelerate host-side rendering of graphics intensive content), intelligent transport enhancements that introduce UDP support to allow fuller/smoother desktop experiences over low bandwidth/high-latency links and finally multi-touch capabilities to support gestures (e.g. pinch, zoom, swipe).
User Profile Disks: The introduction of User Profile Disks greatly enhances the ability for users to personalize pooled virtual machines removing the necessity to implement more complex roaming profile or folder redirection methodologies. This technology is really only applicable to virtual machine-based deployments but is worth mentioning as it makes deployment of virtual machine-based VDI much simpler and more robust.
Fairshare Resource Management: New to Windows Server 2012, the session host role service now introduces “fair share” resource management for network I/O, storage I/O and CPU. This resource management ensures that no single user can adversely impact users on the same host by ensuring each session is allocated an equal share of the resources described above. This simple enhancement makes the user experience in session-based deployments much smoother and consistent and eases the burden on administrators when deploying additional RD Session Host servers to the session collection.
Deployment Models
Now that we’ve gone through a brief review of Remote Desktop Services and its various role services, let’s focus on examining the session-based deployment model. First and foremost, let’s address why the session-based deployment model is so attractive when compared to the virtual machine-based deployment model.
The “traditional” approach to VDI is to utilize virtual machine-based desktop virtualization – when using Microsoft Remote Desktop Services this generally means one or more RD Session Broker instances and a number of dedicated Hyper-V hosts running the RD Virtualization Host RDS role service. In this model, users connect to a virtual machine either from a pool of identically configured virtual machines (called pooled virtual desktops) or a personal virtual desktop that is dedicated to a specific user. The drawback is that this model requires standing up dedicated virtual machines per user which requires significantly greater resources than a session-based deployment. In addition to the increased resource demands, administrators must ensure there are adequate pooled virtual desktops or personal virtual desktops in place to meet user load requirements. You should consider virtual machine-based deployment in those cases where users require significant control over their desktop environment (e.g. administrative rights, installing applications, etc.).
In the session-based model, we continue to rely on session broker instances to load-balance incoming connections but replace the dedicated Hyper-V hosts running the RD Virtualization Host role service with servers running the RD Session Host role service. In this model, users connect to a centralized installation of a desktop running on one or more session host servers (when session hosts are configured in a farm, it is referred to as a session collection) only receiving the user interface from the session host server and sending input commands to the server. When the RD Session Host role service is installed, fairshare resource management ensures storage I/O, network I/O and CPU are evenly distributed to all users; in addition, Windows automatically configures processor scheduling to prioritize performance of user applications over background processes. This is a good reason to avoid collocating this role service on a server with “traditional” background type services (e.g. IIS, Exchange, etc.). In addition to accessing full virtual desktop environments, applications can be published as RemoteApp programs from the session host servers allowing users to connect to specific applications over Remote Desktop – these applications are rendered in a local window on the client and from the end-user perspective, behave almost identically to local applications.
Sample Session-Based Deployment Architectures
For testing or starting a small session-based VDI deployment, you can install the RD Session Host, RD Connection Broker and RD Licensing role services on a single server through the Quick Start deployment option. For an enterprise deployment, we would need to design the infrastructure to deal with availability and scaling concerns. As with any environment, the complexity increases with the availability requirements – a session-based VDI deployment that requires five¬¬¬ nines availability and needs to support a large concurrent user base will be significantly larger and more complex than a solution for a small business with reduced availability requirements. Let’s examine three sample deployment architectures designed to meet the requirements of organizations of varying size and complexity.
Small Business Deployments
For the small business environment that doesn’t have strict availability requirements and only a small number of thin-client devices and remote users, we can deploy a simple infrastructure. For these types of environments, you can deploy the following RDS role services on a single host by using the Quick Start deployment option: RD Session Broker, RD Session Host and RD Licensing.
While a detailed discussion about sizing requirements is outside the scope of this article, this type of environment is generally suitable for 45-50 simultaneous user connections and using standard line of business applications (e.g. Office, Web Browsers, Thick Client Applications) that are not graphics intensive.
Small Business Deployments with Increased Availability
For the small business environment that has increased availability requirements, the deployment becomes only slightly more complex. Windows Server 2012 introduces the Active/Active Broker feature that allows you to provide fault-tolerance and scalability to the connection broker role service without the requirement to implement complex failover-clustering. Instead, you simply combine both connection broker servers under a single DNS entry.
In this architecture, we deploy both the session host and connection broker role services on two identically configured servers, configure Active/Active brokering and register both session hosts in a new session collection. A SQL Server instance is required to allow the connection brokers to synchronize and track sessions. User connections will be evenly distributed across the session host servers – if a single RDS server fails, users will still be able to access their virtual desktop environment.
If this type of environment needs to support the loss of a single RDS server without degradation in the end-user experience, then the previous recommendation of 45-50 simultaneous users should be followed. If some amount of degradation in the end-user experience is acceptable or the business accepts that a reduced number of users will be able to connect in the event of a server loss, this number could be increased to 75-100 simultaneous users.
Enterprise Scale Deployments
For enterprise deployments that have strict availability requirements, need to support a large number of thin-clients and remote users and also require the ability to continue scaling out the environment as the number of users increases, the architecture becomes much larger and more complex.
In this architecture, the connection broker role service is deployed on two dedicated servers in Active/Active Broker mode using round-robin load balancing. For connection broker synchronization and user session tracking, SQL Server is deployed as a clustered failover instance on two dedicated servers to provide fault-tolerance. Microsoft testing shows the connection broker role service operating in Active/Active Broker mode on two servers can maintain reasonable endpoint connection response times (< 2.5 seconds) for up to 2,000 simultaneous connections before end-user observable degradation is encountered.
Fault tolerance and scalability is further accomplished by deploying the session host role service on three dedicated servers registered in a session collection with the Active/Active connection broker farm. User connections will be evenly distributed across the session host servers – if a single RDS server fails, users will still be able to access their virtual desktop environment. To meet scalability requirements, the enterprise can simply add additional session host servers to the session collection to support the increasing number of users.
This architecture also provides fault tolerance in Active Directory Domain Services with two domain controllers deployed on dedicated servers.
If this environment needs to support the loss of a single RDS server without degradation in the end-user experience, then the session host servers should not exceed 66% of their total capacity or about 34 simultaneous connections per session host server. If some amount of degradation in the end-user experience is acceptable or the business accepts that a reduced number of users will be able to connect in the event of a server loss, this number could be increased to 125-150 simultaneous users. As stated before, this environment can continue to scale out to meet user load requirements by simply adding additional session host servers to the session collection and if exceeding 2,000 simultaneous connections, adding additional connection broker servers.
Conclusion
As was pointed out in some of the example architectures, there are a number of factors that can affect the deployment model and architecture you choose and the sizing requirements of the individual role services. You should carefully consider things like application memory requirements, graphic intensive workloads, availability requirements and budget constraints when deciding if desktop virtualization is right for your business.
Every environment is different and not every business will be able to realize cost savings but every business can certainly gain flexibility and enhanced user experience by implementing desktop virtualization. Hopefully this article will help you get you started down the path to providing true flexibility and simplicity to your end-user computing environment.
