Monday, May 25, 2020

Test driving Igel OS with WVD Spring 2020 update!

Igel has released a new (private preview) version of Igel OS which supports Windows Virtual Desktop Spring 2020 update!
This release of Igel OS now supports both the Fall 2019 as well as Spring 2020 Update feeds. The client enumerates both feeds and shows them in one single overview. The screenshot below shows the resources coming from Spring 2020 Update webfeed. Both RemoteApps and Desktops are available coming from 2 different Workspaces.
In this release they also added a new cool feature. The Igel OS WVD client now shows live previews of sessions! The screenshot below shows this functionality. Here we see a live preview of a RemoteApp session as well as two different Full Desktop sessions. This allows me for super fast switching between sessions!
Even more cool, a single right-click on the published Application or Desktop does a instant user logon for that published resource without actually connecting to it in full screen. So I stay within the Igel OS WVD client and with 3 simple right-clicks I can launch resources in the above screenshot and watch the logon sequence of all three. I like it!
I shot a quick video to show this functionality in action. I used a Surface Pro with a Igel UD Pocket (UDP), a super small and portable “thin client” which allows me to USB boot any device or thin client and convert into an Igel OS device. The Igel UDP is so small that I attached a key cord to not loose it :).
And here is the Igel OS WVD spring 2020 Update client in action. It’s a quick video, not focussing on the image quality but purely to show the new functionality.
If you are also interested in test driving the private preview version reach out to Fredrik Brattstig, Technology Evangelist at Igel.

Webinar week: Getting Started with Microsoft Azure!

The webinar “Getting Started with Microsoft Azure” is coming up! This webinar week will take place from 2 to 5 June 2020.

“…Over the course of five days we will deliver virtual sessions on Digital Transformation, Azure Landing Zone and migration to the cloud, Modern Data Warehouse, security and Windows Virtual Desktop. These sessions will be delivered by Microsoft experts in close collaboration with our top partners…”

Wortell joins as one of the partners presenting at two of the Azure Webinars: Secure & Well-managed and Windows Virtual Desktop!

During this webinar, I will represent Wortell and talk about our vision and approach on helping you Jump Start your Windows Virtual Desktop deployment. Sign up!

Getting started with Microsoft Azure: Windows Virtual Desktop

During this Webinar my colleagues Lourens Siderius and Maarten Goet will dive into the Wortell vision on a helping you achieve a secure and well-managed Azure Environment. Sign up!

Getting started with Microsoft Azure: Secure & Well-managed

Check out the full list of topics and sessions that will take place throughout the entire week, a great line up! And also watch the introduction video posted by Guido Kerkhof.

Sign up now, we’re looking forward to seeing you there!


Wednesday, May 20, 2020

New PowerShell script on GitHub to add WVD Hosts to a host pool

  • Check if there is an existing and still valid Registration Token for the Host Pool that was provided, if so grab that one and if not, create a new one.
  • Download and install the WVD Agent providing it the Registration Token.
  • Download and install the WVD Boot Loader
  • Optionally set itself in Drain Mode to not allow new sessions yet
  • Optionally create the Workspace-AppGroup Association
  • If you want to move a WVD Host from one host pool to another without redeploying it.
  • Or, as also outlined in this article, you are manually migrating WVD Hosts from Fall 2019 towards Spring 2020 Update.

Friday, May 15, 2020

Microsoft meets Community: Windows Virtual Desktop, recap, videos and slide decks!


On April 28, the event Microsoft meets Community: Windows Virtual Desktop took place. This was originally planned as an in person event hosting 120 attendees. Due to COVID-19, it unfortunately had to be transformed into a virtual event. It did however, turn into a huge success! With 2236 registrations and approximately 1200 live attendees!
I had the privilege to present the topic "Dealing with application landscapes on WVD, current and future, together with Micha Wets". We had a blast presenting on WVD, MSIX app attach, FSLogix and Azure DevOps CI/CD pipelines!

Today, all content of the event has been published! Videos and slide decks of all sessions are available to everyone!

