It should be noted that this is not a technical blogpost, but more about the overall strategy of how you should look at managing Azure Virtual Desktop at scale based on the way of working with cloud within your organization. But I’m going ahead of myself, so let’s start with the background.
As an increasing number of organizations transition to public cloud and seek to replace their current VDI solution, Azure Virtual Desktop is likely to be a top contender for their next platform. One key reason for this is that Azure Virtual Desktop is the sole platform offering a multi-session OS on Windows 10/11 (Except Azure Stack HCI). Additionally, it is set to become one of the few supported platforms for Microsoft 365 apps due to licensing restrictions implemented by Microsoft in the next couple of years…yay..
When AVD was released about 4 years ago I viewed it as a poor-man’s way of providing virtual apps and desktop, since it at the time had limited management capabilities and no mechanisms to provide image management like most other 3.party tools had at the time.
To add some context, I was one of the few that worked and implemented Azure Remote App back in the day and was early part of the RDMI private preview (which later became WVD). WVD at the time of its release was not a native Azure Resource Manager citizen (ARM), meaning that it could not take benefit of the automation layer that was available.
Now further down the line, AVD was reborn as an ARM native citizen which allow us to take benefit of IaC tooling and automation capabilities to build AVD at scale. Secondly Microsoft provided us with new capabilities such as Azure Image Builder (which is built upon packer) as a separate service and now lately has made numerous enhancements to the platform such as ShortPath and new data sources for Azure Monitor, SSO support and other nifty enhancements to the overall end-user experience.
But still, it is possible to manage AVD at scale compared to a large Citrix PVS environment? No…. Not natively at least (and I’ll get back to what I mean by that). In many large Citrix environments, you might have a single person that was responsible for the entire Citrix environment and being able to easily update an image with new security patches, new versions or update an application in the image and just by flipping a switch easily update the image to the latest versions and voila! You have five thousand users on a new desktop. Secondly you have different mechanisms to handle application management such as layering and much more robust policy and security management.
Also, you have better mechanisms and built-in monitoring capabilities that can tell you what is going-on or drilldown into the logon mechanisms and application probing capabilities. Of course, you are paying extra to get those capabilities as well, but my main point is that it requires less resource to manage a large-scale Citrix environment that it would be to have the same amount managing the same size in AVD using the native capabilities.
So, what options do we have in AVD? Well, we have the Azure Portal, or we can use CLI to script some of the deployment and configuration, however this does not scale since AVD machines are persistent by nature (unless you are using ephemeral disks, but that is another discussion). Meaning that you will need to build up a new host pool or update the machines individually and manage them as you would any other server.
So, what does this mean for an organisation moving to cloud? I often see them taking three different routes, depending on the size and shape of the environment and the organisation maturity
1: Small customers can often move to AVD without the need of image management and advanced monitoring capabilities. Meaning that most of the deployment will be done through the Azure Portal or light scripting using PowerShell or CLI. However, it is still dependent on that the VDI administrator to learn azure properly and then treat the AVD machines as any other static server.
2: Larger organizations with existing Citrix/VMware administrators often opt for third-party tools that can provide similar management capabilities to their previous VDI environment. Nerdio is one such alternative that offers management capabilities on top of the AVD environment. This means that they can manage their new VDI environment with a familiar management UI which abstracts away the complexity that is introduced by the cloud platform.
3: For customers that embrace the public cloud more natively and fully automate their Azure environment. This involves using automation and Infrastructure-as-Code (IaC) to deploy AVD and automate image management using Continuous Integration/Continuous Deployment (CI/CD) pipelines through GitHub Actions. They are also using more of the native capabilities that the cloud providers offer. This in most cases, means that they are using the same approach for all services that are being built in the public cloud, and having a centralized CCOE team that is responsible for building and implementing the core mechanisms and automation tools.
Looking at the alternatives for a large-scale environment, option three will always provide the most flexibility and possibilities. Such as when Microsoft releases a new feature you often had the option to use that new feature directly and deploy it using code. However, with third party tools you will need to wait until they support that new capability from Microsoft. While you get more flexibility it means that it will need more work to be able to implement changes/updates compared to a third-party tool, since the code needs maintaining with new versions to providers / features and new capabilities.
However which approach is more suitable for an organization is not dependent on tooling, but more how mature the organization is and the amount of people available to maintain the environment. This is the biggest issue with most organizations adopting cloud and that is all the on-going changes. Within Microsoft Azure alone there is about 1200 new changes/features on a yearly basis, which means that your organization needs to be able to understand those changes and how they impact or can benefit your existing services.
If you don’t have the resources available to be able to build and maintain the code, and you have a rather large enviroment that I would recommend a third-party tool. If you want to fully embrace the cloud way of working and use IaC then I recommend looking at building AVD as code, but each option has its own set of upsides and downsides.