49 facts listed – What I picked up during a WVD Solution Design Workshop

Last week I drove to Microsoft HQ NL, which takes me about 15 to 20 minutes to attend a Solution Design Workshop specifically aimed at WVD. After a formal kickoff (and coffee, of course), the group was split into a technical and business/sales orientated track. Needles to say I joined the technical track. Here’s what I’ve learned. I’m pretty sure there’s some stuff in here you didn’t know already.

I’ll try and stay clear from the obvious, if your new to WVD I would suggest reading one of my earlier articles, here or here. Below you’ll find answers to some of the questions asked during the workshop, information shared in general, and some notes from personal experience while setting a WVD tenant a few weeks back.

1. A common mistake when setting up a WVD tenant for the first time is to skip (or forget) the ‘give consent’ steps to both the server and client app. Though, you’ll only need to give consent to the client app when you want to experiment with RemoteApps, to appear in your start menu, for example. It’s not a necessity to build up and try out Windows Virtual Desktop.
2. The same applies to assigning tenant creator permissions.
3. The account used to provision your WVD hosts needs (at least) RDS-Owner permissions. Use PowerShell to assign. It’s all in the docs.
4. When your tenant is ready, make sure your users are created in Active Directory Domain Services (normal AD) and that they are synced (Azure AD Connect) to Azure AD. A user created within Azure AD won’t be able to log in. When using PowerShell diagnostics (detailed) to troubleshoot, which I did, you’ll find that it doesn’t work because the user cannot be added to Remote Desktop User Group. This happens because the account is not in the same domain as the machine, meaning Active Directory Domain Services (normal AD).
5. Some skip the perquisites completely and start by creating a hostpool directly from the Azure marketplace. Read the manuals and FAQ’s. Go here and make sure to follow all steps.
6. Most of the above steps will be automated going forward, no exact time-frame as of just yet. A new Azure WVD management portal is being worked on.
7. People were curious about the use of Azure AD exclusively, meaning no more synchronization with Active Directory Domain Services. Yes, this will be possible in the (near) future.
8. The same goes for using (Azure AD) security groups to assign users to WVD resources. It’s coming.
9. When a WVD tenant is created it means the control management plane, managed by Microsoft is being set up and made ready for use – it’s what used to be called RDMI.
10. Once you have a fully functional WVD tenant up and running you might want to consider exporting it to a ARM template. This makes it easier to create multiple tenants, when you are a CSP for example, or use it to create multiple hostpools. A little automation never hurt anyone.
11. As you may know, hosts can live anywhere on Azure, meaning all Regions over the globe, though the WVD service itself, the control plane, is only available in East US2. At least during the preview phase.
12. For machine sizing purposes there are templates and guidelines available form Microsoft. However, these are pretty conservative, meaning too low on RAM, CPU etc. is basically what most where saying.
13. There were some questions on pricing from a CSP perspective as well. Currently Microsoft is working on multiple templates and calculators of which at least one will be specifically aimed at WVD. Also, these will be based on more real-world usage scenarios, instead of the resource templates mentioned above.
14. The marketplace currently holds three pre-configured Operating System images/templates for WVD (with and without Office ProPlus configured, for example) plus Windows Server 2016. More will be added soon.
15. Note that the images currently available are not optimized for WVD/VDI usage. Meaning, you’ll have to fine-tune them yourself for which multiple documents are available. Microsoft is investigating if and how they can offer more customized and optimized Windows templates. No further details as of yet.
16. There can only be one Desktop App Group and any number RemoteApp App Groups per hostpool. Users cannot be assigned to a Desktop App Group and a RemoteApp App Group within the same hostpool. Users can be assigned to multiple RemoteApp App Groups. All machines within a hostpool should be provisioned form the same image.
17. The above also means that when you create a separate RemoteApp App Group, next to an existing Desktop App Group a new/additional virtual machine will be needed/created.
18. Changes to above (bullet 16 and 17) are being worked on, though at this time there are no further details that can be shared.
19. Load Balancing is configured at control plane level.
20. The Scaling Script, which now needs to run as a scheduled task will be automated and available as part of the upcoming new WVD management portal.
21. Image management can be done in multiple ways: by using Azure Update Management, SCCM, Intune, though this will be added as a post GA option, ARM scripts provided by Microsoft, Azure Automation, manually, or by means of other third party software.
22. For the updating of (hostpool) images there is a template/script available. This is what happens: it will, drain, stop, and remove old WVD instances, create new session hosts and register them to the WVD hostpool. There are multiple parameters that you’ll need to fill in.
23. The above will also be made available in the upcoming WVD management portal.
24. Creating hostpools, assigning desktops and applications to users, add and remove machines to a hostpool, drain existing machines, etc. will all be automated and made available in the new WVD management portal as well.
25. All existing PowerShell CMDlets won’t go anywhere. New ones will be added as we go along.
26. The Fslogix Profile Containers will be the only supported profile management solution going forward. Currently, Storage Spaces Direct is the preferred solution for storing profile related data, and thus containers. In the (near) future Azure Files will be added, and preferred.
27. Azure storage must be used for profiles when using WVD.
28. With Profile Containers as the default profile solution, this also means that CSP’s, including Citrix as an example, are not allowed to use anything else.
29. UPD and Roaming Profile will (eventually) no longer be supported. I don’t have a date for this.
30. A script of some sort will become available for UPD migration purposes.
31. Regarding user profiles, as a general guideline it is recommended to plan between 5 and 15 GB per user.
32. From an IOPS point of view plan for 5 to 15 IOPS per user. 70% write, 30% read.
33. As a best practice, configure Profile Containers on a per hostpool basis.
34. In short, Profile Containers, combined with Azure Files will be the only supported solutions for WVD in the future. This will apply to CSP’s as well.
35. MSIX AppAttach (Microsoft is slowly moving away from App-V) a brand new form of application layering (sort of) will become the native way for application management within WVD. However, this will take (at least) another year before to accomplish. Have a look here for some more detailed information.
36. Citrix will offer Citrix DaaS making use of the Windows Multi-User WVD image.
37. Their focus is on secure remote access, offering the Workspace App on every device, including a HDX user experience, and secure multi-factor authentication.
38. From an administration perspective they offer intelligent management and monitoring, simplified maintenance (all from a single management plane), support for non-domain joined VM’s, and the ability to manage your WVD hosts (Azure only) and on-premises machines form a single management console.
39. You need to be a Citrix partner to be allowed to use this, though there will be no strict obligations with regards to revenue and such. A mandatory certification will be involved. More detail will follow – during Synergy, probably.
40. Migrating your Azure RDS farm to Azure WVD is relatively easy: create hostpool within WVD tenant, install RD Agent on existing session hosts, agent will register itself with WVD, decommission old RDS hosts, launch your sessions.
41. Azure migrate is primarily used for VMware on-premises environments. Hyper-V and support for physical machines are on their way. It can do an on-prem assessment resulting in clear reports and overviews, including pricing and sizing recommendations.
42. Azure Site Recovery manager is also optional and can be used for VMware, Hyper-V and on-premises physical machines.
43. Multi-tenancy (Azure AD B2B accounts) for use with multiple Azure AD environments, is currently not possible but it’s something that will be worked on.
44. Microsoft is investigating the use of Azure Stack for on-premises WVD. On-premises use in general, so no Azure Stack, seems to be out of the question, at least that’s my take on it. Will depend on customer demand.
45. Today it’s no longer technically possible to connect WVD to on-premises and vice versa.
46. The WVD Windows 10 Multi-User images will follow the same life-cycle, update channels, and build numbers as Windows 10 does.
47. Currently the use of WVD API’s is not possible/allowed. As soon as the WVD service goes live this will change. Another way for partners to add value.
48. Publishing applications from an RemoteApp Group to a Desktop App Group is possible.
49. WVD will go GA within 4 months from now – the summer of 2019.

That’s it. Does it help?

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.