Watch our session here! and get out slide deck here!
https://youtu.be/Ovmdne4OvY0
For the full set of all videos and slide deck visit the this page:

We want to thank everyone who attended our session.

Tuesday, May 12, 2020

Using WVD to provide secure and easy access to a management server in Azure!

Two weeks ago, on April 30, Windows Virtual Desktop Spring Update 2020 Public Preview was released! A huge jump forward for WVD! If you missed those announcements, check out my two previously published articles:


In this article I want to highlight a different use case, using WVD to provide your (customers) administrators a secure management server accessible from anywhere using any device.
If you are running any resources in Azure, there is a good chance that one of those resources is a Management Server / Jump Host or whatever you want to name it. Such a server is used as central management for administrators to access admin tools like Active Directory Users & Computers, DNS, Group Policy, other MMC Snap ins and any other 3rd party vendor management consoles. It is also often used a single point of entry to RDP “jump” into other servers. Why is this? When organisations move resources to the Public Cloud, in this example Microsoft Azure, the first thing you need in Azure is Networking & Storage. In most cases expanding a current (on premises) Active Directory Domain (ADDS) is the next step to support Domain Services for Azure resources. Or, you might be implementing Azure Active Directory Domain Services (AADDS) or Azure Active Directory only. Having either of these services available in Azure allows you to deploy Domain Joined Application Servers, File Servers, Database Services et cetera. As you move more resources to Azure, the need for a centralized management server grows. In many cases you already have such a management server on premises or at a hosting facility. A couple of questions: How are you allowing access to that management server? Using a VPN? Published by an RDS/Citrix/VMware platform? Is it secured by Conditional Access & MFA? Can administrators access it on any device?
Why not leverage the Windows Virtual Desktop platform in stead?
Use a centralized Management Server / Jump in Azure and publish it to your administrators, applications vendors, external contractors using Windows Virtual Desktop! This allows secure access using any device from any location!
Using an RDS deployment (on premises, hosted or in the Public Cloud) you can of course achieve the same the goal. For example if you have an RDS deployment in your environment that you use to publish applications and desktops to end users, it makes perfect sense of course to re-use that platform for administrators to access a management server. But if you don’t, setting up a full RDS Deployment just for remote management only is not that cost-effective and by default it does have the security needs we require today like for example Conditional Access, enforced MFA et cetera. Sure, you could also just deploy an RD Gateway Server with an NPS Server and MFA Extension. I wrote about this back in 2017 in the article Securing RD Gateway with MFA using the new NPS Extension for Azure MFA! and I have seen a lot of organizations successfully use this approach. Also remember that using RDS requires the purchase of a RDS Client Access License. With WVD, and especially with Spring 2020 release, I believe its time to move on and start leveraging the latest technologies!
Even if you do not use the WVD platform right now, if you have the need for a secure management server in Azure, leveraging WVD makes total sense! And if you do already have WVD for other use cases, re-use it and eat you own dog food!
So, how do we get started? Deploying a WVD Workspace including Host pool and AppGroup for the purpose of publishing a Management Server is similar to deploying WVD for any other purpose. Your deployment options are as follows
  1. Deploying using the Azure Marketplace entry in the Azure Portal. This allows you to deploy all the necessary WVD backplane components including the VM acting as the Management Server. Recently published article on Tech Community by Christiaan Brinkhoff
  2. Using your own custom JSON template, specially useful if you are deploying the same setup in multiple environments or for multiple customers.
  3. Deploying using 3rd party tools or community tools. For example CloudJumper (who recently became part of NetApp), Nerdio, the free community WVD Management GUI provided by Marcel Meurer, or any of the other tools available.
For the purpose of this article, we’ll go for option 2. We’ll use a JSON template that we can easily re-use in various Azure Subscriptions. If you are less familiar with JSON, a while back I published a 9-part series of articles on deploying RDS in Azure IaaS using JSON templates that is a good start to get introduced into JSON based on the RDS use case.

STEP 1 Creating the WVD backplane components

