Thursday, April 30, 2020

The next big innovation in Windows Virtual Desktop is here!

Since its inception Windows Virtual Desktop (WVD) has been a big hit. Being able to publish Applications and Desktops from the Azure Cloud without having to worry about the backplane infrastructure was spot on! I have seen a huge demand for the service especially after General Availability and have already helped at least a dozen of organizations with their architecture and implementation. During Microsoft Ignite Orland 2019 I wrote an article covering all the news and announcements around WVD. That article ended with a quote by Scott Manchester



“This is just the beginning of #WVDIgnite”.
Although Microsoft Ignite 2019 already a long time ago, it really was just the beginning. Many of the features and capabilities announced there already made it into product. And today marks the beginning of a new big step:
*** Public Preview of WVD fully managed via Azure Portal and Azure Resource Manager! ***
In a nutshell this brings us an integrated Azure GUI, AZ PowerShell and Role Based Access Control to deploy, configure, troubleshoot, and monitor Windows Virtual Desktop Resources! I’ve had the privilege to test drive this new release of WVD in a private preview version and this article covers the top 10 things you need to know including my experiences on this big step forward!
1. Consent for Azure AD
If you have dealt with deploying the existing WVD Service, you probably know that you had to jump through a lot of different hoops to fully install and configure the service. The first thing you had to do is providing consent for the WVD Service to read Azure AD. With WVD Spring Update this is not needed anymore. WVD has now become a 1st party application in Azure and no explicit consent (as shown below) is needed anymore!



2. Azure Role Based Access Control (RBAC)
Existing WVD comes with custom RBAC roles. Permissions for Admin accounts and Service Principal Accounts to manage a WVD Tenant need to be setup using PowerShell as per the example shown below.
New-RdsRoleAssignment -RoleDefinitionName “RDS Owner” -SignInName “Freek@wvd.ninja” -TenantGroupName $TenantGroupName -TenantName $tenantname



Also, permissions to be able to create a WVD Tenant need to be explicitly configured on the WVD Enterprise Application.
WVD Spring Update comes with Azure Role Based Access Control (RBAC) which means that it follows the standard Azure RBAC model and explicit TenantCreator permissions like shown above do not have the be configured anymore. You basically create a new App Registration and provide the permissions on Azure Resource Groups as needed or provide the same permissions to Admin Accounts.



3. Integration in AZ PowerShell
To be able to manage and maintain Existing WVD with PowerShell, a separate PowerShell module is needed which must be installed and imported as shown below.



Although this worked fine and allowed us automate management tasks, WVD Spring Update provides us with an integrated module in Az PowerShell as shown below!



This had to be done to make WVD a full 1st application solution in Azure. It is relatively easy to start using the new Cmdlets. You can use the following conversion for most of the existing CmdLets.
[Verdb]-Rds[Noun] now becomes [Verb]-AzWvd[Noun]
Do note that Set-* Cmdlets are replaced by Update-*, and for every CmdLet you must provide the SubscriptionID. I will explain why that further down. The screenshot below shows all CmdLets (based on version 0.0.5).



4. Management GUI integration in Azure Portal
This is without a doubt the biggest visible change. With existing WVD, most of the management is performed using PowerShell. Personally, I’m a big fan of PowerShell as it allows for fast, easy and automated deployment and maintenance. Sometimes however its very helpful to get a visualization of the WVD configuration, especially when you’re dealing with large deployments containing dozens of host pools and App Groups. There is a separate management GUI available for existing WVD, but honestly it was very limited. It’s really great that the integrated Management UI in the Azure Portal is now here! It allows us to create, manage and maintain Workspaces, Host pools, App Groups and WVD Hosts directly from the Azure Portal.



Example of management of a WVD Workspace, previously known as WVD Tenant (we’ll discuss that name change later on in this article).



An example of Management of a WVD Hostpool. As you can see I have a clear overview of published applications and desktops and I can also (re)create Registration Keys directly from this portal as well.



Here is an example of management of a WVD AppGroup including the publishing of applications and the assignment of users (and groups!).



What’s important to realize is with WVD Current Release, all WVD Backplane components were not visible in the Azure Portal. With WVD Spring Update now becoming a 1st party application in Azure (Resource Manager), they are visible and Azure RBAC defines who is allows to manage them. As shown below, Workspaces, Host Pools and Application Groups are visible as Azure Objects in my Azure Subscription.



All WVD Spring Update Backplane components can be managed similar to any other Azure Object in the Azure Portal.



And since they are, you can now also use JSON Template to automate the creation of WVD Backplane components. As per example, below if the JSON code to create a new WVD Workspace. Similarly, I can create JSON Template to create Host Pools and App Groups as well.



Starting from WVD Spring Update , we can now also store the Meta Information to an Azure Region of our choice.



5. Assigning Azure AD Groups to App Groups!
This feature is part of the overall move to Azure Portal, but important enough to mention here separately. With the current release of WVD, the way you provide access to a Published Desktop or (set of) published applications is by assigning an Azure AD user to a WVD App Group. This means you must add each individual AD User to a WVD AppGroup. If you have a handful of users and only a few App Groups that is not really an issue. It becomes a challenge however when you have hundreds or thousands of users and dozens of App Groups. In that case adding AD Users to an App Group cannot be performed manually anymore. Scripts or Azure Jobs that sync AD or AAD members towards App Groups as shown below become mandatory.



