SPRA v2 Multi-Tenant
Desktop Hosting Architecture
Guide
Version 1.0 Final
9-Feb-16
Prepared by
<Partner>
ii
Table of Contents
1
Introduction ............................................................................................................................................ 5
2
Desktop Hosting Service Overview ................................................................................................ 6
2.1
Remote Desktop Services Architecture Overview ............................................................................................... 6
2.2
Provider Management and Perimeter Environments ........................................................................................ 8
2.2.1
Active Directory Domain Services ........................................................................................ 8
2.2.2
System Center 2012 R2 Virtual Machine Manager ........................................................... 9
2.2.3
SQL Server .............................................................................................................................. 10
2.2.4
Tenant Management Portal ................................................................................................ 10
2.2.5
Hyper-V Networking Virtualization Gateway .................................................................. 11
2.2.6
Scale-Out File Server ............................................................................................................ 12
2.2.7
Networking ............................................................................................................................. 13
2.3
3
Tenant Environment ..................................................................................................................................................... 14
2.3.1
Active Directory Domain Services ..................................................................................... 14
2.3.2
Remote Desktop Web Access ............................................................................................. 15
2.3.3
Remote Desktop Gateway ................................................................................................... 17
2.3.4
Remote Desktop Connection Broker ................................................................................ 18
2.3.5
Remote Desktop License ..................................................................................................... 18
2.3.6
Remote Desktop Session Host ........................................................................................... 19
2.3.7
User Profile Disks .................................................................................................................. 20
2.3.8
File Server ............................................................................................................................... 20
Desktop Hosting Infrastructure Logical Architecture ............................................................ 21
3.1
Basic Desktop Hosting Architecture ...................................................................................................................... 21
3.2
High Availability Desktop Hosting Architecture ............................................................................................... 23
3.3
Highest Availability Desktop Hosting Architecture ......................................................................................... 24
3.4
Other Tenant Services ................................................................................................................................................. 25
3.4.1
4
Microsoft Application Virtualization ................................................................................ 25
Tenant On-Premises Components ............................................................................................... 26
4.1
Infrastructure Components on Tenant’s Premises ........................................................................................... 26
4.2
On-Premises Active Directory Domain Services ............................................................................................... 27
3
4.3
Supported Remote Desktop Client Devices ....................................................................................................... 27
5
Desktop Hosting Infrastructure Security Considerations ..................................................... 28
6
Desktop Hosting Infrastructure Licensing Considerations .................................................. 28
7
Desktop Hosting Infrastructure Scalability Guidelines .......................................................... 31
7.1
Design Considerations for Hosting Very Small Tenants ................................................................................ 32
4
1 Introduction
This document defines a set of architectural blocks for using Remote Desktop Services (RDS) to
create multitenant, hosted Windows® Remote Desktop session and application services,
referred to in this document as “desktop hosting.” The primary goal is to help customers create
highly secure, scalable and reliable desktop hosting solutions for small- and medium-sized
organizations with 5 to 5,000 users. See section 7.1 for specific guidelines to host very small
tenants with 5-25 users with minimal cost and complexity.
The primary audience for this reference architecture are hosted service providers who want to
utilize Microsoft’s Windows Server and System Center software stack to deliver desktop hosting
services and Subscriber Access Licenses (SALs) to multiple tenants through the Microsoft Service
Provider Licensing Agreement (SPLA) program. A second audience for this reference
architecture are end-customers who want to create and manage desktop hosting solutions in an
on-premises private cloud environment for their own employees using RDS Client Access
Licenses (CALs) available through Volume Licensing, OEM, and Retail programs. Extended
Software Assurance (SA) rights may be applied if the end-customer organization is hosting in a
3rd-party multitenant environment (i.e., at a hoster) and wants to use their RDS CALs.
To deliver a desktop hosting solutions, hosting partners and end customers utilize Windows
Server® and the Windows Desktop Experience feature to deliver Windows users an application
experience that is familiar to business users and consumers. Although Windows 8.1, Windows 7
and earlier Windows client versions are not licensed for hosting environments with shared
hardware, the Desktop Experience feature in Windows Server 2012 R2 provides a similar user
experience and application support.
The scope of this document is limited to:

Architectural design guidance for a desktop hosting service. Detailed information, such
as deployment procedures, performance, and capacity planning, are explained in
separate documents.

Session-based desktops, RemoteApp applications and server-based personal desktops
that use the Windows Server 2012 R2 Remote Desktop Session Host (RD Session Host)
server role. Windows client-based virtual desktop infrastructures are not covered
because there is not a Service Provider License Agreement (SPLA) for Windows client
operating systems. Windows Server-based virtual desktop infrastructures are allowed
under the SPLA, and Windows client-based virtual desktop infrastructures are allowed on
5
dedicated hardware with end-customer licenses in certain scenarios. However, clientbased virtual desktop infrastructures are out-of-scope for this document.

Microsoft® products and features, primarily Windows Server 2012 R2 and Microsoft
System Center 2012 R2.

Desktop hosting services for tenants ranging in size from 5 to 5,000 users.
For larger tenants, this architecture may need to be modified to provide adequate
performance. The Server Manager RDS graphical user interface (GUI) is not
recommended for deployments over 500 users. PowerShell is recommended for
managing RDS deployments between 500 and 5000 users.