We’ll start this walkthrough with the creation of a WVD Workspace using JSON. The section below shows this code. The Object Type to deploy is called Microsoft.DesktopVirtualization/workspaces. The minimum we need to define is a name, location, friendlyname and description. We’ll leave the applicationGroupReference empty since we are creation an association later.


To make sure name of the WVD Workspace meets the overall naming convention I’m using for other Azure Objects, I define the WorkspaceName as follows.


Next, we create the Host Pool. We need a couple properties to define the friendlyname, description, hostpool type and load balancing type.


Again, to make sure we comply to a generic naming convention we define the host pool name as shown below. For the Host Pool load balancing type we select Pooled since multiple Administrators will be sharing sharing a pool of x number of Management Servers. We define the load balancing type as BreathFirst so that sessions are distributed evenly across the VM’s we publish as Management Servers as part of this host pool.


Breadth-first distributes user sessions across all available session hosts in the host pool. Depth-first load balancing distributes user sessions to an available session host with the highest number of connections which has not reached its maximum session limit threshold. More info: https://docs.microsoft.com/en-us/azure/virtual-desktop/configure-host-pool-load-balancing
Next, we define the creation of a WVD App Group. Again we define the usual properties like name, location, friendly name and description.


For the property applicationGroupType we choose “Desktop” since we are publishing a Full Desktop session towards the management server. The other option is RemoteApp which allows us to publish individual applications. For the property hostpoolarmpath we provide the resource ID of the hostpool we had create earlier. The screenshot below shows the list of variables used to give you an idea what was specified.


STEP 2 Creating the Management Server VM

Since we now have completed the JSON code to create WVD backplane components, lets cover the creation of the Management VM itself. There are guides available online that cover the creation of a VM in Azure using JSON. Therefor, I will not duplicate that content. A good place to start is Create a Windows virtual machine from a Resource Manager template and Virtual machines in an Azure Resource Manager template. Also, if you are looking for a simple, yet fully working ARM Template check out this GitHub location Very simple deployment of a Windows VM.
In my case, I have reused an existing ARM template we use to deploy a new vanilla VM to Azure inside the specified Subset and using the specified naming convention. On top of that I like to use the Domain Join Extension. This allows me to join the VM to a existing domain in the OU that I specify. More into of the extension can be found here on Github: Joins an Azure virtual machine into an AD Domain by using JsonADDomainExtension extension
In most case, you will not want to deploy a vanilla Windows Server 2019 or Windows 10 Enterprise Multi-Session VM. Instead, it’s convenient to create your own Template Image in Azure first. You can do that by deploying a new VM in Azure, Windows Server 2019 or Windows 10, and once that is complete install all the tools you want to have on the management server. For example you might want to install the RSAT tools and any other 3rd party management tools you want to allow administrators to leverage.
If you select Windows Server as your operating system for a WVD Template Image make sure you install the RD Session Host role, otherwise the WVD deployment will fail. For Windows 10 Multi-Session, this is not needed. Also, using Windows Server requires an RDS Client Access License where Windows 10 Multi-Session does not.
Once you are done customizing the VM you need to sysprep and generalize the VM and capture it to a Template Image.
Note that the actions below result in the VM object that you used to create the template image, becomes unusable. Therefor you might want to take a snapshot of backup before starting the starting Sysprep and capture process.
For instruction on how to sysprep and generalize, follow this guide Create a managed image of a generalized VM in Azure
And finally, to create a Template Image object we capture the VM to a Template Image. To do this, select the capture option on the VM and specify a Tempate Image name and Resource Group location.


STEP 3 Have the VM add itself to the freshly WVD host pool
During step 1 we created the JSON code code create the WVD Workspace, Host Pool and AppGroup. During step 2 we talked about creating the JSON code to create a domain joined VM, optionally based on a Template Image. Its now time to bring it all together! Lets cover the most critical piece, automatically adding the freshly deployed VM to the brand new hostpool we deployed.
Of course we could go ahead and use the WVD Management options on the Azure Portal to add the new VM to the new Host Pool. In stead, lets cover how to automate that part and have the VM join request a new registration key and using that key add itself to the Host pool.
I selected ARM PowerShell extensions to perform this action. Main reason is that this allows me to re-use that same PowerShell script when expanding the Host Pool with additional servers using ARM and even leverage it as a way to (re)register VM’s as part of troubleshooting steps in the future by manually kicking of the same script.


