EDIT 11/16/2016 – This information is outdated. WVD now supports Azure AD Domain Services with users sourced from Windows Server AD.
I spent hours this week trying to design a Windows Virtual Desktop solution that stores FXLogix profiles in Azure Files. This should be a simple task, but once I got into the details it proved anything but simple. The first consideration was a note on the overview page of the WVD documentation “What is Windows Virtual Desktop” :
“If you use Azure AD Domain Services, your users must be sourced from Azure Active Directory. Using Azure AD Domain Services with users sourced from Windows Server AD isn’t supported at this time.”https://docs.microsoft.com/en-us/azure/virtual-desktop/overview#requirements
If you have any question about the difference between Windows AD, Azure AD, and Azure AD DS, check out my article here that reviews and compares each.
I also noticed the Microsoft documentation on the same page lists the following requirements for Windows Virtual Desktop:
- Azure AD
- Windows AD in sync with Azure AD using Azure AD Connect or Azure AD Domain Services (but per the previously mentioned note, users must be sourced from Azure AD if synced from Azure AD Domain Services.
- A subscription with a VNet containing or connected to Windows Server Active Directory. The term “Windows Server Active Directory” is a little confusing. Is that referencing Windows AD, Azure AD DS or both? Based on my experience, I’m assuming this means the VNet needs connectivity to either Windows AD or Azure AD DS, depending on what option is in use.
- The VM’s need to be Standard AD Joined or Hybrid AD joined. WVD won’t work with Azure AD joined VM’s.
I come up with two deployment scenarios based on these requirements.
Windows AD Based WVD
Windows AD synchronizes users identities to Azure AD with AD connect. The WVD Session Hosts must join the Windows AD domain (not Azure AD DS).
The WVD VNet must have connectivity to a Domain Controller for the Session Host VM’s to join the domain. Connectivity options are a Domain Controller in Azure or on-premises with a VPN or ExpressRoute.
Azure AD Domain Services Based WVD
Azure AD DS in place and replicating with Azure AD. Users must be sourced from Azure AD, not synchronized from Windows AD. Session hosts join Azure AD Domain Services.
The WVD VNet requires connectivity to the Azure AD Domain Services.
There are some reports that Azure AD DS joined VM’s will work with Hybrid identities by synchronizing password hashes to Azure AD DS using the steps in the document in the link below. The note in the WVD documentation is clear that Hybrid Identities and Azure AD DS joined Session Host is not supported. I’m leaving this option out of the equation until there is more guidance from Microsoft.https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-password-hash-sync
Edit: 11/7/2019, This week at MS Ignite Azure Files support for on-premises AD was announced. A welcome addition for WVD profiles.
Now it gets interesting. I started with this link that states Azure files is a premium solution for user profiles in WVD. That sounds good, Azure Files would be an ideal target for FSLogix profiles.
However, Azure Files SMB access requires the VM to be Azure AD Domain Service joined. Put that in context to what we have already learned about Windows AD and Azure AD DS, and I have to conclude Azure Files for FSLogix profiles will only work with identities that are sourced from Azure AD, not synchronized from Windows AD.
For organizations that are cloud-native, Azure AD DS with native Azure AD identities and Azure Files for FXLogis profiles would be a great option.
For organizations replicating identities from Windows AD to Azure AD, the WVD Session Hosts must be Windows AD joined to be supported. In this configuration, Windows Server file share or NetApp Files are the only options for FSLogix profiles. Azure Files won’t work.
Don’t agree? Have had another experience or know something I missed? Please add to the comments below.