Blogs

Azure Done Right Series: Automating Windows Virtual Desktop (WVD) Host Pools with Pipelines

Introduction

Windows Virtual Desktop (WVD) is a service that gives users easy and secure access to their virtualised desktops and remote apps. WVD has a concept of host pools, which is essentially a collection of Azure virtual machines that act as remote desktop session hosts that users connect to.

WVD is still in preview and has recently gone through some development referred to as Windows Virtual Desktop Spring 2020 Release. This release has introduced some much needed improvements with a WVD blade now in the Azure portal, AAD group integration, host pool registration tokens and much more.

With all the new changes to WVD, automating the deployment of host pools can be challenging, especially if you would like to automate the configuration of some of the optional features such as user profile containers.

Today we are going to run a deep dive and automate the WVD host pool deployment by setting up a pipeline in Azure DevOps.

Prerequisites

You will need a few prerequisites before you will be able to continue.

  • A key vault which holds the credentials used to domain join VMs.
  • Log analytics workspace for WVD diagnostics logs
  • (optional) A storage account joined to the domain with a file share configured to host user profile containers

Pipeline

My pipeline has been configured with 3 jobs.

  1. Build
  2. Deploy
  3. Cleanup
Build

The build job creates a temporary storage account and uploads the DSC files required to configure the host pool VMs.

Deploy

The deploy job has numerous tasks;

  1. Creates WVD host pool and generates a temporary registration token
  2. Configures diagnostic logging to a log analytics workspace
  3. Obtains the password for the account to join VMs to domain from the key vault
  4.  Conditionally deploys the ARM template to create VMs and register them to host pool using an Azure marketplace image or custom image

Here is where the magic begins!

The ARM template deployment not only deploys the Azure VMs and joins them to the domain. It runs a DSC configuration that installs the Windows Virtual Desktop Agents on each VM (yes, this was introduced in the spring release) and configures the agent with the registration token generated previously. This process allows your VMs to register and join the WVD host pool.

But wait, that’s not all!

Enter in the power of pipelines! If you would like to enable user profile containers you can simply set a variable to true and BAM! The DSC configuration will not only install the Windows Virtual Desktop agents but install the FSLogix software as well and configure it to store the user profiles in your domain joined storage account.

This gives you a much better alternative to creating an Azure VM image, install the FSLogix software, and configuring it with the storage account file share URI. Just imagine having to update an entire Azure VM image just to update the FSLogix file share URI, it is an admin overheard that can now be avoided.

Clean Up

In this job I run two steps once the pipeline completes;

  1. Remove temporary storage account containing DSC config files
  2. Remove host pool registration token I generated previously

Scaling

Now that we have deployed a WVD host pool, we now have a bunch of VMs to manage, which can become cumbersome and an admin overhead, especially if we need to scale up those VMs.

One of the best reasons for moving to a pipeline deployment for WVD host pools, is that we can scale up the VMs at the click of a button!

So how do we do it? Easy by simply updating the value of a variable to the number of VMs we require.

Then we simply execute our pipeline again and it will scale accordingly.

An example of the ARM template and pipeline to automate the host pool deployment can be found here.

Enjoy!

[mailpoet_form id="1"]

Other Recent Blogs

Microsoft Teams IP Phones and Intune Enrollment

Microsoft Teams provides a growing portfolio of devices that can be used as desk and conference room phones. These IP phones run on Android 8.x or 9.x and are required to be enrolled in Intune. By default, these devices are enrolled as personal devices, which is not ideal as users should not be able to enrol their own personal Android devices.

Read More »

Level 9, 360 Collins Street, 
Melbourne VIC 3000

Level 2, 24 Campbell St,
Sydney NSW 2000

200 Adelaide St,
Brisbane QLD 4000

191 St Georges Terrace
Perth WA 6000

Level 10, 41 Shortland Street
Auckland

Part of

Arinco trades as Arinco (VIC) Pty Ltd and Arinco (NSW) Pty Ltd. © 2023 All Rights Reserved Arinco™ | Privacy Policy | Sustainability and Our Community
Arinco acknowledges the Traditional Owners of the land on which our offices are situated, and pay our respects to their Elders past, present and emerging.

Get started on the right path to cloud success today. Our Crew are standing by to answer your questions and get you up and running.