To have the script support a variety of different use cases it accepts the following 10 parameters to define how the host adds itself to the existing host pools and what other optional configurations are performed
Next, the script authenticates using the Service Principal account and checks for existing registration info. If registration info for the Host pool exists, it grabs the corresponding token and if not, it creates a new registration info and collects that token.


Next, the scripts downloads both the WVD Agent and Bootloader and silently installs it on the WVD Session Host providing the token from the previous step.


Optionally, the WVD Host can set itself in drain mode by specifying the DrainMode parameter. For the purpose of this Management Server it’s most likely not needed, but this allows us to re-use this script to add additional WVD Host servers to a production WVD Host pool which we do not want to take in production right away. E.g. if you are rolling out a new Template Image version and want to switch over later during the evening or a different maintenance window.
And Finally, the script (optionally) associates the AppGroup with the Workspace. This is optional and particularly handy when the script was part of a full JSON Deployment in which a new Workspace and AppGroup were also created.
STEP 4 Deploying the Custom JSON Template
Let’s now take a deploying in an Azure Subscription. We perform a new custom deployment in our Subscription. and deploy it to a dedicated Resource Group.


As stated before, I’m reusing an existing JSON template we also use to deploy new vanilla VM’s in Azure. And we have added the creation of a Workspace, Host pool and AppGroup to is. We also added a new PowerShell extension to run the PowerShell Steps on the deployed VM as outlined in step 3. Below is a snippet from the JSON code to give you an idea how the PowerShell Extension is launched as part of the ARM deployment.


In order to collect a couple of parameter to pass to the PowerShell extension, we collect them as part of the JSON template. And after that we kick off the deployment…


STEP 5 Taking a look at the end result
The entire JSON template only took 11 minutes to complete! This includes the creation of the domain joined VM, all the WVD backplane components ( workspace, Host pool, AppGroup) and adding the VM to the WVD host pool!


Below is what it looks like from a Deployment overview as well as from a Resource Group overview with the created Azure objects.


The template created a WVD Workspace and performed the association with the created AppGroup.


And the Host Pool is created with the Management Server added and available as well.


Ans also, the VM was joined to the domain inside the designated OU we specified as one of the parameters.


So, we have deployed a secure and easy to access management server published via WVD and accessibly anywhere using any device in ~11 minutes! Lets see the end result!
When we log on to Windows Virtual Desktop, in this case using the Windows Client, we have the Management Server available with all the admin tools we need!


And of course we have that same management server available at our finger tips on any other OS as well using the Remote Desktop App from the various AppStores, including a Web Client based on HTML5.


To conclude: In this article we talked about using a centralized Management Server / Jump in Azure and publishing it to administrators, applications vendors and external contractors using Windows Virtual Desktop! This allows secure access for management purposes using any device from any location! Regardless if you are already using WVD for other purposes or not, I can recommend using the service to provide easy and secure access, including conditional access, to a management server without the needing a VPN.

Monday, May 4, 2020

Migrating your existing WVD Workloads to WVD Spring Update!

