Self-service deployment of Microsoft workloads on Cloud Platform System (and other systems with Windows Azure Pack) – Part 4

Artikel
05/27/2015

For this post, we are glad to host Thomas Roettinger, Program Manager in Microsoft’s ECG CAT Team focusing on Cloud Solutions. Thomas announces the availability of another workload self-service deployment sample: remote desktop session hosting.

In this post, I am glad to announce the availability of the Remote Desktop Session Hosting(RDSH) as an addition to our self-service deployment sample family. In previous posts of this series we published Active Directory, SQL Server, SharePoint and Exchange 2013 SP1. Now it is time to get a Virtual Desktop to consume those services.

We follow our design principles and leverage Service Management API (SMA) and Desired State Configuration to automate the installation of the Windows Server 2012 R2 instances, the required Windows Features and the load balancer!

Brought to you by the CPS team, with a lot of help from the Microsoft Enterprise Cloud Group’s Customer Acceleration Team (the Building Clouds guys). And remember, CPS is not a pre-requisite, because you can use these items with some adjustment if you have already deployed the Windows Azure Pack (WAP). As with the first two releases, we are making these available through the VMM content feed.

Previous blogs in this series:

Part 1- SQL Server 2014 and Active Directory. Read this to get the pointer to the WebPI feed!

Part 2- Exchange 2013 SP1.

Part 3 – SharePoint.

Remote Desktop Session based Deployment

We have taken the learnings from deploying Remote Desktop Services in Microsoft Azure and brought them on-premises. For Microsoft Azure, we created a Desktop Hosting - Reference Architecture and Deployment Guide.These guides cover two scenarios, a basic hosting desktop solution and an advanced solution.

In this release, we have fully automated the deployment of a basic hosting scenario that can be scaled out to an advanced solution. (Steps for scaling out to an advanced solution will be covered in a dedicated blog post part of this series.) As mentioned earlier, we have taken the deployment steps from the Azure Reference Architecture and Deployment Guide and complemented them:

1. Automated all the steps to have a self-service experience.

2. Adjusted the architecture to fit Cloud Platform System.

What the deployment does

The deployment can be triggered by subscribing to a plan as discussed in earlier blog posts or in a do-it-yourself fashion.

When the deployment is finished you will have the following Architecture:

Subscribing to the Dedicated RDSH plan will result in the following activities:

1. A VM network is created using our software defined networking capability.

2. A new AD domain is set up with two DCs, including DNS (and the VM network is configured for that).

3. Connection Broker VM gets provisioned that is also running the licensing & File Server.

4. A VM running Remote Desktop Session Host Role is deployed.

5. A VM running RD Gateway & RD WEB is deployed.

6, The load balancer gets configured to listen for inbound traffic on 443 (VIP) pointing to the VM running RD Gateway & RD WEB.

7. Connection Broker creates the RDS Deployment and creates a Collection when the VMs from Step 4&5 are finished provisioning.

There is one last manual step once the deployment is finished. That is adding your certificate to the deployment. Of course, you also want to have a DNS entry pointing to the VIP IP to ensure you certificate CN name is matching.

Validation

We ran Login VSI (a performance benchmark) against this architecture and have been able to get 32 User Sessions with a medium workload (defined by Login VSI)per Session Host Virtual Machine. The Remote Desktop Session Host in this test case was using a VM Profile Size equal to an Azure A4 VM (8 CPUs, 14 GB Memory).

Samples

The usual reminder: these are examples for you (the service provider/enterprise private cloud admin) to customize to best suit your customers’ needs. To modify them will require an understanding of how WAP works, how the multiple scripting engines process scripts, and how to edit the automation artifacts. An understanding of PowerShell is also going to be a prerequisite. See the Building Cloudsblog and the rest of the resources at the end of this post.