I have been helping admins who have been tasked with immediately piloting WVD, and this post aims to document some of infrastructure items that are commonly overlooked in the rush to stand up the solution. (For more insight in setting up WVD for remote workers, check out this blog post by my colleagues Drew Shanahan and Brandon Pierce.)
Active Directory, Azure Active Directory and Azure Active Directory Domain Services
Windows Virtual Desktop uses Azure Active Directory to authenticate users of the WVD environment; it is not used to manage the underlying server infrastructure. User authentication, at least for now, is where Azure Active Directory’s involvement ends.
The servers that make up a Host Pool, called Session Hosts, must be joined to an Active Directory Domain. To support full cloud deployments, Microsoft created a service called Azure Active Directory Domain Services. This provides a limited domain environment for cloud-based systems that require Active Directory, but on-premises Active Directory has not been or cannot be extended to the cloud. This includes organizations that are pure cloud, meaning they have no on-premises infrastructure to extend.
The WVD Session Hosts can be members of either Active Directory or Azure Active Directory Domain Services. Which one is right for an organization depends on the organization’s existing cloud footprint. An important point to consider is the need for the Session Hosts to talk to a domain controller. If an organization’s Active Directory is purely on-premises, either a site-to-site VPN or ExpressRoute will need to be in place. DNS server assignment in Azure will also need to be configured if provisioning a new network to support WVD.
User Profiles and Storage
User profile management is something that is commonly overlooked by first-time implementers, but it is crucial that it not be. Improperly or unconfigured user profile handling will severely impact the functionality of the WVD deployment and will likely impact the user experience.
FSLogix is a solution to handle the user profiles, Office 365 profiles and certain applications, but this service requires a storage location to keep the profile files when not attached to an active user session. The best practice for storing these files is in Azure, which can be accomplished in a few ways. A file server cluster could be used but is not likely advisable if WVD will be its only purpose. A single file server can be used, but this does not provide redundancy and is not recommended for anything but lab use.
Azure File Storage is the newest way to provision storage for the user profile disks, but Azure Blob Storage is still a supported and viable mechanism. These options all come with their own pros and cons and should be taken into consideration when moving a WVD deployment from proof of concept to pilot.
One of the beautiful features of WVD is the ability to scale out deployments around the world quickly. For those admins who may have set up a pilot deployment in a single region, the implications of expanding the Azure Virtual Networks to accommodate an expanding WVD infrastructure need to be accounted for. These can include peering networks, additional site-to-site VPNs, creating new virtual networks, DNS and ensuring Session Hosts can communicate with Active Directory.
Having a healthy and well-thought-out infrastructure can easily make WVD part of an organization’s work-from-home strategy. With a good infrastructure in place, Windows Virtual Desktop can scale up quickly to meet the new demands, and scale back down when demand has subsided.