So, Windows Virtual Desktop (WVD) Spring Update (Public Preview) is out as of last week! In case you missed it, on the day of the launch I published an article covering my experiences of testing WVD Spring Update in private preview! I talked about the top 10 things that stand out. Catch the article here: The next big innovation in Windows Virtual Desktop is here!
As discussed in the article mentioned above, WVD Spring Update makes deploying and managing Windows Virtual Desktop a lot easier because there now is full integration in the Azure (Resource Manager) Portal! Since the first release of WVD saw the light on September 30 of last year, many organizations have already deployed it and have it running in production. I myself have helped at least a dozen of organizations with architecting and implementing and many of them are using it in production right now. So, the question arises, how can we start to manage existing WVD Workloads with the new WVD Spring Update Azure Portal Integration?
First of all; Microsoft is also working on a set of PowerShell Cmdlets for the Az PowerShell module that can be used to migrate an existing Host pool including hosts from WVD Fall 2019 to WVD Spring 2020 update. I have already seen private preview information on this and it looks very promising! If the Cmdlets become available in public preview I will share it here. In the mean time, this article explains how to migrate your workloads today! Also, it is a good exercise to perform migrations using the steps explained in this article as it allows you to get familiar with the new components, PowerShell Cmdlets, ARM code and so on.
This article talks about migrating your existing WVD Workloads to WVD Spring Update!
Before we start it’s important to realize what WVD Spring Update exactly is. It is not “just” a new Management Console for WVD. It all about making WVD a 1st Party application in Azure and as a result some changes to the WVD Service were needed. Below is a quick summary of the most important changes. Again, for a full list and more detailed information, check my previous article referenced in the first paragraph.
- WVD Backplane components are now ARM Based and manageable and visible in your Azure Portal.
- RBAC for WVD is now based on the Azure RABC model
- PowerShell Cmdlets are now integrated in AZ PowerShell
- The hierarchy of the WVD Backplane components changed
To answer the most important question; Can existing WVD Deployments and resources be instantly managed using the new Spring Update Azure Portal integration? The short answer is no. Does that mean we need to start entirely from scratch? No again! It comes down to migrating your WVD Host Servers from WVD current release to WVD Update Release. This article takes you through these steps.
Migrating to Spring Update (even with the upcoming migration Cmdlets) basically comes down to 4 main steps:
STEP 1 — Duplicating existing WVD backplane configuration into WVD Spring Update In this step we are going to duplicate existing WVD Tenants, Host Pools and Applications Group into the WVD Spring Update. Basically, we are creating a second WVD Deployment fully separated from the existing WVD Deployment. Depending on the size of your existing WVD Deployment you can perform this manually using the WVD blades in the Azure Portal, by using JSON Templates, or by using PowerShell to export and import the configuration. In this article we will use PowerShell to automate the duplication of a Tenant with a Host pool and AppGroup. And we’ll also briefly touch on JSON and VD blades in the Azure Portal.
STEP 2 — Moving your existing WVD Hosts to WVD Spring Update In this step we are moving WVD Hosts from the existing WVD Host pool towards the new Host pool in WVD Spring Update. This step can be performed with a single WVD Host at first to start testing the WVD Spring Update Update, and later additional WVD Hosts can be migrated the same way. We’ll also discuss the option to recreate a new set of WVD Hosts in parallel with the existing environment.
STEP 3 — Assign users and groups In this third step we will assign permissions to the WVD Host pool to allow (a subset of) users to be able to test the new deployment.
STEP 4 — Testing the migrated WVD Deployment We are now ready to test the migrated WVD workload using our WVD Clients and plan for next steps.


So let’s go ahead and dive into the migration deep dive, here we go!



STEP 1 — Duplicating your existing WVD backplane configuration into WVD Spring Update
This first step is all about exporting your WVD Configuration on the current release so that you can import that configuration in WVD Spring Update. For this example, I selected an existing WVD Host pool that publishes a Full Desktop. But obviously, the same steps apply to migrating a Host pool that publishes a set or RemoteApps. In that case however, make sure to add the additional Cmdlets to export published RemoteApps. In this example I chose to duplicate a single Host Pool in each run to get better control over the migration path, the script can of course be extended to run in a loop to export every Host Pool.
First, we need to define the parameters based on our existing environment, so the Tenantname, HostpoolName and AppGroupName. And second, we define the SubcriptionID, destination ResourceGroup and Location of our new WVD Spring Edition deployment. Remember that these 3 properties are mandatory as outlined in my previous article.



Next, we logon to the existing WVD Deployment.



