This is the second in my series of blog posts about desktop virtualization using Windows Server 2012 R2 and Microsoft Azure . In today's blog post, I want to talk about how to deploy desktop virtualization. In my last post , I introduced the various desktop virtualization deployment models that we can use, including on-premises, Microsoft Azure, and a combination of both (hybrid). I want to give you an overview of each deployment model and wrap up this post with a discussion about Remote Desktop Session Host (RD Session Host) image management. Let's jump right in and take a closer look at on-premises deployment.
On-premises
On-premises deployment is pretty straightforward, and there are a number of Test Lab Guides that provide step-by-step instructions for configuring Remote Desktop Services. But the old saying "A picture is worth a thousand words" is appropriate here. Figure 1 illustrates a typical Remote Desktop Services infrastructure deployment. If you’re unfamiliar with what each one of the Remote Desktop Services role services does, check out my first blog or see Remote Desktop Services Overview and the Remote Desktop Service Component Architecture .
Figure 1. Example of on-premises Remote Desktop Services infrastructure
The session-based Remote Desktop Services infrastructure is a prime candidate for virtualization itself. Figure 1 shows which role services can run on the same virtual machine (VM) and which might require one or more VMs. Of course, for testing purposes, you can run all of these in one or two VMs. However, for production environments, you’ll need to scale out further to support user capacity.
Also, it should be pointed out that the file server in this sample infrastructure is running Windows Server 2012 R2 (required to support SMB 3.0). The file server stores user profile disks, backs up data, and provides shared folders in which users can store data and share that data with other users.
Again, check out the Test Lab Guides for more information about deployment.
Microsoft Azure
As illustrated in Figure 2, deploying Remote Desktop Services in Microsoft Azure (IaaS) is very similar to on-premises deployment. There are the same Remote Desktop Services role services as with the on-premises solution. However, you'll notice some minor differences. For example, the load balancer and traffic manager are virtual entities in Microsoft Azure. Figure 2 also includes the Azure Management Portal, which is used to manage and monitor services running in Microsoft Azure (see my previous blog). Notice that the RD Virtualization Host server cannot be run in Microsoft Azure, as you are unable to virtualize, systems that run virtualization.
Figure 2. Example of Remote Desktop Services infrastructure in Microsoft Azure
You'll need to synchronize your on-premises Active Directory Domain Services (AD DS) with Microsoft Azure Active Directory (see the AD DS domain controller in Azure). You'll need to perform this synchronization so that users can use their same domain credentials to sign in to the Remote Desktop Services infrastructure. You can perform synchronization by using the Azure Active Directory Sync tool. For more information about synchronizing Azure Active Directory with your on-premises AD DS, see Administering your Azure AD directory .
Note that this infrastructure contains multiple instances of SQL Server (which supports the RD Connection Broker in high-availability solutions). Also, if you want to support users in multiple cloud services, you can deploy the Remote Desktop Services infrastructure in one cloud service and the RD Gateway and RD Web Access role services in the other clouds.
When deploying your Remote Desktop Services infrastructure in Azure, consider the following:
- Azure subscriptions have a maximum number of virtual networks, VM cores, storage, and cloud services that can be supported. Consequently, you might need to create multiple subscriptions.
- Because Azure deployments are partially based on the number and size of VMs, optimize the number and size of VMs to provide the highest cost-performance ratio.
- Use Azure availability sets when creating solutions that require high availability.
A wealth of deployment information about deploying Remote Desktop Services in Azure is available at Azure Desktop Hosting - Reference Architecture and Deployment Guides , which includes the following guides:
- Desktop Hosting Reference Architecture Guide
- Desktop Hosting Deployment Guide
- Remote Desktop Web Access and Gateway Farm Deployment
Hybrid
As you might guess, hybrid deployments of Remote Desktop Services combine both on-premises and Azure deployment methods. Typically, you would start with your on-premises deployment and then create your Azure deployment.
As with the Azure deployment model, you will need to synchronize your on-premises AD DS with Azure Active Directory . This synchronization ensures that users can access on-premises or Azure resources by using the same credentials.
You will need also create a virtual private network (VPN) connection between your on-premises desktop virtualization infrastructure and your Azure infrastructure. This connection will allow users to transparently use desktop virtualization on premises or in Azure, and it will allow virtualized desktops in Azure to access on-premises resources. For more information about Azure VPN connections, see Windows Azure Virtual Network Overview and Windows Azure: Virtual Network .
RD Session Host image management
One last deployment topic that I'd like to cover is creating a standard RD Session Host image. Because the recommendation is to use VMs on premises, you can use the same virtual hard disk image for on-premises and Azure deployments. Both System Center 2012 R2 Virtual Machine Manager and Azure support the creation of VM templates, so the idea is to create a VM template in both infrastructures that is based on the same RD Session Host image.
The process is pretty straightforward. Let's take a look at it.
- Install and configure an RD Session Host in an on-premises Hyper-V VM.
- Run Sysprep.exe on the VM (to generalize the operating system).
- Export the Hyper-V VM.
-
For on-premises deployment, perform the following:
- Import the exported VM as a template in System Center 2012 R2 Virtual Machine Manager.
- Deploy RD Session Host servers as required by using the template.
-
For Azure deployment, perform the following:
- Upload the VM virtual hard disk file into Azure storage.
- Create a VM template in Azure that has the same configuration as the original VM and uses the VM virtual hard disk file that you uploaded in the previous step.
- Deploy RD Session Host servers as required by using the template.
Of course, the big advantage of using this method is consistency in RD Session Host server farms (where you have two or more VMs). You want each VM running RD Session Host within the farm to be identically configured so that users have the same experience, regardless of which VM they connect to.
Another advantage is that this method allows you to quickly "spin up" additional RD Session Host VMs if you need additional capacity. You can always "spin down" or remove the extra VMs later when they aren't needed.
Summary
That’s an overview of Remote Desktop Service deployment--on premises, in Azure, or both. Clearly, you have the flexibility to place your desktop virtualization infrastructure where it can best support your business and your users. Deploying Remote Desktop Services is easy and requires minimal changes to your infrastructure. And you can grow your Remote Desktop Services infrastructure to meet your demands now and in the future.
But how do we connect devices to our newly deployed infrastructure? That's the topic of my next blog post! See you then!
NEXT BLOG POST IN THIS SERIES: Accessing desktop virtualization (Coming June 5)