WVD Spring Release > What’s New?

This post will focus on the changes made to the Windows Virtual Desktop (WVD) service by way of the Spring Release that went into Public Preview on Thursday 30th April 2020.

For ease, I’ll refer to the pre Spring Release WVD as version 1, and post Spring Release WVD as version 2.

Firstly, I’ve been a massive fan of WVD from the early days and was lucky enough to attend the Microsoft Airlift event in Seattle back in late September 2019 in which Microsoft officially announced its general availability – since then I’ve spent a considerable amount of time working with WVD, deploying it not only for internal use but for a number of large organisations, all with global workforces, who were looking to take advantage of its capabilities.

Now, I’m not going to say WVD version 1 was perfect, far from it, however, mindful that it was a first-generation product and Microsoft made it clear that their initial efforts were to build the multi-session capabilities into Windows 10 and additional functionality and supporting services, such as a much-requested native Azure portal-based management interface would follow soon.

Like many others in a similar position, I am extremely grateful to Marcel Meurer for producing his fantastic WVD Admin tool, this has saved me several hundred hours over the past months – to be honest, even with the newly released management interface (which I’ll cover later) I’m going to be hard pushed to not use WVD Admin going forward, it’s truly that good.

I’ve kept an eager-eye on the WVD Roadmap for months now,  hoping that the product team would make the new management UI available sooner rather than later, apologies to the guys at Microsoft who I’ve pestered no-end, especially Jim and Tom 🙂

So on Thursday 30th April Microsoft made the announcement that the Spring Release of WVD had moved out of private, and into public preview!

All I was expecting was the aforementioned new management interface, what we received, however, was essentially an entirely new WVD architecture!

My initial thoughts around the rearchitecting were, why? Why did WVD, a product that was less than 12 months old need such an overhaul? Now having spent a few days digging into version 2 it’s evidently clear, and in hindsight, it’s likely that I’d used WVD version 1 so much I’d become very robotic in the way I managed some of the less than elegant nuances, saying that, I’ve written close to 20 individual PowerShell scripts in that time to address these nuances so that should have given me some food for thought…

Anyway, what’s changed and why is such good news for those deploying, managing and using WVD going forward?

Firstly, WVD is now a first-party Azure service, to those who have deployed version 1 that means no more having to go through the steps of registering the app service in Azure granting consent (twice!) and having to run lines of PowerShell to create a tenant, in-fact Microsoft has done away with the concept of a tenant altogether!

Christian Brinkhoff provided a great diagram, below, showing how the WVD model has evolved in version 2, note the lack of tenant group and tenant.


In version 2 Microsoft has removed the hard-dependency between the host pool and apps or desktop groups, each component of the WVD architecture, that is, the workspace, host pool, app group, in line with Azure Resource Manager (ARM) is now modular and can be linked together to present resources to end-users (and groups, the Spring Release also brought this long-awaited functionality!)

Christian’s latest blog post on the Spring Update is essential reading so please check it out, Freek Berson‘s post on LinkedIn is brilliant too, not to forget Dean Cefola‘s Azure Academy YouTube channel – these guys provide an immense amount of content, information and inspiration for the wider WVD, EUC and Azure tech communities.

In place of the deprecated Tenant is now the Workspace, a Workspace is a collection of application and desktop resources presented to the end-user, in the screenshot below Core Apps, Finance Team and Tech Team are all Workspaces that the test user is assigned to.


Where this differs from version 1 is that in version 2 a single host pool can be associated to an application group and a desktop group at the same time, whereas in version 1 if you wanted to present applications and a desktop to the same user you would have had to deploy two separate host pools and associated virtual machines.

The relationship between components in the version 2 architecture is shown below.


As mentioned previously the Spring Release also brought the ability to use Azure AD groups (sync’d from AD) to assign users to WVD resources.

Users or groups are assigned access to the application or desktop group, those are associated with a hostpool (and underpinning sessions hosts, not shown in the diagram) and it is the hostpool that is assigned to the Workspace.

Even better than that, a single Workspace can be made up of multiple host pools!

Say you create a Workspace for the Graphic Design team at Company X and amongst the standard productivity tools the team use a resource-intensive application, you spin up an F series VM or similar and install the application on it, you want that application presented to the team in the same Workspace as their other apps but you don’t want to pay for all F series VM’s – with WVD version 2 you can spin up a host pool of cheaper general purpose session hosts for hosting MS Office etc and present the collective application stack to the team from a single Workspace, as below.


Note, multiple app groups can also be assigned to a single host pool.

So that concludes this article on the Spring Release of WVD however I’ll share more as I dig further into version 2.

Lastly, for those wondering as I did how to officially migrate your version 1 WVD workloads to WVD version 2, the answer is to sit tight for now, Microsoft will be releasing tooling soon to uplift the non-ARM deployments into ARM and version 2, as per Christiaan’s tweet below.


…that said, using version of WVD Admin it is quick and easy to use existing VM images to deploy into version 2 host pools, just follow this post.

Bulk Updating UPN’s

As part of a recent project I had to migrate 1500 user objects between two AD domains and then sync them with Azure AD – I’ll cover that entire project and its challenges, of which there was a handful in another post.

As part of that migration, I needed to bulk update the UPN’s of the newly created accounts to align with the custom domain name configured in Azure AD, that begs the question why didn’t I just stand up the new AD domain with the appropriate suffix in the first instance, and the honest answer is this project was extremely fast-moving and we had to make decisions on the fly whilst we were working on the strategic architecture, again, this will become clearer when I cover the project in more depth.

Anyway, with 1500 user objects to update I certainly wasn’t doing that manually, I used the below script to target all users in a specific OU and change their UPN.

Note, if you are to use this please ensure you have created the new UPN in AD Domains and Trusts first, details on how to do that here.

Import-Module ActiveDirectory

$oldSuffix = "oldsuffix.local"
$newSuffix = "newsuffix.co.uk"
$ou = "OU=New-Accounts,DC=oldsuffix,DC=local"

Get-ADUser -SearchBase $ou -filter * | ForEach-Object {
$newUpn = $_.UserPrincipalName.Replace($oldSuffix,$newSuffix)
$_ | Set-ADUser -UserPrincipalName $newUpn