Next, we export the properties of the VWD Tenant (remember that starting from WVD Spring Update this is renamed to Workspace), Host Pool and AppGroups. In this example I made a selection of properties I am interested in but you might need to expand these for specific scenarios were other properties are of interest as well.




Now, let’s connect to Azure using PowerShell and import the new WVD module, which is now part of Az PowerShell.




Now we can create the WVD Workspace based on the exported values of the existing WVD Tenant and we add a postfix “-Migrated” to it in order to differentiate the existing and new published desktops inside the WVD Client. This is of course optional.




After the WVD Workspace has been created, we perform a similar approach to create the (empty at first) WVD Host pool based on parameters we exported earlier.




And finally, we create the App Group in a similar way, also based on the values we exported from the existing environment.




New in WVD Spring Update is that an App Group needs to be associated to a Workspace in order for end users see assigned applications and desktops. The command below creates this association for the App Group and Workspace we created above.




And as a final step we configure the Friendly Name of the Published Desktop, duplicating how it was configured in the existing WVD Deployment.




This concludes Step 1; we have now duplicated the WVD Backplane components to WVD Spring Update! The end result in the Resource Group looks like below. A Workspace, Host pool and App Group have been created.




The workspace has an association with the App Group.




And all other properties are successfully migrated as well, as per example below some of the properties of the Host pool we migrated.




In this example we used Az PowerShell to create the WVD Spring Update backplane components. Since Spring Update is fully based on ARM, we could have also created these objects using JSON templates. Below is an example of what it would look like to create a Workspace, Host pool and Appgroup using JSON.




STEP 2 — Adding your existing WVD Hosts to WVD Spring Update
Now that we have the backplane components in place we have a Workplace, Host pool and App Group ready. It’s now time to add (existing) WVD Host Server towards this new host pool. Before we start, the goal of this step is to add WVD Host(s) to the Host Pool we created in step 1 and there are 2 migration options for this scenario. Select the one that is applicable for your environment.
Option 1. Using Existing (custom) template VM images
If you have an existing WVD environment based on current release you deployed your WVD Host based on a (custom) template and most likely (and hopefully) still have access to that template. In case you used a vanilla Windows 10 Enterprise Multi-Session template, you can simply re-use that same template to add new WVD Hosts Servers to the new Host Pool. But most likely you used a Custom Image Containing company specific applications, in that case you need to have access to the Template Image that you used when deploying the existing Host pool, for example Template Image objects like below.




In both cases (vanilla- or custom template image) the steps to add WVD Hosts is similar approach.
You first generate a Registration Key for the Host pool. With WVD Spring Update this can now be performed easily from the Azure Portal (and also still using PowerShell) as shown below.




Then we are able to add new WVD Host to the host pool by using the Azure Portal WVD Management blades.




Next, you specify the WVD Host properties like the Region, Size, Number of machines and Prefix similar to how you deploy WVD today.




Then you specify the image in case you used a vanilla image, select Gallery and select the image you used. In case you used a custom template image, select Storage Blob and configure the location.




And finally, provide the networking information, the domain to join including the service account to add the machines to the Active Directory domain.




The end result is that the WVD Host Pool now has WVD Hosts added to it.




We performed the actions as part of Option 2 manually using the Azure Portal. You can of course also use Custom ARM Templates if you want to have granular control over what gets created. In a previous article I talked about my Custom ARM Template for WVD Current release. In the mean time I have already updated that Custom ARM Template to also support WVD Spring Update, I’m planning to talk about that in more detail in an upcoming article, but to give you an idea of what it looks like, I added a screenshot of the deployment using that Custom ARM Template.
Amongst other options it allows for fast and easy selection of Workspaces and Host pools from dropdown lists with preconfigured values.




Option 2. Migrating existing WVD Host(s)
In case your current WVD Deployment was build on a Custom Template Image that for some reason is not available anymore, out of date, or if you never used a Template before and installed applications in a different way, you can also move & migrate the existing WVD Hosts.
For this option 2, let’s consider the following example. I have an existing WVD Host pool based on current release. This Host pool consists of 2 WVD Host servers, based on Windows 10 Enterprise Multi-session.
We use the command below to retrieve the WVD Hosts that are part of the existing Host Pool.




