As a key part of the original team at Microsoft that launched the service, I created this 5-part series to provide a review of how we got to Azure Virtual Desktop.
In my second blog post in the series, we discussed Remote Desktop Services (RDS). In continuing onward in the evolution to AVD, this third blog looks at RDS in Microsoft Azure and the impact of the Microsoft cloud on EUC (end user computing).
RDS in Microsoft Azure: Benefits of the Cloud
Two of the biggest advantages of cloud computing are scalability and flexibility. You don’t have to pay flat out to own infrastructure, you can just rent it, and from Microsoft – a global leader in IT and security.
A good example of how the cloud enables these: I am H&R Block or some other company that has seasonality, meaning certain seasons of the year, they double, triple or even quadruple their workforce. Historically, if I’m doing that in my data center, I have to buy enough servers to handle peak load for the 2-3 months when it’s the height of sales season. The rest of the year those servers sit there and do nothing, right? Hopefully I turn them off, so I don’t have to pay the compute costs plus the electricity bill.
Disaster Recovery
Another big benefit, and one that inspired RDS in the cloud, is disaster recovery. RDS on-premises does not allow for high availability and disaster recovery scenarios were complex. Migrating to Azure helped to solve this. Instead of requiring a data center or two data centers, customers could take their infrastructure and put it in Azure. Even better, with Azure, you don’t have to go and buy hardware. And instead, can operate leveraging Azure virtual machines (VMs) and the operating system.
Configuring RDS in Microsoft Azure
When putting RDS in Azure, folks ask, “but the steps for setting up RDS are still the same, right?” And the answer was yes. Instead of purchasing a physical server, now you create a VM. You still must install all roles on all servers. You still have to do all RDS configuration manually as before.
Over time, Microsoft and the community around RDS built ARM templates and scripts to deploy a full RDS environment in Azure. The solution worked but was not elegant and amplified the complexity and the difficulty of managing RDS. Now IT administrators had to know Azure on top of RDS. The challenges around application and OS management were not solved. X
Limitations of Cloud-based RDS
Over time with RDS in Azure, Microsoft figured out that there were components of RDS that could be moved from dedicated VMs to services in Azure. Hence, helping IT admins be more efficient, while driving down cost and to some extent complexity. For example, initially there was a need for an SQL server, later Microsoft moved to using Azure SQL.
Another example was user profiles, back then Microsoft had User Profile Disks (UPD), and technically there were 6+ different solutions. UPDs worked fine with on-premises file servers and an RDS admin can create a file server in Azure and achieve parity. However, overtime the requests to support Azure Files became frequent and loud.
Back then Azure Files didn’t support Active Directory and so you had to do a very fancy thing with mapping drives and installing service principles and service accounts. Microsoft invested in RDS and allowed administrators to directly attach storage accounts from Azure Files leveraging FSLogix.
