This article originally documented the classic Azure deployment model, back when virtual machines lived behind cloudapp.net endpoints and RDS was commonly hosted as a single server in an Azure VM. That architecture is now part of the archive. The post still has value as a record of how administrators bridged on-premises identity and early Azure IaaS, but it is no longer current deployment guidance.
This article originally documented the classic Azure deployment model, back when virtual machines lived behind cloudapp.net endpoints and RDS was commonly hosted as a single server in an Azure VM. That architecture is now part of the archive. The post still has value as a record of how administrators bridged on-premises identity and early Azure IaaS, but it is no longer current deployment guidance.
Beginning: what the old design was trying to solve
The aim was simple. Stand up an RDS 2012 server in Azure, join it to a domain, and expose RDWeb over HTTPS so users could reach published resources remotely.
At the time, the minimum foundation looked like this:
- An Azure virtual network
- A domain controller, either on-premises over site-to-site VPN or in Azure
- A Windows Server VM provisioned from the Azure gallery
- An HTTPS endpoint published for RDWeb
The important principle still holds up: identity and networking had to be ready before the RDS server was deployed.
Middle: the deployment flow that mattered
1. Build the network and domain path first
Before the RDS VM existed, administrators needed a reliable line of sight to Active Directory. In the classic model that normally meant one of two choices:
- Extend the on-premises domain into Azure with a site-to-site VPN
- Stand up a new domain controller inside Azure
Without that step, the RDS server might be buildable, but it would not be useful in a domain-based deployment.
2. Provision the RDS VM from the Azure gallery
Once the network foundation was ready, the RDS host could be created from the Azure gallery, then configured like any other Windows Server:
- Apply base settings
- Join the domain
- Install the RDS roles required for the chosen design
In smaller environments this was often a single all-in-one server rather than a split role deployment.
3. Publish RDWeb with TCP 443
In the classic Azure model, public access was handled with VM endpoints rather than modern load balancer and NSG patterns. To expose RDWeb, the key step was to publish TCP 443 to the VM.
Once that endpoint was in place, users could browse to:
https://<servername>.cloudapp.net/RDWeb
If a vanity name was required, a public DNS CNAME could then point the chosen hostname at the Azure cloudapp.net address.
End: what still matters from this design
The Azure classic implementation is obsolete, but three ideas from the article still stand:
- Do identity and networking first
- Treat remote access publishing as a separate design step
- Keep internal naming, public naming, and certificate planning aligned
What has changed is the platform choice. In 2026, greenfield remote desktop projects belong on Azure Virtual Desktop or on a supported Windows Server deployment model using modern Azure resource management, not on the retired classic VM experience.
Closing thoughts
This post is worth keeping as a historical bridge between on-premises RDS thinking and early Azure infrastructure. It is no longer a how-to for new builds, but it now reads like a proper archive article instead of a broken set of screenshots.
