Windows Virtual Desktop Spring Update enters Public Preview

On the 30th of April the Spring Update of Windows Virtual Desktop (WVD) entered Public Preview.

This means anyone can go to the Azure Portal and deploy a WVD Workspace and test the new capability. This article discusses the new updates and capabilities in this new update, as well as changes and other items you need to consider when deploying Spring Update WVD deployments.

"Spring Update"

First thing - the name, "Spring Update". WVD is now a first class Azure service (more on that below). Azure does not have versions. It is a platform that gets constant updates continually dropped in. This is the same with WVD. As such this is the set of updates being applied in the Spring. WVD receives many continuous updates, however major changes such as this shift to ARM are bundled into a larger periodical update. Expect future continuous updates to be dropped into platform in the future in a similar manner, with some larger updates getting some kind of seasonal naming.

WVD is now integrated with Azure Resource Manager (ARM)

Up to this point WVD has not been an Azure Resource Manager service. But rather the WVD objects have all existed within a separate database. With the Spring Update all WVD objects now are ARM resources in their own right. Azure Resource Manager is the service that sits between the user and the underlying Azure Fabric and is responsible for the provisioning and management of all Azure services. This is achieved by "Resource Providers". Each Azure service has a resource provider i.e. Compute Resource Provider, that ARM can interact with to construct a Virtual Machine for example. More information on ARM is here.

WVD becoming an ARM service has a number of benefits all of its own summarised below:

Azure AD Groups
Up until the Spring Update it was only possible to publish RemoteApps and Desktops to individual users. Now in ARM you can publish these to Azure AD Groups, which is a significant improvement and time saver in its own right.

Azure RBAC for access control

Up until the Spring Update there were four RDS specific admin roles, that can be applied against the tenant or host pools. This has now been moved into native Azure Role Based Access Control. This can be applied at every single WVD ARM object enabling you to have a full rich delegation model. In addition RBAC is also used for user assignment. If you have used Azure RBAC before you will have recognised this as a way to apply or deny administrative access to an Azure object. It's worth noting that this RBAC process is here being used to provide end user access to the Application Groups in question. More info below.

Azure Portal Integration

This is a big one for most customers. Prior to the Spring Update the options to manage a WVD tenant was, PowerShell or a simple Management App Service Web App, or a third party tool. The Azure portal was shown a long time back by Scott Manchester but this now goes live, more info below.

Dedicated Scale out capability
Prior to the spring update if you wanted to scale out a host pool you would run the Azure Marketplace deployment or the Github template a second time and reference the existing Resource Group and Host pool. You would specify the number of VM's you wanted to end up in the host pool, i.e. 10. If your host pool had five VM's it will deploy five VM's to make up the difference.
Now with Spring Update there is a specific option to scale out your host pool - no need to rerun anything, and you just specify how many VM's you want to add, more info below.

Shared Image Gallery
The Host Pool deployment now is fully integrated with Azure Shared Image Gallery SIG is a separate Azure service for the storage of VM image definitions, that includes versioning, which opens the door for monthly (or any cadence) updates to your image. The image has a property called "latest" that allows you to just reference the image definition every time and SIG will supply the latest image version every time seamlessly. Hence you can automate the session host pool deployment to always use your latest build which includes the latest patches, or application updates etc. It also manages the replication of the images to any Azure region around the globe, so that you don't have to, as well as the number of replica's which is important if you require a large number of deployments. The more replica's you have the higher the throughput. SIG is integrated into the Host pool creation process, as well as the expansion process.

WVD Monitoring
Again consumption of monitoring information was via either PowerShell or another Diagnostics App Service Web App. This has now been moved into Log Analytics within the Azure portal natively. Each WVD ARM object can independently be connected to the same or a different Log Analytics Workspace form where you can run Kusto queries or you can integrate with PowerBI to create visual reports

Consent for consuming Azure Active Directory

The very first step in creating a WVD tenant was to consent for the WVD service to use your specific AAD tenant. This was because the WVD service was not a first class Azure citizen. Now that it is, there is no longer a requirement for this consent to happen. However, note that with the consent page you could specify exactly what AAD tenant you wanted to use for user authentication into the WVD service i.e. it could be separate to the AAD tenant that your Azure subscription that you deploy the WVD session hosts into is itself linked to. Now with ARM the AAD tenant that your Azure subscription is the same AAD tenant used to authenticate your users to WVD, as well as provide RBAC controls for your admin users. Hence your selection of an appropriate Azure subscription is more critical as you have slightly less flexibility than before.

Service meta-data storage location

The meta-data, i.e. the data about your deployment or all of the configuration of your overall deployment used to be only stored in the US. Starting with the Spring Update you will be able to select alternative locations staring with additional US regions, then the European geography, and additional locations will also become available over time. This is great for organisations with data sovereignty requirements.