With WVD Spring Update we can now directly add Azure AD Groups to WVD App Groups! This makes management of WVD a lot easier and was a big requested feature!



6. Name Change: WVD Tenant becomes WVD Workspace
Starting from WVD Spring Update , the term Tenant no longer exists. It seems like a simple change, but you would not believe how questions and discussions it raised when talking to customers and presenting on this topic at conferences! Many confused the term Tenant with an Azure Tenant. The new WVD Workspace makes much more sense! Obviously, corresponding PowerShell Cmdlets have changes accordingly as well. So e.g. New-RdsTenant became New-AzWvdWorkspace. And of course the Azure Portal also reflects this change as shown below.



7. WVD Components hierarchy
As part of WVD Spring Update , the hierarchy of WVD backplane Components also changed. With the current release of WVD, the hierarchy of the components looked like below. The diagram shown the dependencies. This means an AppGroup is dependent on a Hostpool and a Hostpool is dependent on a Tenant.



With WVD Spring Update the Hierarchy needed to change in order to match it the way hierarchy is designed in Azure Resource Manager. The new object model looks like below.



Basically, there is no longer a hierarchy model, you create objects and associate them to other objects. A couple of things have changed:
  1. All resources (Workspace, Host pool, App Group) will have a Resource Group and Location associated with it.
  2. Workspaces and Host pools do not have a dependency anymore, meaning you can create a Host pool without assigning it to a workspace yet.
  3. In order to make Applications and Desktops, that are published inside an App Group, visible a to a user you need to register an App Group against a Workspace.
  4. To be able to associate WVD objects they need to exist in the same location (region)
  5. WVD Hosts can be created anywhere, they do not have to be created in the location where other resources (Workspace, Host pool, App Groups) are located
  6. With WVD today, when you create a new Host Pool a default Desktop App Group is created which was called “Desktop Application Group”. With WVD Spring Update this group is now named similar as Host Pool name followed by the postfix “-DAG”
8. WVD Service Tags
The WVD Agent on a host needs a couple of open ports and locations to be able to successfully communicate with the WVD Backplane. These addresses and ports are outlined below.



Although you can use a Network Security Group (NSG) to open these ports, there now is an easier way. You can now use the Service Tag called Windows Virtual Desktop to open all necessary ports at once as shown below.



9. WVD Clients during preview
Because of the changes within the WVD Spring Update , during the Public Preview a limited number of WVD Client can be used. There are 2 options to test the WVD Spring Update .
Option 1. The existing WVD Web Client can be used by browsing to rdweb.wvd.microsoft.com/webclient. As you can see below, I have access to both WVD Current as well as WVD Spring Update resources from within the same WVD Web Client. This makes migrating to WVD Spring Update fairly easy. If you want to access only the Spring Update resources you can also browse to wvd.microsoft.com/arm/webclient. Accessing the Published Desktops and Apps is identical to the way it works in the current version of WVD.



The WVD Spring Update published Applications and Desktops shown above are visible because my test user is a member of corresponding App Groups. What is also great about the Azure Portal management for WVD is that I can search for a user and get back the App Groups it is assigned to in one single overview!



Additionally, the Sessions tab is available where I can easily see all active sessions of a single user across multiple Workspaces and Host Pools. I can also interact with the user session by sending messages or logging users off.



If I need a per WVD Host view I can do so by opening a WVD Host from the Host Pool object. I can also log off all active users with a single action here and put a server in and out of drain mode.



Option 2. The WVD Windows client (aka.ms/wvdclient) can also be used during the Public Preview. In order to see resources published from a WVD Spring Update deployment, 2 requirements need to be in place. First of all, the version of the WVD Client needs to be version 1.2.673+. Second, it needs to be enabled for Preview. In order to do so, apply the following change in the local registry of the client.



After that you can use the same WVD Client to access both WVD Current version as well as WVD Spring Update resources. Again, working with these published Apps and Desktops from the end user perspective has not changed.



For the macOS client, starting with version 10.3.8, the macOS client can be used to test ARM resources. When prompted for the URL, enter: https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery
For the iOS client, starting with version 10.0.6, the iOS client can be used to test ARM resources. When prompted for the URL, enter: https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery
For the Android client, starting with version 10.0.5.1045, the Android client can be used to test ARM resources.When prompted for the URL, enter: https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery
10. Milestones and Road Maps
So, with WVD Spring Update now being in Public Preview, what does the roadmap look like and when can we expect General Availability? The diagram below shows what is planned for this year. GA for US and EU Regions is expected around the summer and additional Azure Regions will be added in the second half of this year! Note that this does not have to stop you if your WVD Hosts are located outside of these regions. It only means the WVD Meta Information cannot be stored yet outside of the US and EU Regions.



Wondering about how to migrate existing WVD workloads to WVD Spring Update ? Stay tuned because I’m covering that in my next article!
Finally, as always, if you have questions feel free to reach out to me via e-mail, twitter or Linked-In!
Posted by at No comments:
Subscribe to: Posts (Atom)