Forum Discussion
Requirement to have an on-prem AD
Looking at the documentation, it seems an on premise AD is required for Windows Virtual desktop in Azure and Azure domain join is not supported. Can anyone confirm if that's definitely the case? It seems poor to have a new cloud service launched that has a dependency on on-prem AD.
HandA
on-prem AD is not required.
AD requirements:
Option 1: Domain controller that is synchronized with Azure Active Directory. The domain controller can be on-prem or in cloud. To synchronize with Azure Active Directory install Azure Active Directory Connect.
Option 2: Azure AD Domain Services domain in Azure (automatically synced with Azure Active Directory)
- Josh Bender
Microsoft
HandA
on-prem AD is not required.
AD requirements:
Option 1: Domain controller that is synchronized with Azure Active Directory. The domain controller can be on-prem or in cloud. To synchronize with Azure Active Directory install Azure Active Directory Connect.
Option 2: Azure AD Domain Services domain in Azure (automatically synced with Azure Active Directory)I don't understand your response. Per https://docs.microsoft.com/en-us/azure/virtual-desktop/overview:
Your infrastructure needs the following things to support Windows Virtual Desktop:
- An Azure Active Directory
- A Windows Server Active Directory in sync with Azure Active Directory. This can be enabled through:
- Azure AD Connect
- Azure AD Domain Services
- An Azure subscription, containing a virtual network that either contains or is connected to the Windows Server Active Directory
The Azure virtual machines you create for Windows Virtual Desktop must be:
- Standard domain-joined or Hybrid AD-joined. Virtual machines can't be Azure AD-joined.
- Running one of the following supported OS images:
- Windows 10 Enterprise multi-session
- Windows Server 2016
I would like to avoid any and all on-premises requirements and simply have an Azure Active Directory with Azure Active Directory Domain Services enabled with Windows Virtual Desktop virtual machines automatically domain-joined to that instance. Completely cloud. Nothing physical.
Is this possible ?
Thanks. I have this working now using Azure ADDS. Documentation seemed a bit unclear when I first looked at it
How were you able to get the machine to connect to the domain mine failed on domain join wondering If i can somehow do it manually
HandA gerry_1974 Right now, that seems to be the case. In my proof of concept environment, I am running an AD DS server in my Azure tenant, then joining my host pool to that domain through the Windows Virtual Desktop offering. Although at first I was still getting failures with my deployment, even with the AD DS domain existing and the session hosts successfully joining. What fixed this for me, was connecting my AD DS server to AD Connect. I think AD Connect has to be actively syncing and connected to Azure AD for this to work right now due to the interaction it has with the Azure AD users (granting them access to the pool, etc). I went through this bit-by-bit and this is what got me a working deployment (DSC failures on the session host otherwise).
- Does appear to be the case, however I did deploy using Azure ad domain services on a vnet and on my existing on premise with Azure ad connect I followed these steps to sync the password hashes https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started-password-sync
You don't need to actually have the Azure AD and the local Active Directory synced at all (at least with regards to AD Connect). I was able to get everything moving by just adding the Azure AD UPN Suffix (e.g. <tenantname>.onmicrosoft.com) to my Local Active Directory and creating a user whose UPN matches my Azure AD User (e.g. <user>@<tenantname>.onmicrosoft.com).
Yes, I ended up being prompted twice for credentials, once for opening the feed and again for logging into the server, but the end result was a successful connection without having to Sync the ADs.
- Christian_Montoya
smithanc : If this works right now, then great! However, we only support when there is a true synchronization between Azure AD and the local Windows Server AD: either through Azure AD Connect, Azure AD Domain Services, or through federation.
Christian_Montoya Understood but hopefully you extend support to other models such as the one I have done in my PoC. Otherwise, my main use case right now for WVD is broken as I am looking to use WVD to provide VM access to isolated VMs that are located in a Azure VNET which does not have any public IP address associated to any NIC card within that VNET.
We looked into using RDS with Azure AD Application Proxy but ran into a blocker that it only worked with ActiveX and therefore only on Windows Machines running IE 11.
Otherwise, we will have to turn to the Citrix cloud.
