After releasing the Spring Update 2020 for Windows Virtual Desktop on Azure, a lot of new cool features have been added to the service, especially in terms of management, because it can now be modified from via ARM.

A few hours later, I had a look at the documentation and saw that some points, which were existing before, simply disappeared. The link to the official Microsoft documentation can be found here: https://docs.microsoft.com/de-de/azure/virtual-desktop/overview

One of those examples was the page about Auto Scaling. Dean Cefola (AzureAcademy) did a great video on how to setup autoscaling for the “old” version of Windows Virtual Desktop, which I don´t want to hide from you

This video can be found here:

But how do you proceed if you want to use the ARM based deployment of Windows Virtual Desktop and you see that your existing demo environment, based on the PowerShell / manual deployment isn´t represented from within teh WVD Portal on Azure?

For this reason I have a solution for you based on the following technologies:

• Windows Virtual Desktop (For sure)
• Virtual Machine Scale Sets

For the reason of complexity, I want to split the article into two parts to keep focused on the current objective. But lets start with step number 1!

Content

• Step 1: Prerequisites: Windows Virtual Desktop
• Step 2: Virtual Machine Image
• Step 3: Virtual Machine scale set configuration

Step 1: The prerequisites: Windows Virtual Desktop

To get started, we should create ourselves a work environment on Windows Virtual Desktop to be able to adapt our image to join the HostPool automatically on creation.

I´ve logged into the Azure Portal and searched for Windows Virtual Desktop in the search bar.

After I accessed the service, I needed to create a new HostPool for our autoscaling setup. To do so, we click on “Host Pool” in the left navigation bar and click on add to start the creation of a new Host Pool.

Here you can see my configuration steps:

In this example I´ve specified my favorite Resource Group, combined with the information where to store the MetaData, as well as the Host pool name and the type. In this automation tutorial, we select a “Pooled” Host Pool type and select our maximum session limit and the loadbalancing algorithm, which is Breadth-first in my case.

On the next page, we have the possibility to add virtual machines to our new Host Pool, this is NOT what we wanted to do right now, so we leave the option to “No” and continue.

Also the App Group for our Workspace will be kept empty and we just add a few tags and go to Review+Create.

Once the validation has passed, we´re about to create our new HostPool.

As a next step, we need to retrieve the Registration key for our future VM´s to automatically join the HostPool. To retrieve this key, we need to go back to our Windows Virtual Desktop dashboard and select Host Pools from the left navigation bar.

Now we just need to select our recently created Host Pool, which is KCLD-WVD-HP01-02.

From within this menu, we can click on “Registration Key” from the top menu bar to retrieve the key to be used on our virtual machine image to join automatically to this Host Pool. Please store this key carefully!

Now, that we have our future Host Pool ready to be used with our new virtual machines, let’s see what the prerequisites for our virtual machine image is!

Step 2: The prerequisites: Virtual Machine Image

For the virtual machine image, I´ve deployed a standard Windows 10 Enterprise Multi-Session, equipted it with the software I need for my end users as well as FSLogix as my profile solution.

Just to review, below you can see my FSLogix configuration from within the Registry Editor:

When our setup is completed so far and we´ve made everything ready for the deployment, we just need to install two additional software packages required to register the auto scaled VMs to the Host Pool directly.

• Windows Virtual Desktop Agent – Link
• Windows Virtual Desktop Agent Bootloader – Link

Attention! If you run the installer for the Windows Virtual Desktop Agent, it will ask you at the very beginning to enter your Registration Key, this is the place, where the copy of the registration key from prerequisite 1 comes in place. Just paste the key into the installer and continue. With the bootloader installer you shouldn´t have any issue or special things to consider during the installation process.

If we´ve also completed this step, we can generalize our image to be used for the automation deployment.

For this reason open the Explorer and navigate to:

C:\Windows\System32\Sysprep

and run the sysprep.exe as an Administrator and select the values I´ve done below.

Once, the virtual machine is shutdown, you need to “Stop and deallocate” the machine from within the Azure Portal to generate the Image. A complete procedure, how to do this can be found in my article about the Golden Image Creation – Part 2 of the series.

I´ve finalized the image creation, which finalizes also our prerequisites for the automation deployment, which will be configured in the following steps.

Step 3: Virtual Machine Scale Sets

Now, this is actually the tasks, where we configure the auto scaling behavior of our Session Hosts in Windows Virtual Desktops. The following steps show you a demonstration environment and I will quickly mention the points I have configured to show you this functionality. If you want to benefit from these features in a production environment, please find the link to the official Microsoft documentation about scale sets including all of their options. https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview

Lets start in Azure, where we´re creating a new resource called “Virtual Machine scale set”. Search for it and click create to continue.

On the first page, we can define the basic parameters for our scale sets, which includes standard parmeters like the Resource Group, Virtual machine scale set name, the region as well as the usage of the image and the image size. As we are using a custom image for our deployment we need to click on “Browse all public and private images” and select in the following pop-up side bar our recently created image, while navigating to my items.

I left the specified size of the virtual machines for demo purposes and configured the other virtual machine settings like mentioned below:

In my case I have a valid Microsoft 365 E5 license which obliges me to use Windows 10 Enterprise to be used like this, if this is also the case for you click on yes, select Windows client and confirm your setting. Hit Next to define the virtual hard disk settings for the machines.

I chose Premium SSD with the default encryption and continued to the networking section.

Over here, I´ve selected the virtual network and the Subnet, where my virtual machines should operate in. When these values fit for you, continue to the next page, which defines the scaling settings.

In my demo case, I start with an initial virtual machine count of 1, so only one machine will be created at the beginning and represents the always available number of virtual machines in my scaling set.

Below, I specified the maximum number of VMs created in my scale set, which represents the count of 4.

Below I´ve defined, when to scale out and create a new machine, this will be done in my case, when a CPU threshold of 75% is reached over 10 minutes – so the scale set will increase the number of VMs by 2.
Attention while configuring the value like this. In some cases 75% over 10 minutes assume a bit to slow depending on your environment and concurrent users, logging into WVD. For this reason I suggest keeping the number of initial instances higher to not block your users from signing in.

Lower on that page we can also collect diagnostic data from our virtual machines and bind them to a Diagnostic logs workspace, like I did in the example above.

Another important point represents the “Scale-in policy”, describing which virtual machine will be removed, while scaling in. In this case we select of course the newest one, because it will not disconnect productive user from their workspace.

Attention! You must pay attention during the configuration of the scale in policy to not disconnect the users while the machine is in a deletion process, for this reason I highly recommend in the scaling settings to lower the scale in threshold and to raise the time before removing the VM.

On the next page, we can configure then our Upgrade Mode, which defines how virtual machines are brought up-to-date with the latest Upgrade model. In my example I choose Automatic.

If you want to know more about the possibilities and what they´re doing, please follow the link to the official Microsoft documentation: https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set

On the next page we can configure an allocation policy. In my case I´ve defined to not scale beyond 100 VM instances and choose the Fixed Spreading algorithm.

If you click next, we´re nearly about to finalize our deployment. We can define our Tags, maybe used for the Cost Center to evaluate the cost on our future scale set and go to the Review+Create summary page.

In this demonstration case, everything was fine, I agree on the points and click create. This process took approximately 15 minutes (but there was only one machine to be created), it can take more depending on your setting.

Once the deployment succeeded, we can have a look back in our Windows Virtual Desktop environment, to see if the Session Host has registered itself.

After a few seconds the Session Host has been successfully recognized from within the portal, but currently nobody can access the resource!
Attention again! Currently the virtual machine is not domain joined, I used a DSC configuration from within my scale set afterwards to join the domain. I will explain this a bit deeper in part 2 of my automation series.

To change that, we need to grant access to our users by selecting the Host Pool, going to Applications Groups and assign a user or security group to that resource.

I´ve chosen the standard Desktop Application Group, entered the user name for my demo environment and saved this. As the last step we need to provision our Desktop Application Group to the workspace created to be able to finally provide access for our end users to the resource.

To do so, we change to the Workspaces configuration from within Windows Virtual Desktop, select an existing workspace or create a new one and add our modified application group, to grant access. The result could look like this:

Conclusion

To be honest, I´m very impressed of the new capabilities Windows Virtual Desktops brings in the Spring Update release, but functionalities like auto scaling, auto-shutdown of the machines are a mandatory selling argument for this product (at least on the Luxembourgish market 😉 ) and for this reason, Microsoft should consider integrating such features into the ARM deployments.

In this part 1 of my article series about automation options in Windows Virtual Desktop I generally want to show you, that an auto scaling is possible with Session Hosts, but there are a few steps to perform additionally to make it a good working solution.

In part 2 of my series I will highlight the following points:

• Desired State Configuration (which tasks can be completed by using DSC in scale sets)
• Auto Start/Shutdown of Session Hosts, what to do and what definetley not!

So stay tuned and healthy,

Cheers,

Patrick