In my previous article I covered the use case of using Windows Virtual Desktop to publish a centralized Management Server / Jump in Azure to provide secure and easy access for administrators, applications vendors or external contractors. In that article I also briefly touched on using a PowerShell script to add a Host (weather its Windows 10 Multi User or Windows Server) to an existing WVD Host Pool. This PowerShell script is multi-purpose and can by used as part of a JSON deployment, any other automation, but also to manually add or re-add a host during troubleshooting or migration steps.
The script is no rocket science, but…
I believe this script to be a very valuable asset in an administrators WVD Toolbox. I decided to share this script publicly on GitHub for others to use it!
The script currently takes 9 parameters which allow you to customize which existing Workspace, Host Pool and App Group to use. You also need to specify the credentials of the Service Principal account. Because of changes in the new Spring Update 2020 release of WVD, we also need to specify the azureADTenantID, resourceGroupName and azureSubscriptionID inside any az.DesktopVirtualiztion PowerShell Cmdlet. Therefor, we collect those as parameters too. And finally the scripts allows you to configure if the new hosts should be placed in Drain Mode or not and it optionally can also create the association between the Workspace and the App Group if you had not performed that before.
The actions that the script performs are:
- Connect towards Azure PowerShell using the Service Principal provided.
- 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
Let’s talk about scenarios and use cases to leverage this script.
SCENARIO 1 : Using the script as part of a Host Pool Custom ARM Deployment creation or to add hosts to an existing Host Pool.
Windows Virtual Desktop Host Pools can be created and updated using the Azure Portal. This functionality was already there in WVD Fall 2019 Update, but became a lot more intuitive and easy to use in WVD Spring 2020 Update. As I also explained and showed in a previous article (Migrating your existing WVD Workloads to WVD Spring Update!) using a Custom ARM Template to deploy and update the WVD Hosts in your Host Pool also has advantages. Especially if you want to have granular control over what gets created using specific naming conventions for various Azure Objects.
From within a Custom ARM Template, this is how you can use the CustomScript Extension to download an execute the PowerShell script during the ARM Deployment. The parameters that are passed to the PowerShell script are collected as JSON Parameters when deploying the ARM Template. Again, besides ARM you can use the same approach in any existing automation your might already be using.
This allows me to deploy a Virtual Machine in Azure using existing ARM code I might already have and automatically add the Virtual Machine as a WVD Session Host inside a Host pool.
So, when deploying an ARM Template I allow the admin to select Workspace and Host pool information from an easy to use drop down list and pass these parameters to the PowerShell script.
The WVD step in the ARM Deployment shown below is where the PowerShell magic happens.
SCENARIO 2 : Using the script as part manually and quickly adding or re-adding a host
In some scenarios you might just want to add or re-add a WVD Host to a Host pool manually. For example;
- When you are troubleshooting an issue on a host that e.g. did not successfully register or lost connectivity towards a Host pool.
- 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.
In all of those cases you can just copy the PowerShell script to that host and simply run it by providing the parameters as previously discussed.
The script provides basic logging as per the example show below. It does not do any error handling yet, something I’m looking at adding in the future.
As said, I’m happy to take any suggestions you might have on improvements and proposals for new features using pull requests on GitHub, or just reach out to me directly.