UPDATE: With the upcoming release of Windows Server 2012 R2, we've announced several changes to RDS CAL licensing. One of these changes is that, by next year, customers with Software Assurance (SA) will be able to leverage their existing RDS CALs with license mobility to apply to either an on-premises Remote Desktop Services installation or a deployment of Remote Desktop Services on Windows Azure. This new RDS licensing option, when available, will provide an additional choice for licensing RDS on Windows Azure, as an alternative to using RDS Subscriber Access Licenses (SALs) noted below in this article.
For more details on the RDS licensing changes in Windows Server 2012 R2, please see the Windows Server 2012 R2 RDS Licensing FAQ on the Microsoft Download Center.
In Part 1 of this two-part article series, we introduced Remote Desktop Session Virtualization on Windows Azure as an attractive alternative to traditional Desktop as a Service ( DaaS ) solutions. Remote Desktop Session Virtualization provides a high-density solution that requires provisioning and managing far fewer VMs than traditional DaaS, while still providing a robust and highly compatible method for delivery of high-fidelity remote desktop and remote application experiences to users.
In this article, we’ll step through the provisioning process for configuring a Remote Desktop Session Virtualization lab environment on the Windows Azure pay-as-you-go cloud platform. Our lab environment will consist of two VMs: one VM configured as an Active Directory Domain Controller and DNS server, and a second VM configured as a Remote Desktop Session Host, Web Access gateway, and Connection Broker.
Lab Scenario: Remote Desktop Session Virtualization in the Cloud
Note: If your production needs require higher scalability with multiple Remote Desktop servers or larger VM sizes, this base environment can be easily scaled-up to support those additional requirements.
In this Step-by-Step guide, you will learn how to:
Estimated time to complete: 1 hour, 15 minutes
In this exercise, you will activate a free Windows Azure Trial Subscription and then setup two components that will be needed for the other exercises in this lab: a Windows Azure Affinity Group and a Windows Azure Storage Account.
Register the internal IP address that our domain controller VM will be using for Active Directory-integrated Dynamic DNS services by performing the following steps:
Define a common virtual network in Windows Azure for running Active Directory, Database and SharePoint virtual machines by performing the following steps:
Provision a new Windows Azure VM to run a Windows Server Active Directory domain controller in a new Active Directory forest by performing the following steps:
The configuration for this virtual machine is now complete, and you may continue with the next exercise in this Step-by-Step guide.
Provision a new Windows Azure VM to run Remote Desktop Session Virtualization by performing the following steps:
The Remote Desktop Session Virtualization VM configuration for your lab environment is now completed. In a production environment, before continuing, you would also use the RD Licensing Manager tool to Activate your licensing server and Install Licenses for user-mode Remote Desktop Subscriber Access Licenses (SALs). See Remote Desktop Licensing for detailed steps for activating and installing licenses in a production environment.
In this exercise, you will test Remote Desktop Services connectivity to a Windows Azure virtual machine running Remote Desktop Session Virtualization. Begin this exercise from your local PC desktop.
Your functional Remote Desktop Session Virtualization lab environment is now complete, but if you’re like me, you won’t be using this lab environment 24x7 around-the-clock. As long as the virtual machines are running, they will continue to accumulate compute hours against your Windows Azure subscription.
To preserve your compute hours for productive lab work, be sure to shut down each VM from the Windows Azure Management Portal when not in use. After each VM is successfully shutdown, the status of each VM will be listed in the portal as “Stopped (Deallocated)” and compute charges will not accumulate for VMs in this state.
NOTE: It is important to shut down the VMs from the Windows Azure Management Portal to properly de-allocate compute resources and prevent compute charges from accumulating. If you shutdown VMs from within the Guest OS, the VMs will be placed in a “Stopped” state where compute resources are not de-allocated and compute charges in this state will still apply.
Like this article? Subscribe to "IT Pros ROCK!" and stay up-to-date!