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.
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. 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.
- 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.
Creating the host pool
If you have deployed a host pool prior to the Spring Update you will recognize 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.
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 published 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 at this point.
- So to assign users or group go to the host pool and then go to "Assignments" then click on Add and you can select a user or group using the standard AAD picker:
Creating the 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.
- 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: The Start menu and 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 as it requires 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. Applications should now be 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 the 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. 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.
- Navigate to the Host pool and go to the Session Hosts section and select the Add button located at the top.
- Click on Add and you are taken to the specific Session Host addition screen:
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:
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 -4.
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.