The minimum set of components and services required for a desktop hosting service.
There are many optional components and services that can be added to enhance a
desktop hosting service, but these are out-of-scope for this document.
Note: This SPRA v2 Multi-Tenant Desktop Hosting Architecture Guide builds upon the
Infrastructure as a Service (IaaS) design guidelines provided in the following documents:
o
IaaS Product Line Architecture Fabric Architecture Guide
o
IaaS Product Line Architecture Fabric Management Architecture Guide
o
SPRA v2 Multi-Tenant Foundation Architecture Guide
The Foundation document is publishing simultaneously with the Desktop Hosting
document, therefore a URL is not available. The SPRA MT Foundation document
is available on both the internal Services Portfolio, and external Microsoft Partner
Network sites.
We strongly recommend reading the above documents to review the IaaS recommended practices
for Hyper-V host clustering, SOFS (Scale-Out File Server), Virtual network isolation with NGVRE
(Network Virtualization using Generic Routing Encapsulation), Hyper-V guest clustering, etc.
prior to reading this document.
2 Desktop Hosting Service Overview
2.1 Remote Desktop Services Architecture Overview
RDS in Windows Server 2012 R2 is a collection of role services that support various remote
desktop scenarios.
RDS supports remoting from both sessions on a RD Session Host server and client guest virtual
machines (VMs) on a Remote Desktop Virtualization Host server. Connection information for
the Remote Desktop and RemoteApp sessions and VMs hosted on these servers may be stored
6
in an RDP file or displayed using the publishing features of Remote Desktop Web Access (RD
Web Access). As illustrated in the following figure, the Remote Desktop Connection Broker (RD
Connection Broker) routes incoming connections to the appropriate RD Session Host depending
on the contents of the RDP file and its load balancing configuration. The Remote Desktop
Gateway (RD Gateway) provides secure remote access to the RDS deployment and the Remote
Desktop Licensing (RD Licensing) server handles licensing for RDS infrastructure.
The following figure provides an overview of the architecture of RDS in Windows Server 2012
R2.
Figure 1 – Windows RDS Architecture in Windows Server 2012/R2
RDS session virtualization, formerly known as Terminal Services, is an effective and mature
centralized desktop infrastructure that many organizations deploy to increase user density on
the host and therefore reduce costs. Windows Server 2012 R2 makes it easier to deploy this
architecture by offering a session virtualization deployment scenario.
A session virtualization deployment consists of RD Session Host servers and infrastructure
servers, such as RD Licensing, RD Connection Broker, RD Gateway, and RD Web Access.
The desktop hosting solution described in this document utilizes Windows Server 2012 R2 RDS
capability to deploy session-based desktops or RemoteApp programs.

Session-based desktop Virtualization – Using the RD Session Host server role,
Windows Server 2012 R2 creates separate desktop sessions for multiple users on a single
server.
7

Session-based RemoteApp virtualization) – Using the RD Session Host server role,
Windows Server 2012 R2 creates separate RemoteApp sessions for multiple users on a
single server. If a user starts more than one RemoteApp from the same server (the
default behavior), all RemoteApp programs will run in the same session.
Additional information:
Remote Desktop Services Overview
Windows Server 2012 R2: What’s New in Remote Desktop Services
Using PowerShell to install, configure and maintain RDS in Windows Server 2012 R2
2.2 Provider Management and Perimeter Environments
The provider’s desktop hosting service is implemented as a set of isolated tenant environments
hosted on the service provider’s IaaS fabric. The SPRA IaaS fabric includes all of the
foundational infrastructure components required to support a multi-tenant IaaS environment.
The following subsections describe the components that comprise the management and
perimeter networking components of the service provider’s IaaS fabric. For additional details
regarding the provider IaaS Fabric architecture, see the SPRA v2 Multi-Tenant Foundation
Architecture Guide.
2.2.1 Active Directory Domain Services
The provider’s management infrastructure includes an Active Directory Domain Services (AD DS)
server for the provider’s fabric management forest and domain, also referred to as the fabric
management AD. All the hosts in the provider’s fabric and the virtual machines in the provider’s
management environment are joined to the provider’s fabric management domain. All the
provider’s administrative users have user accounts in the provider’s fabric management domain.
The provider’s forest does not require any trust relationship with the tenant forests.
For service providers who offer fully managed desktop hosting services, the provider will also
have an AD DS server for the provider’s tenant management forest and domain, also referred to
as the tenant management AD.
Each managed tenant will have a tenant domain and forest with one-way trust to the tenant
management domain. This allows designated tenant administrators to manage the tenant’s
environment.
Hyper-V host clusters can be used to provide a base level of high availability for the
management and perimeter workloads. To provide a more continuously available service, two
AD DS server guest virtual machines can be configured on two separate clusters. The first
8
AD DS domain controller that is deployed creates the provider’s domain and forest. By default,
it holds the DNS role, and it is the operations master for all five operations master roles.
A second domain controller is promoted as a replica in the provider’s domain. The second
domain controller’s preferred DNS server must be configured to point to the IP address of the
first domain controller before running the promotion user interface.
Additional information:
Active Directory Domain Services Overview
Windows Server 2012 R2: What’s new in Active Directory Domain Services?
Active Directory Domain Services (AD DS) Virtualization
Planning to Virtualize Active Directory Domain Controllers
2.2.2 System Center 2012 R2 Virtual Machine Manager
System Center 2012 R2 Virtual Machine Manager (VMM) is installed on a virtual machine in the
provider’s management network, and it is joined into the provider’s management domain. The
provider’s administrators use VMM to manage fabric resources and create and configure the
virtual machines and virtual networks in the tenant environments. VMM utilizes a database in
the SQL Server® failover cluster instance (FCI) that is also on the provider’s management
network.
The VMM console is installed to allow administrators to manually create virtual machines and
virtual networks.
A Tenant Management Portal can be automated by using Windows PowerShell® scripts,
Windows Azure Pack (WAP) or the System Center 2012 R2 Service Provider Foundation (SPF).
See section Error! Reference source not found. for more details regarding implementing a
enant Management Portal using WAP or SPF.
Before installing VMM, the following prerequisite components must be installed:

SQL Server 2012 command-line utilities and the native client. This enables VMM to
communicate with SQL Server, which is running in a separate virtual machine.

