Windows Virtual Desktop just reached public preview and I was really eager to test it out. Here are the issues I ran into during my first encounter with the solution.
I followed the instructions available at Microsoft Docs and considering this was deployed to my test environment I was happily surprised with only running into a few issues along the way.
Create a Windows Virtual Desktop tenant
This step would have worked out just fine if I had been a bit more observant in performing the steps described in the section “Assign the TenantCreator application role to a user in your Azure Active Directory tenant”. After creating the client and server apps I went in to Azure AD to find that my user was already assigned to the application.
When running the PowerShell-cmdlet “New-RdsTenant”, I encountered the following error:
New-RdsTenant : User is not authorized to query the management service.
I went back into Azure AD and found that the role assigned to my account wasn’t the right one. After adding the account again with the “TenantCreator” application role and reconnecting to Windows Virtual Desktop PowerShell the command worked fine.
Create a host pool with Azure Marketplace
Strange password requirements
When deploying your host pool you need to enter on-premise AD credentials to join the server to the domain. Pretty straight forward if the account used for this has a password of 12 characters or more. The UI will not let you advanced with a shorter password.
The reason for this is that during the deployment a local account will be created on the servers deployed. The user account will have the same name and password as the account used to join the domain. Azure required local accounts created on servers to have passwords of 12 characters or more.
Failed deployment of dcsextension
For my first attempt at a deployment I didn’t use a service principle as it appeared to be the quickest way to get the environment up and running. This didn’t quite work out as planned.
The last step of the installation is deploying an extension called “dscextension”. This extension would fail, in the error log I could once again see the error message “User is not authorized to query the management service.”
I didn’t really figure out what caused this issue as I decided to proceed with creating the service principal as described in the section “Create service principals and role assignments with PowerShell”. After re-deploying with the service principle instead of my users everything was good.
Manage app groups for Windows Virtual Desktop
After trying out the full desktop I decided to publish an application all went according to plan until it was time to add my user account to the AppGroup. Running the command “Add-RdsAppGroupUser” I got the following error:
The specified UserPrincipalName(s) is already assigned to a Desktop AppGroup in the specified HostPool.
The error itself is really quite self explanatory, all that was needed was running the cmdlet “Remove-RdsAppGroupUser” and specifying the AppGroupName “Desktop Application Group”. After doing this I had no issues adding the user to my new AppGroup.
Finding the web client URL
I had some issues finding the URL for the web client mentioned in the documentation, thanks to Reddit I managed to find it: https://rdweb.wvd.microsoft.com/webclient/index.html
While your host pool can be deployed in a wide variety if Azure region the endpoints used to access the service are located in Azure US regions. Microsoft suggests to deploy the host pool close to the end points. However if your based in Europe, performance will not be great until endpoints are deployed on this side of the pond.