Dec 11 2019
- last edited on
Jul 24 2020
I am having problems joining a VM to Azure AD Domain Services. The VM is in the same Vnet as AADDS, but in a different subnet, as the documentation (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/join-windows-vm) suggests.
The VM does have IP-connectivity as I am able to ping both the AADDS nic's IP-addresses from the VM, but when I try to make the VM a domain member I get the good ole "Domain Controller for the domain could not be contacted"..
Since everything else is in order, I am wondering if there is anything I could or should do regarding DNS - since that's what seems to be the problem. I should NOT edit the DNS for the Vnet as this is the same Vnet as AADDS, and the only way I found so far is to edit using a member server. Which I am not able to deploy. Biting my tale over here.
Anyone have any idea what could be wrong, or how I could get out of this mess? Redeploy the whole thing - delete and start over?
Anything helpful is much appreciated!
Dec 13 2019 07:33 AMSolution
What DNS settings do you have on the VNet that the server is a member of?
IP connectivity isn't enough Ii.e. the ability to ping the servers won't allow you to join to the domain). The virtual machine will need to be able to resolve the domain name of your Domain Services instance. What happens when you ping the domain name, and what DNS servers are your VM's receiving at the moment?
I would expect this to work out of the box... I've configured this across disparate VNet instances before, peered, and with DNS servers set on the VM network to match that of the AADDS network. Never with a subnet that's int he same VNet as a DS instance though...
Dec 18 2019 06:57 AM
@Kelvin Papp Thanks for your reply,
I've also deployed this numerous times without any problems. This time it was my own fault, not hitting the big blue button within Azure AD Domain Services to update DNS server settings for the Vnet.
In the end I did manually edit the DNS servers of the Vnet, but ignored this button. The results on the Vnet are the exact same, but now deployed automagicly, and voila! Everything works as expected.