Access to the new ARM WVD objects uses new URL’s.

If you are using the HTML client then the new full URL is is also a Microsoft short link of:

If you would like to use a more corporate like URL to access this rather than the above URL’s there are a couple of native Azure services that you can use to perform a redirect.

The first is using a Function App, review this article: Create a corporate URL for the Windows Virtual Desktop Website, Part 1 Azure Function App
The second is to use Azure Front Door, review this article: Create a corporate URL for the Windows Virtual Desktop Website, Part 2 Azure Front Door

When connecting via the Windows client you either need to Subscribe using your email address or using this feed url:

To set up Email discovery follow this guide from my colleague Jenzus Hsu: Configure Email Discovery to subscribe to your Windows Virtual Desktop feed

Personal Host pool direct user to session host assignment

It is now possible to assign a session host VM directly to an individual AAD user account. The process is twofold. The first step is the add the user to the Application Group for the desktop and then secondly do the direct assignment. The easiest way to do this is go to the Host pool, click on Application groups:

Click on your Desktop Application Group:

Click on Assignments:


Click on Add:

Now add the users that you would later like to add as a direct assignment. It is much easier to add a user group that contains all your users that you would like to assign directly in the next step. At this point adding the user group just means you can add users from just that group directly as direct assignments. 

Once your group is added, go back and in Manage click on Session hosts:

For the Session hosts that are not already assigned you will see an "Assign" link. Click on Assign:

Now you will see the list of users that have been provided access to the Desktop Application Group. This list of users is not the full AAD user list, but rather just the users in the specific user group you added to the Application group above.


Now select a user account and that user is then directly assigned to his specific session host:

PowerShell support
Prior to the Spring Update there was a RDS specific PowerShell module. This has now been replaced with WVD support being integrated with existing Az module: AzWvd. This is supported in PowerShell Core which runs on .NET Core. E.g. Get-AzWvdWorkspace.
To install just run: Install-Module Az.DesktopVirtualization, and then run: Get-Command -Module Az.DesktopVirtualization to get a list of available commands.

Final consequence of the WVD objects moving to ARM is that they inherit a largely flat hierarchy rather than the top down hierarchy. This is illustrated here:

