Windows Virtual Desktop Spring Update enters Public Preview

On the 30th of April the Spring Update Release of Windows Virtual Desktop (WVD) entered Public Preview.
 
This means anyone can go to the Azure Portal and deploy an WVD Workspace and test the new capability. This article discusses the new updates and capabilities in this new release, 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 an ARM service
 

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
In WVD there are 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.
 
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 organizations with data sovereignty requirements.
 

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)
• Applications groups contain individual Remote Applications or the Full Desktop.
• Users are assigned to Applications Groups
• Applications groups are added to a Host Pool
• Workspaces 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 release 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.