Windows Virtual Desktop (WVD) – First Impressions

Toby Skerritt has finally got his hands on the Windows Virtual Desktop (WVD) preview… here are his initial thoughts.

After months of anticipation, I’ve finally been able to get to grips with the new Windows Virtual Desktop (WVD) service, and while there are certainly some quirks and issues to be ironed out, I must say that generally, I’m very pleased.

Firstly, its worth setting the tone for this blog, which is purely designed to provide an overview of the current setup process, issues encountered, and first impressions of what the platform looks like for users and administrators. There is no discussion of business benefits, no cost analysis, and no discussion of why you might want to implement WVD. Other more capable people have written some great content in relation to this, most notably Kevin Goodman, co-founder of FSLogix. His perspective can be found here, and is well worth a read.

Setting Up WVD: 

Essentially, WVD is just a PaaS service for the management elements of a Windows Remote Desktop environment – so you no longer need to worry about the Broker, Gateway, Web Access or Licencing services. All you need to do is select and customise a desktop image, configure some Azure services, and assign desktops or applications to users. This is all achieved (currently) through PowerShell. The SKU ofr Windows 10 multi-user is freely available from the gallery and can be created without the use of the WVD platform. I’ve not tested this, but it should be possible to set up a standalone Terminal Services host machine based on this image. The gallery view and sku details are shown below. It’s important to remember that Windows 10 ‘multi user’ is exclusive to Azure, but not exclusive to the WVD platform. Citrix, VMware and other will be integrating this sku into their offerings but managed by a different control plane.

All the guidance for creating the WVD tenant can be found at the below link. I found this documentation very thorough, however there is plenty to be done once these steps have been completed, and customisation of your master image is predictably going to take much more time (LOB applications, office deployment etc.). For testing purposes, I’d recommend reducing the VM size to keep costs down. I chose a B2ms, with 8GB of ram and 2 CPUs, I also chose HDD rather than SSD for storage, again to reduce overall costs. Performance has been fine for early-life functional testing. https://docs.microsoft.com/en-us/azure/virtual-desktop/tenant-setup-azure-active-directory

User Access: 

From a user access perspective, there are a few different ways for users to access this platform:

• The new Microsoft RD client which supports aspx feeds can be found here
• The HTML5 based Web Client can be found here
• Details for the iOS RD client (beta) can be found here

(I was very impressed with the usability of this one) You can even add the stream to your remoteapp and desktop connections in Windows 10 (although I believe this is unsupported, and performance can be erratic) Stream details are shown below. https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx With setup complete, and the correct clients downloaded, it was time to start testing. Generally, I have to say that the logon experience via the new Windows RD client and the HTML5 web client is slightly disappointing. Both still have the appearance of traditional RDWeb services front end, and its quite dull and tired. Microsoft should follow Citrix or VMware’s lead here; the Horizon web experience for example is much more appealing.

The Desktop Client Experience – tiny icons, lots of white space.

 We are a pretty good test case for interoperability as our AD is federated, we use InTune to manage end-user devices, we have implemented Windows Hello, and we use multi-factor authentication in most instances, including passwordless sign on, which I am a big fan of. The initial authentication process for us was a bit clunky, however it must be remembered that the service is likely to improve significantly before full public release. The new Windows and iOS RD clients prompted me to log into Microsoft, authenticate to our ADFS STS server, then enter the code provided in an SMS message (passwordless sign in is not currently supported). Once this initial process had been completed however, it was simply a case of selecting the desktop and entering my domain password each time I wanted to log in (Windows Hello PINs are also not supported currently). The desktop client experience was great, it instantly picked up my multiple monitors, with the appropriate resolutions. The Web-based HTML5 client also worked well, allowing single sign-on to the platform, but not into the desktop itself. This required me to enter my domain username (no domain suffix required) and password. Helpfully, Edge remembered these for future use. The Web client performed well, with even Youtube content playing acceptably in full screen (circa 20 fps).

Administrative Pain Points: 

As it stands, you can’t deploy both applications AND desktops to the same user in a pool, its one or the other. This was a feature of previous Remote Desktop services, so I hope this will be introduced soon. Deploying remote applications is a bit painful – you need to query the OS via PowerShell, then find the application you want from a list of all applications in the start menu, this is a clunky process. Also, I haven’t yet discovered a way to rename the desktop from ‘Session Desktop’ to something more meaningful.

Adding Applications – from a list of around 50, note required info, then run a PowerShell command to deploy the application.

WVD Summary: 

Below are the key observations from my limited testing. Its important to remember that the is a preview product, and many of the current issues will likely be addressed before the full public release.       

Good

• Much simpler to setup than a traditional Remote Desktop infrastructure, as Microsoft host the control plane.
• Windows 10 experience with ‘Multi-user’ functionality.
• Can scale automatically, based on demand
• Simple access via clients or web browser
• Great desktop performance

• Opaque control plane, no GUI option for service management
• No Group support – users must be assigned individually
• Currently, will only deliver applications or desktops from a pool per user, not both.
• Multiple authentications required
• No support for Password-less sign in
• No support for InTune Management platform
• General user access experience not as good as competition

Licencing WVD

Licencing is still a confusing subject; however we at least now have a clear steer on eligibility, which can be found in the FAQ section of this page. As it stands, the below licences are eligible for both Windows 10 and Windows 7 WVD. Bear in mind, this is operating system only licencing, you will till be liable for compute, storage and bandwidth costs associated with your WVD environment. Its also worth remembering that for access from non-windows devices, you required at least one of the licences listed in red for the specified user.

• Microsoft 365 E3/A3
• Microsoft 365 E5/A5
• Microsoft 365 F1
• Microsoft 365 Business
• Windows 10 Enterprise E3/E5
• Windows 10 Education A3/A5
• Windows 10 VDA per user

Early Conclusions: 

From a purely technical perspective, I really like the platform. There are still lots of areas that I hope are improved prior to full release, but as it stands this is a usable and versatile service, and the availability of Windows 10 multi-user is a very welcome addition. Use cases vary by organisation, but if you have moved a significant proportion of your infrastructure estate to Azure, including user-facing services, then moving the user desktop or application closer to the back end makes a lot of sense. The key element for a good user experience will then become local connectivity. Office network bandwidth, resilience and latency should be one of the first areas of investigation if you plan to move to WVD, or any cloud-based EUC solution, including DaaS.