The output looks like below.




For this example, lets migrate the 2nd server (WVDFBFD20031–2.wvd.ninja) and leave the 1st server in place to support existing sessions. Again, this is a sample environment, in production environments you will have more hosts to migrate. The command to remove the WVD Host is as shown below. Optionally you can use the -Force option if the host has existing sessions that can be ignored.




We log on to the WVD Host server and open the Installed Programs section. Amongst other installed software, we can see the components that are needed for WVD. Depending on how long this WVD host has been running you will see multiple previous version of the agent and SxS stack as well.




The safest way to migrate this WVD Host to the new WVD Spring Update host pool is by first uninstalling all of the WVD Agent & SxS versions. It can be done manually, but I have created a PowerShell script that uninstalls the various agents including multiple previous versions if those exist. Be careful where you run this script and use it at your own risk as it does not ask for confirms and uninstalls instantly.
No alt text provided for this image

An automated uninstall step of the SxS Network stack seems to temporarily drop your RDP session, so I left that out. If needed it can be uninstalled manually. select “do not close “to avoid the drop in your RDP session. I have not found the uninstall switch to force to this mode yet.


Then we add the WVD host to the new WVD Spring Update Host pool. In order to do so we log in to Az PowerShell, in this case with our ServicePrincipal account.




And finally, we download and install both the WVD Agent passing it the registration token and we download and install WVD Boot Loader




The end result in the Host pool looks like below, the host is successfully migrated from WVD Current version to WVD Spring Update!




The script snippets I shared above as part Option 2 are actually part of a fully automated PowerShell JSON Extension Script that I use to deploy WVD Hosts to a new host pool or expand a Host pool with additional WVD Hosts.
STEP 3 — Assign users and groups
Now that we have the WVD Backplane components including freshly installed or migrated WVD Hosts, it is time to start assigning permissions to the created App Group.
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! To add an AAD Group to a WVD Spring Update App Group, browse to the App Group, select Assignments and as you can see below, I am able to add AAD Groups as well as ADD Users.




So, when it comes to migrating user access from WVD Current Release to WVD Spring Update, in most cases it will be a matter of creating new AAD Groups and adding those to App Groups.
In case you want to add users and groups using PowerShell, you can use the Azure RBAC model, and so *-azRoleAssignment can be used. For example, here is the code to add an individual user.




And below is the code to add a Group. Since this specific group is a security group it does not have a SignInName, so I am adding it based on its ObjectID.




And similar, I can retrieve the users who have access to the AppGroup as shown below.




The end result looks like below, in this case both an individual user as well as an AAD Group are added to the WVD App Group.




STEP 4 — Testing the migrated WVD Deployment
So, finally we can now test the migrated workload. In order to see resources published from a WVD Spring Update deployment, the version of the WVD Client needs to be version 1.2.673+.

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 users perspective has not changed.
Below is the WVD Windows Client that now shows both the existing WVD workload (1) and the new WVD workload based (2) on Spring Update!




And when we launch the Full Desktop published in WVD Spring Update we can confirm it is successfully working!




And as a last step, lets confirm the running session in the Azure Portal.




This wraps up & concludes this migration article. After testing the Spring Update thoroughly, you can plan to start adding or moving more WVD Host Server and expand the group of users to migrate in several phases.
And finally, as also stated in the beginning of the article;
Microsoft is also working on a PowerShell Cmdlet for the Az PowerShell module that is able to migrate an existing Host pool and hosts from WVD Fall 2019 to WVD Spring 2020 update. If it becomes available in public preview I will share it here. Nevertheless if a good exercise to perform migrations using the steps explained in this article as it allows you to get familiar with the new components, PowerShell Cmdlets and ARM code.
Also, a shout out to Marcel Meurer who updated his WVD Management tool which also allows you to migrate host pools, great work!
And as always, if you have questions feel free to reach out to me via e-mail, twitter or Linked-In!