Windows Assessment and Deployment Kit (ADK) for Windows 8.
Hyper-V host clusters are used to provide high availability for the management and perimeter
workloads, including VMM.
Additional information:
System Center 2012 R2 – Virtual Machine Manager
9
Overview of System Center 2012 – Virtual Machine Manager
System Requirements for System Center 2012 R2
Preparing your environment for System Center 2012 R2 Virtual Machine Manager
Installing a Highly Available VMM Management Server
Windows ADK for Windows 8
Download - SQL Server 2012 Command Line Utilities
Download- SQL Server 2012 Native client
2.2.3 SQL Server
Microsoft SQL Server is used by VMM to save information about the data center deployment.
Hyper-V host clusters are used to provide high availability for the management and perimeter
workloads, including SQL Server. To provide a more continuously available SQL Server service, a
native high availability solution can be implemented in SQL Server (e.g., SQL AlwaysOn
Availability Groups).
Additional information:
Configuring a Remote Instance of SQL Server for VMM
Using a Remote Empty Database for VMM Installation
High Availability Solutions (SQL Server)
AlwaysOn Failover Cluster Instances (SQL Server)
Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager)
2.2.4 Tenant Management Portal
The provider may want to create a tenant provisioning portal that resellers and tenant
administrators can use directly to self-provision. A tenant provisioning portal for desktop
hosting is not provided by Microsoft at this time, but one can be obtained from third party
developers or developed by using the Windows Azure Pack or Service Provider Foundation (SPF)
for System Center.
Available to Microsoft customers at no additional cost, WAP comes as a collection of Windows
Azure technologies that install in enterprise and service provider datacenters, integrating with
their existing System Center and Windows Server environments.
10
WAP can be combined with the Basic, High Availability or Highest Availability architecture
design patterns to provide robust management of tenant desktop hosting environments.
The Service Provider Foundation is provided with System Center 2012 - Orchestrator, a
component of System Center 2012 R2. Service Provider Foundation exposes an extensible
OData web service that interacts with Virtual Machine Manager (VMM). This enables service
providers to design and implement multi-tenant self-service portals that integrate IaaS
capabilities available on System Center 2012 R2.
Additional Information:
Windows Azure Pack for Windows Server White Paper
Windows Azure Pack Datasheet
Windows Azure Pack Architecture
Windows Azure Pack for Windows Server 2012 R2 Guide
Service Provider Foundation
Preparing your environment for System Center 2012 R2 Service Provider Foundation
2.2.5 Hyper-V Networking Virtualization Gateway
The tenant’s components communicate with each other in a virtualized network environment
that is based on Hyper-V network virtualization. Packets are isolated on the tenant’s virtual
subnet using encapsulation. However, the tenant’s sessions running on the RD Session Host
servers need to communicate with the non-network virtualized environment to access the
Internet. This is done by using Hyper-V Network Virtualization Gateway, which de-encapsulates
the packets and routes them to the Internet.
Hyper-V Network Virtualization Gateway is multi-homed. One network adapter connects to the
provider’s Network Virtualization (NV) network and carries encapsulated traffic from each
tenant’s virtual subnet, and the other network adapter connects to the provider’s perimeter
network.
Hyper-V Network Virtualization Gateway can also support site-to-site virtual private networking
(VPN) connections between the tenant’s on-premises network and the tenant’s virtual subnet in
the provider’s data center. This is referred to as a hybrid cloud model in the Hyper-V Network
Virtualization Gateway Architectural Guidehttp://technet.microsoft.com/enus/library/jj642895.aspx.
11
This allows the hosted desktops to access the on-premises resources. For example, a tenant’s
desktop hosting environment can utilize line of business application servers on the tenant’s onpremises network.
For self-managed, desktop hosting scenarios, a tenant’s desktop hosting environment can utilize
an AD DS server on the tenant’s on-premises network. In this configuration, an AD DS virtual
machine is no longer needed in the hosted environment. Alternatively, an AD DS virtual machine
could be provided in the hosted environment, but promoted as a replica in the tenant’s domain.
Note that in the self-managed scenario just described, the tenant and not the service provider
maintains control of the environment. Ultimately, control is dictated by administrative access to
the AD forest. When a tenant has control, the service provider is not able to guarantee service
level agreements, nor service level targets.
Microsoft provides Hyper-V Network Virtualization Gateway in Windows Server 2012 R2.
Additional information:
Hyper-V Network Virtualization Technical Details
Windows Server 2012 Hyper-V Network Virtualization Survival Guide
Hyper-V Network Virtualization Gateway Architectural Guidehttp://technet.microsoft.com/enus/library/jj642895.aspx
NVGRE Draft RFC
2.2.6 Scale-Out File Server
Physical storage in the provider’s data center is virtualized by using the Scale-Out File Server and
other storage technologies such as storage pools, storage spaces, and virtual hard disks.
Individual disks are combined in a chassis, pooled into logical storage units, and then exposed
to the Hyper-V hosts as virtual hard disks on SMB 3.0 shares on the Scale-Out File Server.
To provide highly available Cluster Shared Volumes (CSVs) to the Hyper-V host clusters, the
Scale-Out File Server is also implemented in a failover cluster.
All the storage hosts are members of the provider’s Active Directory forest, and they are
included in the provider’s VMM fabric as storage servers.
Additional Information:
Scale-Out File Server for Application Data Overview
What’s New in Failover Clustering?
How to Configure a Clustered Storage Space in Windows Server 2012
12
2.2.7 Networking
To support desktop hosting, a minimum of five independent networks must be implemented as
follows:
1. External Network
This network carries the incoming traffic from the public Internet through the provider’s
firewalls.
2. Network Virtualization (NV) Network
This network carries the encapsulated traffic for all tenants that are hosted in the
provider’s data center. This network is not directly accessible by any of the tenants (it is
only accessible through NVGRE). This network must use a pool of static IP addresses in
the provider’s address space, and it must be defined in a VMM logical network pool.
3. Management Network
This network carries the provider’s management traffic to manage fabric resources, such
as storage and Hyper-V hosts, using the provider’s management AD DS and VMM.
4. Storage Network
This network carries all storage traffic between the Scale-Out File Server and the Hyper-V
hosts.
5. Perimeter Network
This network carries traffic to and from the public Internet.
2.2.7.1 Tenant Management Virtual Network
Service providers who offer fully managed desktop hosting services will create a network
connection from the tenant’s virtual machines, including the tenant’s AD DS server, to the
provider’s tenant management AD DS server. This network connection supports a one-way trust
from the tenant’s domain and forest to the provider’s tenant management domain. To
accomplish this, the provider can create a tenant management virtual network that connects to
the provider’s tenant management AD DS server VM and then to the virtual machines in each
managed tenant environment. Port access control lists (ACLs) must be configured on the
Hyper-V hosts running the tenant virtual machines to restrict access to allow connections only to
and from the provider’s tenant management AD DS server. This model can be extended to
include other tenant management services offered by the provider by extending the range of IP
addresses and ports allowed in the port CAL configuration.
13
2.2.7.2 Network Load-Balancing
A load-balancing device located between the provider’s Perimeter and External networks
enables load-balancing remote desktop connections to multiple Remote Desktop Web Access
(RD Web Access) and Remote Desktop Gateway (RD Gateway) servers located within the tenant
environments.
2.3 Tenant Environment
The provider’s desktop hosting service is implemented as a set of isolated tenant environments
hosted on the service providers IaaS fabric. Each tenant’s environment consists of a set of virtual
machines, all communicating over an isolated virtual network. Each virtual machine contains
one or more of the components that make up the tenant’s hosted desktop environment. The
following subsections describe the components that make up each tenant’s hosted desktop
environment.
2.3.1 Active Directory Domain Services
The tenant’s network includes an Active Directory® Domain Services (AD DS) server for the
tenant’s forest and domain. All the virtual machines in the tenant’s virtual subnet are joined to
the tenant’s domain. All the tenant’s users have user accounts in the tenant’s domain.
The VM used to deploy AD DS should have a virtual SCSI data disk attached and configured for
the AD DS database and SYSVOL.
If the provider is deploying AD DS solely in the tenant’s hosted environment (i.e., the tenant
does not have a separate on-premises AD DS as is the case for most small tenants), then the
DNS role will be deployed with AD DS and will serve as the primary DNS server for the other
virtual machines in the tenant environment. To resolve names on the public Internet, the
tenant’s DNS server forwards requests to a public DNS server.
To provide a continuously available service, two AD DS server virtual machines can be deployed
and configured in the tenant environment. The first AD DS domain controller deployed creates
the tenant’s domain and the forest. By default, it holds the DNS role, and it is the operations
master for all five operations master roles. A second domain controller is promoted as a replica
in the tenant’s domain. The second domain controller’s preferred DNS server must be
configured to point to the IP address of the first domain controller before running the
promotion user interface.
There are two tenant management models considered for this architecture, provider-managed
and self-managed. For self-managed tenants, the tenant’s forest does not require any trust
relationship with the provider’s tenant management forest. A domain administrator account will
14
be created in the tenant’s domain to allow the tenant’s technical personnel to perform
administrative tasks in their environment (such as monitoring system status and applying
software updates) and to for troubleshooting and further configuration.
For provider-managed tenants, a one way trust is created from the tenant’s forest to the
provider’s tenant management forest. A security group is created in the tenant management
domain that will be used to manage this tenant. This group is then added to the local
administrators group on all servers in the tenant’s RDS deployment so that the provider’s
technical personnel can perform administrative tasks in the tenant’s environment.
For small tenants, the cost can be reduced by combining AD DS, the file server, RD Connection
Broker and RD Licensing roles on a single virtual machine on the tenant’s virtual network.
Note: See the SPRA v2 Multi-Tenant Foundation Architecture Guide for details regarding the
recommended networking design, security design and identity framework design for the SPRA
multi-tenant hosting solution.
2.3.2 Remote Desktop Web Access
The RD Web Access component allows the tenant’s employees to have a single website where
they can authenticate and then access Windows desktops and applications that are hosted in
the service provider’s desktop hosting service. By using RD Web Access, Windows desktops and
applications can be published to a variety of Windows and non-Windows client devices, and
they can be selectively published to specific users or groups.
The RD Web Access component requires installation of Internet Information Services (IIS).
A Hypertext Transfer Protocol Secure (HTTPS) connection is used to provide an encrypted
communications channel between the clients and the RD Web server. The RD Web Access
virtual machine must have a public IP address that is accessible through TCP public port of 443
to allow the tenant’s users to connect from the Internet using the HTTPS communications
transport protocol.
Matching digital certificates must be installed on the server and clients. For development and
testing purposes, this can be a self-generated and self-signed certificate. For a released service,
the digital certificate must be obtained from a trusted certification authority. The name of the
certificate must match the Fully Qualified Domain Name (FQDN) that is used to access RD Web
Access externally through the Internet.
The RD Web Access VM must be dual-homed to connect from the provider’s external network
to the tenant’s isolated virtual subnet. Consequently, it has two Hyper-V network adapters.
Each of these adaptors is connected through a Hyper-V virtual network switch, and each switch
15
connects to the one of the host’s physical adaptors. One of the physical adaptors is connected
to the provider’s external network and the other is connected to the provider’s NV network.
The Hyper-V network adapter that is connected to the provider’s external network is configured
by using VMM to connect directly to the external network so that packets on this network use
the provider’s address space. The Hyper-V network adapter that is connected to the provider’s
NV network is configured with Network Virtualization using Generic Routing Encapsulation
(NVGRE) so that the packets are isolated to the tenant’s virtual subnet and address space. This
enables users to connect from the public Internet to their RD Web Access server and access
resources in the tenant’s isolated virtual subnet. This is shown in the following diagram.
Dual-homed Guest VM
Hyper-V Network
Adapter
Hyper-V Network
Adapter
Hyper-V Host
Hyper-V Virtual
Switch
Hyper-V Virtual
Switch
Physical Network
Adapter
Physical Network
Adapter
Figure 2 - Dual-homed RD Web Access VM
For tenants with small numbers of users, the RD Web Access and RD Gateway workloads may be
combined in a single virtual machine to reduce cost. To provide a highly available service and to
scale-out to larger numbers of users, additional RD Web Access virtual machines may be added
to an RD Web Access farm.
16
Additional information:
Deploying and Configuring RD Web Access
Publishing RemoteApps in Windows Server 2012 R2
Distribution of Remote Apps and Desktops in Windows Server 2012 R2
2.3.3 Remote Desktop Gateway
The RD Gateway component enables tenant employees who are using client devices on the
public Internet to securely access Windows desktops and applications that are hosted in the
service provider’s desktop hosting service.
The RD Gateway component uses Secure Sockets Layer (SSL) to provide an encrypted
communications channel between the clients and the server. The RD Gateway virtual machine
must have a public IP address that is accessible through TCP public port of 443 to allow the
tenant’s users to connect from the Internet using the HTTPS communications transport protocol
and through UDP port of 3391 to allow users to connect using the UDP protocol. Matching
digital certificates must be installed on the server and client. For development and testing
purposes, this can be a self-generated and self-signed certificate. For a released service, the
digital certificate must be obtained from a trusted certification authority. The name of the
certificate must match the FQDN that is used to access RD Gateway externally through the
Internet.
For tenants with small number of users, the RD Web Access and RD Gateway can be combined
on a single virtual machine to reduce cost. To provide a highly available service and to scale-out
to larger numbers of users, additional RD Gateway virtual machines may be added to an RD
Gateway farm. When deploying multiple RD Gateway servers in a farm configuration it is
necessary to include a load-balancer that supports Source IP address affinity persistence
between the Remote Desktop Client devices and the RD Gateway servers. Source IP address
affinity persistence directs session requests to the same server based solely on the source IP
address of a packet.
External network connections must be brought in to the RDGW VM from by dual homing the
RDGW VM as is also required for the RD Web Access VM.
Additional information:
Deploying and Configuring RD Gateway
What’s New in Windows Server 2012 R2 RD Gateway
RD Gateway Capacity Planning in Windows Server 2012 R2
17
2.3.4 Remote Desktop Connection Broker
RD Connection Broker manages incoming remote desktop connections to the servers in RD
Session Host server farms, known as collections. RD Connection Broker handles connections to
collections of full desktops and to collections of RemoteApps. For new connections, RD
Connection Broker can balance the load across the servers in the collection. For a session that
was disconnected, RD Connection Broker reconnects the user to the correct RD Session Host
server and the disconnected session, which already exists in the RD Session Host farm.
To support single sign-on and application publishing, matching digital certificates must be
installed on the RD Connection broker server and the client. For development and testing
purposes, this can be a self-generated and self-signed certificate. For a released service, the
digital certificate must be obtained from a trusted certification authority. The name of the
certificate must be the internal Fully Qualified Domain Name (FQDN) of the RD Connection
Broker virtual machine.
The Windows Server 2012 R2 RD Connection Broker can be installed on the same virtual
machine as AD DS to reduce cost. To provide a highly available service and to scale-out to
larger numbers of users, additional RD Connection Broker virtual machines can be added to
create an RD Connection Broker (Active-Active) cluster. To create an RD Connection Broker
cluster, a Microsoft SQL Server AlwaysOn Availability Group must also be deployed in virtual
machines.
Additional information:
Overview of Remote Desktop Connection Broker (RD Connection Broker)
RD Connection Broker Performance and Scalability
RD Connection Broker High Availability in Windows Server 2012
Overview of AlwaysOn Availability Groups (SQL Server)
Step-By-Step: Creating a SQL Server 2012 AlwaysOn Availability Group
2.3.5 Remote Desktop License
Each tenant’s environment includes an activated RD License server to allow users to connect to
the RD Session Host servers that host the tenant’s desktops and applications. For hosted
environments, the RD License server is configured in “per user” mode.
The service provider must acquire the proper number of RDS Subscriber Access Licenses (SALs)
based on the number of unique (not concurrent) users authorized to log on to the service each
month. Service providers who offer hosted desktops must purchase the SALs through the
18
Microsoft Service Provider Licensing Agreement (SPLA) program. End-customers who purchase
a hosted desktop solution from a service provider must purchase the complete hosted solution
from the service provider.
For small tenants, the cost can be reduced by combining the AD DS, the file server, and RD
Licensing components on a virtual machine in the tenant’s environment. To provide a higher
availability service, two RD License server virtual machines can be deployed in the tenant
environment. All the RD servers in the tenant’s environment are associated with both RD
License servers to ensure that users will be able to connect to new sessions even if one of the RD
License servers is unavailable.
Additional information:
Overview of Remote Desktop Licensing
Deploying Remote Desktop Licensing Step-by-Step Guide
Managing RDS Licensing Using PowerShell on Windows Server 2012 R2
Generate Per User CAL Report
Microsoft Volume Licensing: Licensing Options for Service Providers
2.3.6 Remote Desktop Session Host
The RD Session Host component provides a tenant’s users with session-based desktops and
RemoteApp programs. The desktops and applications can be accessed over the Internet from
any device running a capable remote desktop connection client. See section 4.3 for more
information regarding supported client devices.
The remote desktops and applications can be organized into collections of one or more RD
Session Host servers. The collections can be customized for specific groups of users within each
tenant. For example, a collection could be created so that a tenant’s accounting group can
access accounting applications, but the engineering group cannot access them.
The applications can be installed directly on the RD Session Host servers. For larger
deployments, streaming applications to the RD Session Host from an App-V server is
recommended to reduce the maintenance costs.
To provide higher availability of the collections and to increase scale to support more users or
applications that use more computer resources, each collection can be expanded by adding RD
Session Host server virtual machines to a collection farm with each RD Session Host virtual
machine within a collection assigned to same tenant environment.
19
In most cases, the RD Session Host servers are shared by multiple users simultaneously. This is
the most efficient way to utilize the IaaS fabric resources (e.g., compute, storage and network)
for a desktop hosting solution. In this configuration, users must sign in to collections by using
non-administrative accounts. In certain cases, some users want full administrative access to their
own personal desktop. This can be achieved by creating a collection with 1 RD Session Host
virtual machine for each user who wants administrative access.
When the user signs in to a desktop collection, by default, the user sees a server desktop.
Administrators can install the Desktop Experience feature and customize the default profile to
provide a more client-like experience for the end-user. We strongly recommend utilizing the
Desktop Experience feature as part of a desktop hosting solution. Additional customizations can
be made by creating a virtual hard disk that contains the Windows Server operating system to
be used as a template for creating RD Session Host virtual machines.
Additional information:
Desktop Experience Overview
Desktop Experience in Windows Server 2012 R2
Install Desktop Experience on Windows Server 2012
2.3.7 User Profile Disks
User Profile Disks allow users to save personal settings and files when they are signed in to a
session on an RD Session Host server in a collection, and then have access to the same settings
and files when signing in to a different RD Session Host server in the collection. When the user
first signs in, a user profile disk is created on the tenant’s file server, and that disk is mounted to
the RD Session Host server to which the user is connected. For each subsequent sign-in, the
user profile disk is mounted to the appropriate RD Session host server; and with each sign-out, it
is un-mounted. The contents of the profile disk can only be accessed by that user.
Note: Microsoft does not recommend combining User Profile Disks with Roaming User Profiles.
Additional information:
Easier User Data Management with User Profile Disks in Windows Server 2012 R2
2.3.8 File Server
The tenant file server provides shared folders by using the Server Message Block (SMB) 3.0
protocol. The shared folders are used to create and store user profile disk files (.vhdx), to
backup data and to allow users a place to share data with other users in the tenant’s Cloud
Service.
20
The VM used to deploy the file server should have a SCSI virtual data disk attached and
configured with shared folders.
For small tenants, the cost can be reduced by combining the file server, AD DS, and RD
Licensing components on a virtual machine in the tenant’s environment. To provide a higher
availability service, two file server virtual machines can be deployed in the tenant environment
and configured as a guest cluster using a shared virtual SCSI disk.
Additional information
Overview of File and Storage Services in Windows Server 2012 R2
Deploy a Guest Cluster Using a Shared Virtual Hard Disk
3 Desktop Hosting Infrastructure Logical Architecture
This section describes design patterns for three desktop hosting architectures that provide
increasingly higher levels of availability; Basic, High Availability and Highest Availability.
The SPRA IaaS Fabric includes all of the foundational infrastructure components required to
support a multi-tenant IaaS environment.
3.1 Basic Desktop Hosting Architecture
This section describes the basic desktop hosting architecture (Basic Architecture) design pattern
which is intended to provide hosted desktop sessions and RemoteApps with the least cost and
complexity possible. The following diagram provides an overview of the basic desktop hosting
logical architecture.
21
Public Internet
Provider Services
Management
AD
VMM
Perimeter
SQL
Firewall
WAP
HNV
Gateway
LB
Tenant1 RDS Deployment
...
Desktop Hosting Service
VM
Other Tenant
Services
AD
File
Server
RDGW
RDLic
RDCB
Providr Fabric
Storage
Network
RDSH
RDSH
VM
VM
Session Desktop RemoteApp
Collection
Collection
VM
Compute
RDWeb
Hyper-V hosts
Scale-Out File Servers, JBOD arrays, tiered HDDs/SSDs, ...
Switches, multiple redundant networks, teaming, ...
Figure 3 – Basic Desktop Hosting Logical Architecture
The basic desktop hosting architecture requires the lowest cost and complexity to implement,
but provides the lowest availability.
All the tenant components of the basic architecture can be hosted on a non-clustered Hyper-V
hosts. This architecture employs a single instance of each RDS server role (i.e., RD Licensing, RD
Connection Broker, RD Web Access, RD Gateway and RD Session Host). The RD Gateway and
RD Web Access roles are combined in one Windows Server 2012 R2 server VM. For smaller
tenants, the Active Directory Domain Services, File Server, RD Licensing and RD Connection
Broker server roles are combined in a second Windows Server 2012 R2 server VM. For larger
tenants, the role services should be separated into individual VMs.
One Windows Server 2012 R2 VM with the RD Session Host server role enabled is required to
host Remote Desktop sessions. A second (optional) Windows Server 2012 R2 VM with the RD
Session Host server role enabled is required to host RemoteApp, if needed.
Additional Information:
See section 3.4.1 for more information regarding the App-V technology.
22
For architecture details regarding the provider fabric and provider services, see the SPRA v2
Multi-Tennant Foundation Architecture Guide document.
3.2 High Availability Desktop Hosting Architecture
This section describes the high availability desktop hosting architecture (HA Architecture) design
pattern which is intended to provide hosted desktop sessions and RemoteApps with greater
availability than the Basic Architecture design. The following diagram provides an overview of
the high availability desktop hosting logical architecture (HA architecture).
Public Internet
Provider Services
Management
AD
VMM
Perimeter
SQL
Firewall
WAP
LB
HNV
Gateway
Tenant1 RDS Deployment
Desktop Hosting Service
VM
Other Tenant
Services
AD
VM
Providr Fabric
Compute
Storage
Network
File
Server
...
RDGW
RDLic
RDCB
RDSH
RDSH
VM
RDWeb
RDSH
RDSH
VM
Session Desktop RemoteApp
Collection
Collection
Hyper-V hosts, host clusters, ...
Scale-Out File Servers, JBOD arrays, tiered HDDs/SSDs, ...
Switches, multiple redundant networks, teaming, ...
Figure 4 – High Availability Desktop Hosting Logical Architecture
The HA Architecture requires additional cost and complexity to implement vs. the basic
architecture model; however, it provides increased availability.
The tenant components of the HA Architecture are hosted on a multi-node Hyper-V host cluster.
This HA Architecture employs a single instance of each RDS server role (i.e., RD Licensing, RD
Connection Broker, RD Web Access, RD Gateway and RD Session Host). The RD Gateway and
RD Web Access roles are combined in one Windows Server 2012 R2 server VM. For smaller
23
tenants, the Active Directory Domain Services, File Server, RD Licensing and RD Connection
Broker server roles are combined in a second Windows Server 2012 R2 VM. For larger tenants,
the role services should be separated into individual VMs.
At least one Windows Server 2012 R2 VM with the RD Session Host server enabled is required to
host Remote Desktop sessions. At least one Windows Server 2012 R2 VM with the RD Session
Host server enabled is required to host RemoteApps.
3.3 Highest Availability Desktop Hosting Architecture
This section describes the highest availability desktop hosting architecture (Highest Availability
Architecture) design pattern which is intended to provide hosted desktop sessions and
RemoteApps with greater availability than the High Architecture design. The following diagram
provides an overview of the Highest Availability architecture
Public Internet
Provider Services
Perimeter
Management
AD
VMM
SQL
Firewall
WAP
HNV
Gateway
LB
Tenant1 RDS Deployment
Desktop Hosting Service
...
Other Tenant
Services
AD
VM
SQL
SQL
File
Server
VM
RDGW
VM
RDLic
RDCB
VM
VM
RDWeb
VM
VM
RDSH
RDSH
VM
RDSH
RDSH
VM
Session Desktop RemoteApp
Collection
Collection
Providr Fabric
Compute
Storage
Network
Hyper-V hosts, host clusters, ...
Scale-Out File Servers, JBOD arrays, tiered HDDs/SSDs, ...
Switches, multiple redundant networks, teaming, ...
Figure 5 – Continuous Availability Desktop Hosting Logical Architecture
24
The CA architecture requires additional cost and complexity to implement vs. the HA
architecture model; however, it provides the highest level of availability.
The tenant components of the CA architecture are hosted on a minimum of a two-node Hyper-V
host cluster. All desktop hosting server VMs are implemented as HA VMs.
The CA architecture employs redundant instances of all RDS server roles (i.e., RDLic, RDCB,
RDWeb, RDGW and RDSH), each implemented in separate WS2012 R2 server VMs.
The RD Connection Broker role is implemented as an Active-Active High Availability Connection
Broker (HA RD Connection Broker). The HA RD Connection Broker requires a SQL Server
instance to host the HA RD Connection Broker database. The SQL Server instance is
implemented as a SQL AlwaysOn cluster that requires two SQL Server instances running two
Windows Server 2012 R2 VMs that utilize Hyper-V guest clustering.
Two tenant Active Directory Domain Controllers are implemented as separate HA Hyper-V VMs.
The File Server is implemented as a File Server Cluster implemented in two separate Windows
Server 2012 R2 VMs that utilize Hyper-V guest clustering to provide shared storage.
At least two Windows Server 2012 R2 VM with the RD Session Host server role enabled is
required to host Remote Desktop sessions for highest availability. At least two Windows Server
2012 R2 VM with the RD Session Host server role enabled is required to host RemoteApps for
highest availability.
3.4 Other Tenant Services
3.4.1 Microsoft Application Virtualization
Microsoft Application Virtualization (App-V) technology increases business agility through faster
application deployment and updates with no user interruptions. It minimizes conflicts between
applications, allowing enterprises to reduce application compatibility testing time. App-V is an
optional component that can be employed to significantly simplify deployment and
management of Windows application software within the desktop hosting infrastructure.
The App-V server also needs to host a SQL database on the SQL Server VM.
If App-V is included in the Highest Availability architecture, two App-V servers are implemented
as a separate Windows Server 2012 R2 VMs. In the HA App-V configuration the App-V SQL
database should be hosted with a SQL AlwaysOn Availability Group implemented with two
separate Windows Server 2012 R2 VMs that are clustered using Hyper-V guest clustering.
25
Additional information:
App-V product info site
Getting Started With App-V 5.0
Improvements introduced with App-V 5.0 SP2
The Official Microsoft App-V Blog
Performance Guidance for Application Virtualization 5.0
4 Tenant On-Premises Components
4.1 Infrastructure Components on Tenant’s Premises
This section describes the optional infrastructure components that reside on the tenant’s
premises. Smaller tenants (e.g., small businesses with few employees and no on-premises Active
Directory or other back-end application server infrastructures) will not require any on-premises
back-end infrastructure components. Larger tenants that require client applications running
within the hosted virtual desktops to access back-end on-premises infrastructure will required a
site-to-site VPN to be setup between the customer’s premises and the service provider’s
desktop hosting environment.
The following diagram shows the infrastructure components that may be required on the
customer’s premises.
Tenant 1 Premises
VPN
AD
Other Tenant
On-premises
Services
Figure 6 – Infrastructure Components on Tenant’s Premises
26
4.2 On-Premises Active Directory Domain Services
Some larger and more sophisticated tenants may choose to host an Active Directory Domain
Services (AD DS) Domain Controller server on their premises.
In a managed service scenario, the on-premises AD DS is known as the Customer AD. The
Tenant AD, deployed in the service provider’s environment, is in control of the desktop hosting
service for the tenant. Identities from Customer AD are synchronized to the Tenant AD.
In a hosting scenariothe Tenant AD will typically be a replica of the Customer AD DS server that
is on the tenant’s premises. This is supported by creating a virtual network in the tenant’s Cloud
Service and using a site-to-site VPN to create a secure connection from the tenant’s onpremises network to the tenant’s virtual network in the service provider’s desktop hosting
service.
4.3 Supported Remote Desktop Client Devices
To access the hosted desktops and applications, the tenant’s users must use Remote Desktop
Connection (RDC) clients that support Remote Desktop Protocol (RDP) 7.1 or higher. In
particular, the client must support RD Gateway and RD Connection Broker.
To deliver applications to the local desktop, the client must also support the RemoteApp
feature. To achieve highest gateway scale, the client must support the pure HTTP transport
connections to RD Gateway. Examples include the RDC clients that are available in computers
running Windows 7 with SP1 with latest updates or Windows 8.1 and the Microsoft Remote
Desktop apps for non-Windows operating systems.
Additional information:
RemoteFX Enabled Devices
What’s new in Windows Server 2012 R2 Remote Desktop Gateway
Remote Desktop app for Windows in the Windows Store
Microsoft Remote Desktop - Android Apps on Google Play
Mac App Store - Microsoft Remote Desktop
Microsoft Remote Desktop on the App Store on iTunes
27
5 Desktop Hosting Infrastructure Security Considerations
This SPRA v2 Multi-Tenant RDSH Reference Architecture Guide is designed to provide a highly
secure and isolated environment for each tenant. The security of the system also depends on
safeguards taken by the provider during deployment and operation of the hosted service.
Following is a list of some mitigations that the provider must consider to help make sure the
security of a desktop hosting solution based on this reference architecture.