Some things that need to be considered as part of this change to the ARM object model are:

  • All native WVD objects are fully independent ARM objects. Each will have its one Azure region location, and they can be placed anywhere. They all need to reside within a Resource Group and can be any resource group. However for them to be associated together i.e. having an App Group associated with your Workspace they need to be within the same location (Azure Region). The one exception is the Session Host object. This object is a representation of an Azure Virtual Machine and this can be in any location.
  • The relationship between the old model and the ARM model, is as follows:
    • Most people will have never seen the Tenant Group. The vast majority of customer tenants get automatically deployed into the aptly named "Default Tenant Group". For partners and service providers managing many customer Azure Subscriptions or specifically WVD Workspaces this can be managed by Azure Lighthouse, which is an Azure service that allows them to manage multiple Azure services across multiple customers and tenants.
    • The WVD Tenant was effectively the top level of WVD administration, this directly translates to a WVD Workspace in the ARM model.
    • Host Pools, Session Hosts and AppGroups are largely the same and provide the same capability. However their relationship is displayed in a different manner.
    • To publish applications or desktops to users, they need to be assigned to an "App Group" which in turn needs to be registered to a Workspace. The App Group can be assigned to any Workspace (within the same region), and you can have multiple Workspaces. If the App Group is not registered to a Workspace the applications will not be visible in any of the clients.
  • Whilst the ARM object hierarchy is largely flat there are still dependencies between the objects. Starting from the bottom up:
    • A host pool contains Session Hosts (VM's)
    • Application groups contain individual Remote Applications or the Full Desktop.
    • Users are assigned to Applications Groups
    • Applications groups are added to a Host Pool
    • Workspace's contain Application groups
    • Users interact with Workspaces via the WVD Clients.
  • Deployment: There are some dependencies to be aware of when creating the above objects
    • When creating a Host pool you can either allow it to create sessions hosts, or not. If you select No you then need to add them manually later. Also you can optionally choose to register the Desktop Application group that gets created by the deployment to a Workspace.
    • When creating an Application Group, a Host pool is the only object required. Actual applications and users can be added now or you can say No and add later.
    • When creating a Workspace nothing is required to be assigned. You can create an empty Workspace and then add Application Groups later.
  • Migration. The Spring Update will not display non-ARM Tenants, there will be a migration PowerShell capabilty that will enable the migration of the existing WVD objects into the ARM model.
Azure Portal

This is the most visual of updates and what most customers and partners ask me about. So let's take a look at the new user experience, and create all of the WVD ARM objects.

As WVD is now an ARM object you need to register the Windows Virtual Desktop ARM Resource Provider (if it isn't already). This enables you to interact with the service that orchestrates WVD within the ARM service.

So to start, in your subscription go to the Subscription blade:

Once in here on the left in the Settings section select Resource Providers:

In the search bar, type "desktop" and it will show the "Microsoft.DesktopVirtualization" resource provider. This is the WVD ARM Resource Provider.

If this provider is not already listed as Registered then, click on it and then select Register.

Once registered it will appear alongside all of the other registered resource providers.

Now you can interact with WVD from the Azure portal.

Within the Azure portal search for "Windows Virtual Desktop" which will then open and look like below. This is the WVD Hub.

Before we create anything, I have already created a Workspace, Host Pool and Application Groups. It's important to see that when you create hew Host pools and Application Groups you can register them with existing objects, or choose not to.

This is the Host Pool View:

This is the Application Groups View:

This is the Workspaces View:

Just to demonstrate that all of these ARM objects also reside within a Resource Group, in my case one single Resource Group, but you can place them in any Resource Group.

If you go back to the Overview tab the UI suggests creating a host pool first. However you could create a Workspace first if you wanted to if you wanted to follow the previous top down hierarchy.

Click on Create host pool.
If you have deployed a host pool prior to the Spring Update you will recognise most of the questions that need to be answered as well as the format.

On the basics tab the only change is that if you select the "Personal" Host pool type you can select the Direct Assignment type, this was only possible via PowerShell previously

On the VM details you now have the option not to add virtual machines. This is if you already have session host VM's that you are going to join to this host pool, or you will create some manually later.

If you select yes it will show the standard questions that needed to be completed for new VM's.

Next is the Workspace Tab.
Again you have two options here. In Register desktop app group, if you select No it does just that. However if you select yes you can register the default Desktop Application Group, which is the default group that publishes a full desktop, either to an existing Workspace or you can create a new one here.

In my case I am adding it to my existing Workspace.

You can then optionally add Tags, then Review and Create

This will now create Session Hosts, do the AD Domain Join, install the WVD agents create the new host pool, add these session host VM's to this new host pool, create the default Desktop Application Group which is named "HostPoolName"-DAG. This publishes the desktop, although it doesn't publish to any users as it would previously.

So to assign users or groups go to the host pool and then go to the Application Group and "Assignments" then click on Add and you can select a user or group using the standard AAD picker:

Create an Application Group.
So we have a new host pool with a Desktop Application Group published to some users, lets now create a group to present actual applications directly - what's known as a RemoteApp Group. To do this go to the Application groups part of the WVD Hub, and click on Add

Select a Resource Group, then select your Host pool, and then in Application group type select RemoteApp and give this group of applications a name.

Click on Next: Assignments:

In here you can optionally add users or groups to the Application Group. If you don't add them now you will have to assign this Application Group to users later in order for them to see them.

Click on + Add Azure AD users or users groups and you will see the standard AAD user picker menu.

Choose some users or groups to publish these applications to.

Click on Next: Applications

This is where we select applications to be added to this Application Group.
Out of the box there are two methods to find applications. 
1. The Start menu
2. Finding the exe file in the file system aka File Path 

Note at least one VM in the Host Pool needs to be powered on and accessible for this section to work.
It needs to talk to a VM to grab the icons from the application selected.

Click on + Add applications and select Start menu in the Application Source drop down.
Then find an application you want to publish.

Click on Save

Click on + Add applications again and this time select File Path in the Application Source Drop down.

Add an application using its file path.

Click on Save.

You should now have some applications added to the Application Group

Click on Next: Workspace

This is where we register this application group with a Workspace. This is optional. If you say No, you will need to later complete this assignment. Also No allows you to create Application groups prior to Workspaces and later do the registration. If you don't have a Workspace select No and we can create one later.

I already have a Workspace so I select Yes.

In my instance I already have the Desktop Application Group from this same host pool registered to the "Tomboy WVD Workspace" hence it is forcing the registration of this application group in the same host pool to this same Workspace

If that Desktop Application Group didn't exist or was not linked to this or any Workspace the Register application group would be active and allow me to select the Workspace that I wanted:

Click on Next: Tags - where you can add any Tags you want.

Click on Next: Review + Create >

Click on Create.

This will deploy Your Application Group and Register it to your Workspace.

Create a Workspace

The third piece of the puzzle is to have a Workspace. This translates to a tenant in the previous model. You may well want to create this object first (at least that's how I have done this)

Click on Workspaces. Then Click on + Add

Select your Resource Group and enter the naming details for your Workspace and include your location.

Click on Next: Application Groups

If you have any Application Groups that are not already registered with another Workspace, this is where you can register them to this Workspace.

Click on + Register application groups, and select the Application group you want to be associated with this Workspace

Click on Next: Tags and add any of your tags.

Click on  Next: Review + create >

Click on Create

This will now create you a Workspace.

So what does all of this look like?

So if you open any of the WVD clients and log in as a user who had been assigned to the application group you should now see your workspace and those applications.

Note that throughout all of this the Host pool, Application Group and Workspace all need to be in the same Azure region to be associated with each other.

Scaling out a host pool.

Prior to the spring update if you wanted to scale out a host pool you would run the Azure Marketplace deployment or the Github template a second time and reference the existing Resource Group and Host pool. You would specify the number of VM's you wanted to end up in the host pool, i.e. 10. If your host pool had five VM's it will deploy five VM's to make up the difference.

Now with Spring Update there is a specific option to scale out your host pool - no need to rerun anything.

If you go to the Host pool and go to the Session Hosts section, there is an Add button at the top.
Click on Add and you are taken to the specific Session Host addition screen.
Note you will likely need to create a new Registration Token as the previous one will have expired.
You can do this in the portal after clicking on the Add button or via PowerShell:

New-AzWvdRegistrationInfo -ResourceGroupName "YourRG" -HostPoolName "YourHP" -ExpirationTime $((get-date).ToUniversalTime().AddHours(2).ToString('yyyy-MM-ddTHH:mm:ss.fffffffZ'))

On the Virtual Machines section, you just need to complete all the standard answers as before. The only difference is the Number of VMs. In here enter the number of new VM's you want to have deployed and added to this Host Pool.
Also the host name can not be changed, and the prefix is hardcoded to the pre-existing prefix. In my example it will add four session hosts, and as I have one existing VM called test2-0 it will create test2-1 through to test2-4.

RBAC for user assignment

Not only is RBAC used to provide the ARM object permissioning and delegation but it is also the capability that provides end user access. 
To see the standard RBAC implementation go to Application Groups > "Your Application group" > Assignments. Here you can see and modify, which users and or AAD groups have access to this Application group.
If you then go to Access Control (IAM) > Role assignments. Then look for the "Desktop Virtualisation Role" you will see the users who have already been provided access by the process above.
Now click on "Desktop Virtualization User", this will take you through to the ARM Resource Provider - "Microsoft.Desktop.Virtualization" that is enabling this access. Expand this tree to see the full list of permissions:

Note the user permissioning appears in the Resource Type of Data rather than Management which would be used for typical admin access enablement.

This provides two ways to add AAD users and groups to an Application Group. It can be done on the standard AAD user picker as per the Create and Application Group section above. 
Or you can add the user or group directly using RBAC, utilising the new "Desktop Virtualization User" RBAC role.

Go to the Application Group this time click on Access Control (IAM) and then add a new Role Assignment.

Click on Add > New Role Assignment. In the Role dropdown box select Desktop Virtualization User and then select your User or Group as per normal.

This is the RBAC role that provides the users with the permissions required to launch the Application Group.

RDP Settings

Another nice feature is the ability to set RDP Custom properties for each host pool directly in Azure Portal. This was previously only possible via PowerShell. Go to the Host pool and Properties, the RDP Settings. Here you enable any of the options you need.

WVD Monitoring

Each WVD ARM can be directly linked to either Log Analytics, Event Hub, or to Azure Storage.
Just click on Diagnostics settings on any object:

Then choose what you want to log and where you want it to be stored.

You can add all your WVD objects to send their logs to this workspace, as well as adding in the individual session host VM's.

Once logging data is stored in Log Analytics you will be able to run queries against that data and use either Log Analytics Workbooks to visualise the data, or use PowerBI to use its enhanced visualisations capabilities. For further information on this take a look at this article.


  1. What if .. if I all ready have an vwd solution up and running, how can i benefit from Windows Virtual Desktop Spring Update.. Can i "Import" it .. or do I need to create it again using this new feature. ?

    Thanks for highlighting ..

    1. Its not backwards compatible. However shortly there will be some new commands made available in PowerShell to do a migration from existing to this new obect model in ARM. However you can move session hosts by uninstalling the WVD agent and reinstalling with a new registration key from a new host pool created in the Azure portal, save deploying new VM's. Or wait for the pwsh update.


Post a Comment

Popular posts from this blog

Reassign a WVD Personal Session Host

AVD and Azure Active Directory Domain Join public preview

How to deploy a Windows Virtual Desktop host pool using Infrastructure as code from Azure DevOps