Windows Virtual Desktop "Spring Update" enters general availability and gets a name change
On the 27th of July 2020 a new set of capabilities of Windows
Virtual Desktop (WVD) entered general availability.
This means anyone can go to the Azure Portal and deploy production Windows Virtual Desktop and deliver Virtual Desktops from the Cloud.
This set of new features and capabilities during the public preview were referred to as the “Spring 2020 Update”. As part of this update this set of capabilities is now referred to as just “Windows Virtual Desktop”, whilst the original version, that was known as “Fall 2019 Release” is now referred to as “Windows Virtual Desktop Classic”.
The rest of this article discusses the new features and capabilities in this new update, as well as changes and other items you need to consider when deploying Windows Virtual Desktop.
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 this 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.
Windows Virtual Desktop is now delivered via a new Azure Resource Provider called, “Microsoft.DesktopVirtualization”
WVD becoming an ARM service has a number of benefits all of its own summarised below:
In Windows Virtual Desktop Classic, 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 Windows Virtual Desktop Classic 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 to apply or deny administrative access to an Azure object. It is worth noting that this RBAC process is here also 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. In Windows Virtual Desktop Classic the options to manage a WVD tenant were, PowerShell or a simple Management App Service Web App, or a third party tool. WVD can now be managed fully through the WVD Hub within the Azure portal like any other service, more info below.
Dedicated Scale out capability
In Windows Virtual Desktop Classic 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 this release there is a specific option to scale out your host pool - no need to re-run anything, and you just specify how many VM's you want to add, more info below.
The Host Pool deployment now is fully integrated with Azure Shared Image Gallery (SIG). 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.
Consent for consuming Azure Active Directory
The very first step in creating a WVD Classic 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 this 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 https://rdweb.wvd.microsoft.com/arm/webclient/index.htmlThere is also a Microsoft short link of: aka.ms/wvdarmweb
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
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
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 this specific session host:
In Windows Virtual Desktop Classic 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.
For further information review this article: Set up the PowerShell module for Windows Virtual Desktop.
You can also see a list of available commands at the AzWvd PowerShell reference
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 Classic model and the ARM model, is as follows:
o 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.
o The WVD Classic Tenant was effectively the top level of WVD administration, this translates to a WVD Workspace in the ARM model.
o Host Pools, Session Hosts and AppGroups are largely the same and provide the same capability. However, their relationship is displayed in a different manner.
o 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:
o A host pool contains Session Hosts (VM's)
o Application groups contain individual Remote Applications or the Full Desktop.
o Users are assigned to Applications Groups
o Applications groups are added to a Host Pool
o Workspace's contain Application groups
o Users interact with Workspaces via the WVD Clients.
· Deployment: There are some dependencies to be aware of when creating the above objects.
o 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.
o 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.
o When creating a Workspace nothing is required to be assigned. You can create an empty Workspace and then add Application Groups later.
· Migration. This update will not display non-ARM Tenants, there will be a migration PowerShell capability that will enable the migration of the existing WVD objects into the ARM model.
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 is not 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.
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.
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.
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
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.
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: 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
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.
Changing the name of an Application Group
To change the name of the icons that appear in the WVD clients is now very simple. Within the Azure portal go to Application Groups, then select your Application Group you want to rename, in the Settings section click on Properties, and in the resulting screen on the right hand side change the text in Friendly name:
Scaling out a host pool
Prior to this release 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 this release 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 clickin on the Add button or via Powershell:
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.
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.
Go to the Application Group this time click on Access Control (IAM) and then add a new Role Assignment.
Just click on Diagnostics settings on any object:
Then choose what you want to log and where you want it to be stored.