All administrative passwords must be strong, and ideally randomly generated, changed
frequently, and saved in secure central location that is only accessible by a select few
provider administrators.
Care must be taken when replicating the tenant environment for new tenants to avoid
using the same or weak administrative passwords.
The RD Web Access site URL, name and certificates must be unique and recognizable to
each tenant to mitigate spoofing attacks.

During the normal operation of the desktop hosting service, all access to all VMs from
the Internet should be removed except the for the HTTPS and UDP ports for the RD Web
and RD Gateway VM that allow users to securely connect to the tenant’s desktop hosting
cloud service from the Internet.
Additional information:
Security and Protection Overview
Strong Passwords
Security Best Practices for IIS 8
Secure Windows Server 2012 R2
See the Security Design section of the SPRA v2 Multi-Tenant Foundation Architecture Guide
document for additional security recommendations.
6 Desktop Hosting Infrastructure Licensing Considerations
The following changes to RDS CAL licensing in Windows Server 2012 R2 are effective as-of
November 1, 2014:

Windows Server 2012 CALs provide entitlement to R2 functionality.

RDS User CALs Extended Rights through Software Assurance
Customers are be able to access the Windows Server GUI running on Windows Azure or
on a 3rd-party’s shared server environment, without acquiring a separate RDS SAL.
28
The following tables list the desktop hosting scenarios and associated Windows Server 2012
R2 RDS license types:
Service Provider Scenario
Type
SAL
Mode
Per user
Technical
SPLA agreement number only
Basis
Unique users authorized to access the desktop hosting environment
Source
From SPLA reseller. Special case: Software Assurance customer may
bring their own per user CALs.
Who pays
Microsoft?
Service Provider
Table 1 – RDS Licensing for Service Provider Scenario
Self-Hosted Software Assurance Customers in Partner Hosted Cloud Scenario
Type
CAL
Mode
Per user
Technical
CALs added to RD License Server
Basis
Unique users authorized to access the desktop hosting environment
Source
Microsoft or CAL reseller
Who pays
Microsoft?
End-customer (tenant)
Table 2 – RDS Licensing for Self-Licensed Software Assurance Customers in Partner Hosted Cloud Scenario
Enterprise Private Cloud Scenario
Type
CAL
Mode
Per user or per device
Technical
CALs added to RD License Server
Basis
Unique users or devices accessing the desktop hosting environment
Source
Microsoft or CAL reseller
Who pays
Microsoft?
End-customer (tenant)
Table 3 – RDS Licensing for Enterprise Private Cloud Scenario
29
Additional information:
Windows Server 2012 R2 – Remote Desktop Services Licensing Data Sheet
Microsoft Volume Licensing: Licensing Options for Service Providers
30
7 Desktop Hosting Infrastructure Scalability Guidelines
In a typical hosted RDS deployment, the RD Session Host and RD Gateway server VMs will be
the limiting factors in scaling. When considering RD Session Host and RD Gateway VM scaling
one should consider the following.

