Forum Discussion
Azure AD Connect & WVD
Hey all
Im setting up WVD (Windows Virtual Desktop) for a client.
From what ive read on docs i either need Azure AD Connect (with my on premise enviorment) or Azure AD Domain Services.
Im going with the first one Azure AD Connect.
I have synced over users in a demo enviroment and it worked out fine.
But when it comes to adding a host pool to WVD it asks me to write "AD Domain join UPN"
I'm a bit confused rather they ask me for my global admin account in Office365,
or AD Administrator Account onpremise? Or maybe even if they should be synced (merged) as one account?
Help is appreciated, Thanks!
I managed to fix this myself.
I want to share the issue and what solution worked for me, and also give a big thanks to all the people that had engagement in this thread.
my on prem AD had the same domain name as my Azure AD tenant.
Also, my on prem AD join user had the same UPN as one of my Office365 users (which is a part of Azure AD Tenant)
So I suppose wvd deployment was trying to authenticate with the wrong catalog, and since I don't have Azure ADDS deployed it failed.
Hope someone troubleshooting this same issue will find this thread.
You join your newly built VMs to a Windows Active Directory. That is the ad domain join credential, just like you would add a new machine to your on-premises domain. But! Your Windows Active Directory servers need to be able to reach the virtual network that the WVD VMs live in. So:
- Either you have set up AADDS, and those instances give you two IPs (which you have to add as DNS servers in your VNet)
- Or you have your on-premises domain controllers connected to Azure via VPN or express route. Preferably also you have set up two domain controllers in Azure and sync them with your on-premises domain controllers. Next to this, there needs to be an AD connect, so that your accounts are also in Azure AD. Then you add the IPs of your on-premises (or Azure replicated) IP addresses to your DNS in the VNet.
Once you've set up those prerequisites, you can add the hostpool VMs to your domain, using your on-premises credentials.
An end user will first log on with the Azure AD credentials, then log on a second time using their on-premises credentials.
I'm super thankful for your response, and maybe I forgot to add the fact that I already have established an IP SEC tunnel and even have an VM in Azure running that is already connected to my on-premise domain (Which I joined manually )
- So with that said, I have the right DNS settings in my sub-network.
Still getting an error when creating the host pool.
But for clarification
I'm going to use my local AD Administrator account, but doesn't this account need to be synced to Azure AD then?
I watched Travis Robert's youtube video
https://www.youtube.com/watch?v=rnLdQSWUi4w&t=817s
And he said that the account needs to be sourced from Azure AD and not from Windows AD.
SamirAbdou1999 Be careful about the info you get from youtube videos, the fall edition of WVD is not the same as the spring update of WVD, but that screenshot in the first post you showed is where you come to the part where you tell to add the machines to the domain, and I'm 100% sure you should be using an on-premises account (in the form of a upn, so something like wvdadmin@youronpremisesdomain.internal). Should that account be joined? I'm not sure, but the demo I got this morning from a colleague had that account synced (she showed me a setup with AADDS, so that naturally is joined), but it just needs to be the account to join to the domain.
However, your second screenshot I saw something with "vmcreation-LinkedTemplate" in the name.. Are you using ARM templates? I've heard of issues before regarding domain joining and those nested ARM templates that are provided by Microsoft.
A quick search gave me something from Azure Academy https://www.youtube.com/watch?v=DrkQFSVD9Ik from which I know who is heavily into WVD at the moment. There may be some info in there too.
The Domain Join account does not need to by synced with AD Connect. The domain administrator account is a protected account and not replicated by default. I’ve used domain admin accounts many times to join session hosts.
Be sure to set the VNet DNS servers to your DC, or domain DNS if they are different. Also, if you have deployed session hosts with the same prefix in the past, you may need to delete the old session hosts from AD or reset the computer account. They can’t join the domain if there are existing computer accounts with the same name.
I have a new version of that video, link in the Fall 2019 version comments. There were some registrations that required an Azure AD global admin account for that version. Now that WVD is ARM, that’s not needed.
For the second host pool error with “Changing property ‘adminUsername’, did you use the back button after the failed deployment and update the domain join account? If so, it looks like you will need to start the deployment over without going back.
-Travis
I'm Super thankful for your respons TravisRoberts
DNS Settings on VNET are costum and this is the IP of the Domain Controller that is on premise.
Note that if I create a new VM in Azure within this VNET I can manually (within windows) join the domain without any problem what so ever.
It is just when I try to do it from the WVD Deployment Portal.
I have tried different prefix names just in case of that reason also.
You mention that the administrator account does not need to be synced to azure ad. Sure.
But, Do i need Azure AD Connect at all at this point then?
As I said earlier in this thread, I have ONLY synced a few users that will use thisI managed to fix this myself.
I want to share the issue and what solution worked for me, and also give a big thanks to all the people that had engagement in this thread.
my on prem AD had the same domain name as my Azure AD tenant.
Also, my on prem AD join user had the same UPN as one of my Office365 users (which is a part of Azure AD Tenant)
So I suppose wvd deployment was trying to authenticate with the wrong catalog, and since I don't have Azure ADDS deployed it failed.
Hope someone troubleshooting this same issue will find this thread.
