First published on CloudBlogs on Jul 13, 2015
Today we are happy to announce availability of the Azure Resource Manager Template for Remote Desktop Services (RDS) Deployment based on our
Azure Desktop Hosting Deployment Guides.
The template location is:
http://azure.microsoft.com/documentation/templates/rds-deployment/
The template allows you to easily deploy a basic session-based desktop collection including all the Server role services of a typical RDS deployment:
-
AD / DNS server
-
RD Connection Broker
-
One or more RD Session Host (RDSH) servers
-
RD Gateway
-
RD Web Access server
-
RD License server
This blog post is organized under the following topic headings:
-
About Azure Resource Manager
-
Using the Template
-
The Resulting RDS Deployment
-
Connect to the RDS Deployment
-
Manage the RDS Deployment Using Server Manager
About Azure Resource Manager
Azure Resource Manager
is the new management API layer for the Microsoft Cloud. The introduction of Azure Resource Manager makes it easy to deploy and manage multiple related Azure resources together as single logical units, also known as resource groups.
Azure Resource Manager provides a declarative, template-driven method for defining resources and their configuration allowing you to automate and simplify the deployment process. By using a template, you can repeatedly deploy the configuration in both public (Azure) and on-premises (Azure Stack) cloud infrastructure, and have confidence your resources are deployed in a consistent state.
Using the Template
Running the template from Azure Portal
Running the template is as simple as clicking the “Deploy to Azure” button.
|
|
The template supports a number of parameters (
Figure 1
) which allow you to customize the deployment. Some of the parameters have default values supplied. There are 3 mandatory parameters for which you must provide values.
Parameter name
|
Description
|
publicDnsName
|
The Domain Name System (DNS) prefix for the external public IP address for the deployment.
This must be a unique name consisting of lower-case characters, digits, or dashes.
The resulting fully qualified domain name (FQDN) will be in the form of:
<publicDnsName>.<location>.azure.cloudapp.com
|
newStorageAccountName
|
A new storage account will be created as part of the deployment. This will be used to store virtual hard disks for the virtual machines.
This should be a unique name, up to 24 chars, all lower-case.
|
adminPassword
|
Password for the domain administrator account (specified by domainNameadminUsername parameters).
Keep this password secure! Make sure it meets domain admin password complexity requirements (i.e. it’s not something simple or obvious like “password” or “abcd1234”).
|
There are 2 parameters that allow you to control the size of the deployment.
Parameter name
|
Description
|
numberOfRdshInstances
|
Number of RDSH servers in the deployment.
The default is: 2 RDSH servers.
|
rdshVmSize
|
The size of the virtual machines used for RDSH servers.
The default is size A2 with 2 cores and 3.5GB of RAM.
Note: all other VMs in the deployment (DC, RD Broker and RD Gateway) are also A2 by default, this can be changed by modifying the template JSON directly.
|
You can also modify parameters to specify the Active Directory domain name, the administrator user name, and the location of assets used by the template.
Figure 1.
Template parameters.
When you have finished setting the parameter values, select
OK
.
Next, you must specify the name of the resource group (either new or existing) and its location. All the resources, including the new storage account and virtual machines, will be deployed to the region specified by the resource group.
Finally, you must accept the legal terms by selecting
Buy.
Now you are ready to create your basic RDS deployment by selecting
Create
.
Running the template using Azure PowerShell
If you prefer using Azure PowerShell to accomplish the task, run the following PowerShell commands.
For more information on how to use Azure Powershell with Azure Resource Manager please see “Deploy with PowerShell” section at
https://azure.microsoft.com/en-us/documentation/articles/resource-group-template-deploy
.
The Resulting RDS Deployment
Once provisioning operation completes, let’s look at the resources that were created as part of the deployment (
Figure 2).
Figure 2
. Resource group view after deployment.
The template has created:
-
VNET
-
new storage account
-
public IP resource
-
Load Balancer resource
-
VM for Active Directory and DNS server roles
-
VM for RD Gateway and RD Web Access server roles
-
VM for RD Connection Broker and RDS License server roles
-
VMs for RD Session Host (RDSH) servers.
|
|
Connect to the RDS Deployment
Azure has allocated a public IP address from a pool of available addresses and created an associated global DNS record that has the following format. <
publicDnsName
>.<
location
>.azure.cloudapp.com
For example, if you specified parameters as shown in Figure 1, the resulting RD Web URL would be:
https://rds-deployment.centralus.cloudapp.azure.com/rdweb
The ports on the Gateway VM (also running RD Web Access role) that are exposed to the Internet are HTTPS port 443 and UDP port 3391 (for improved RDP performance).
Log onto RD Web Access server
Let’s connect to the deployment and verify that it was provisioned and configured as we intended.
Navigate to the RD Web URL, select
Continue to this Web site (not recommended)
to bypass certificate warning. (See the note about gateway certificate below.)
Enter credentials using the domain name, administrator account name, and password that you specified in the template parameters, and select
Sign in
.
Once logged in, you should see a simple collection named
Desktop Collection
.
Install RD Gateway certificate on the client computer
Note
: In a production environment you would install a certificate from a trusted root certificate authority on the RD Gateway and this step would not be necessary. You can also create a self-signed certificate for the RD Gateway and pre-install it on the client computers. For a step-by-step procedure for creating a self-signed certificate, exporting it and installing on client computers see the “Desktop Hosting Deployment Guide” document
here
.
For the purposes of this blog post, we will describe how to download the default RD Gateway certificate and install it on the client computer.
Select the collection icon to make the connection and the Remote Desktop Connection certificate warning dialog will appear.
To download the default certificate, select
View certificate…
,
Details
tab,
Copy to File…
, and then save the certificate (.cer file) on your computer.
To install the certificate, right-click the .cer file, select
Install certificate
,
Local Machine
,
Place all certificates in the following store
,
Browse
,
Trusted Root Certification Authorities
, and
OK
.
Connect to the deployment
Now make the connection again (by clicking the “Desktop Collection” icon in RD Web) and you should connect to one of the Remote Desktop Session Host VMs in your deployment.
Manage the RDS Deployment Using Server Manager
To view and manage Remote Desktop Services from Server Manager we recommend that you remotely connect to the RD Connection Broker server and run Server Manager. This can be done by running mstsc.exe, entering the name of the connection Broker server (broker.<addomainname>.com, and log on using the domain administrator credentials.
Once logged onto the RD Connection Broker server, launch Server Manager, select
Manage and Add servers
. In the
Add servers
dialog select
Find now
, select all of the servers (‘broker’, ‘gateway’, and all the RD Session Host servers named ‘rdsh-{n}’), and select
OK
.
Now select
Remote Desktop Services
in Server Manager and you will see the familiar Deployment Overview UI:
Now you could add more users to your AD, configure Gateway and Single-Sign-On (SSO) certificates, and have the new users connect and use your new Remote Desktop Services deployment running in Azure! We hope that this post helps you understand both the value and how to start using the Azure Resource Manager template for RDS.
Note: Questions and comments are welcome. However, please DO NOT post a request for troubleshooting by using the comment tool at the end of this post. Instead, post a new thread in the
Remote Desktop Forum
.