RDS infrastructure scaling is highly workload and infrastructure dependent.

When verifying the scalability of a desktop hosting infrastructure, it is important to
average across measurements of actual workloads (i.e., real users using real applications
on the target infrastructure).
Note: The sizing estimates provided in this section are based on Dell PowerEdge R720 servers with Dual
Socket 10C Intel® Xeon® processor E5-2600v2 40 Logical cores and 128 GB Memory. Scaling estimates are
hardware dependent and will change over time as new hardware becomes available.
The following table lists general scaling recommendations for RD Session Host and RD Gateway
VMs with a light, medium and heavy user workloads.
Server
Light
Medium
Heavy
RD Session Host1
8 users / vCPU
5 users / vCPU
4 users / vCPU
270 MB RAM / user
450 MB RAM / user
630 MB RAM / user
200 connections / vCPU
200 connections / vCPU
200 connections / vCPU
1 Mbps / connection
1 Mbps / connection
1 Mbps / connection
RD Gateway2
Table 4 – General RD Session Host and RD Gateway Sizing Guidelines
Following are example3 RDSH and RDGW VM sizing recommendations for a desktop hosting
infrastructure designed to support 15 concurrent users:

RDSH environment sizing to support 15 concurrent users
o
o
RDSH: 2 VMs with 2 vCPU and 1.75 GB RAM each
RDGW: 1 VM
1
The RDSH sizing example is based on testing performed using the Login VSI 4.0 Light, Medium, and Heavy Workloads.
2
The RD Gateway sizing example is interpolated from the information in the RD Gateway Capacity Planning in Windows Server 2012 document.
3
These examples are intended for approximate sizing only. Your results may vary.
31
Additional information:
For additional RDS sizing details, see slides 40-47 in the TechEd North America 2014 PCIT-B338
presentation.
RD Gateway Capacity Planning in Windows Server 2012
7.1 Design Considerations for Hosting Very Small Tenants
The primary purpose of this document is to show how to support very small tenants with 20-25
users in a cost effective way. This section describes some design considerations for hosting very
small tenants.

Right size the VMs to support auto-scaling (i.e., spinning up and down RD Session Host
VMs dynamically based on demand. To support auto scaling RDSH VMs, smaller sized
RD Session Host VMs for finer granularity of VMs is recommended (e.g. two 4 cores VMs
vs. one 8 core VM). For an example of how to auto-scale RD Session Host VMs using a
PowerShell script see Automatic Scaling of Remote Desktop Session Hosts in Azure
Virtual Machines. While the example PowerShell script above is designed to auto-scale
RDSH servers running in IaaS VMs hosted in the Microsoft Azure cloud, it can be adapted
to work in a hosted service provider environment.

Windows Server 2012 R2 RDS role services can be combined to minimize the number of
VMs and resources required to support each tenant.

For small tenants, the cost can be reduced further by combining the file server and AD
DS with the RDS components on a single virtual machine in the tenant’s environment,
such as the AD DS and RD License components.
32