blue UTP cord

Join an Azure VM to an AD Domain (in Azure)

In this article I show you, how I could handle to join an Azure VM to an AD Domain that runs on Azure VMs. No AADS or similar, really a DC running on Azure. This scenario is quite common for test- dev- or demo environments.

My scenario is configured like this:

  • I work with ARM and have a dedicated resource group.
  • The resource group is hosting an own VNet with an address space 10.0.0.0/16. I’ve left the default from Azure to keep my lab environment as easy as possible.
  • Azure VM (sizing DS1_v2) that is running a Domain Controller on Windows Server 2016. I don’t need high availability for now, so there is only one DC.
  • Azure VM (sizing B2ms) that will run a tiny Exchange Server.

The installation of the Domain Controller was straight forward: after setting up the VM, I patched it – as usual – and then ran the wizard for ADDS installation with dcpromo for the configuration. DNS is also included. After that I’ve modified the Azure subnet and added the DCs IP address to the default DNS servers (so that all future VMs will also ask my DC when querying DNS):

This setting is inherited very well to the VM’s NIC:

In my case I also configured the local DCHP IP as static, this depends on the server and role if it is necessary. Because I need an Exchange Server, a static IP is good.

Now, after happy patching, IP-assigning and the organizational stuff that needs to be done on a server, I tried to join it to my domain. It always ended up in that error – no matter if I used the NETBIOS name, FQDN or IP address oy my DC:

The DC can be pinged, so it is reachable in general. Here is what I’ve tried (after googling and binging around for several hours and collecting possible solutions):

All steps did not lead to success. So I started trying things anyone should probably not do in Azure because of the risk of connectivity loss. But hey, it is a lab, it is an empty server – if I lock out myself completely – who cares, then i create a new VM and delete this one. So here is what I did next:

In the IP settings of the Azure VM (just to make it clear: all actions are done on my Exchange Server, not the DC) I change the settings of the IPv4 protocol:

First I manually added the DC as primary DNS server (that may be optional, but it worked for me):

Now I continue in Advanced and set the following in DNS settings:

The DNS suffix must match the FQDN of your AD Domain. All that forces the VM to talk to my DC directly in any case. After the settings are saved with OK the connection to the Azure VM gets lost (I am connected with RDP, a TeamViewer Session may survive, I didn’t try that). It isn’t even reachable via RDP anymore. You remember I said earlier in that article that it may be a bad idea to change the network adapter settings manually? That is the proof.

But that is where the magic begins. The VM itself remains unavailable. So during my troubleshooting I thought “hm okay, Azure has a reset feature, I’m gonna try that. Hopefully it will reset all network settings”. So here is my advise: Reset your VM after adjusting the network settings:

That process doesn’t need much time, only approx. 1 or 2 minutes:

After some waiting you see the notification about the successful redeploy in the Azure notifications center:

That is exact moment when you can try to reconnect via RDP. And it worked! The connection can be established again and the IP settings are exactly how they were configured above, so the Azure VM is forced to directly communicate with the Domain Controller.

Now the domain join works fine by using the FQDN of the domain:

All you need to do now is a reboot. The logon with a domain account works fine (e.g. a domain admin to install the server). You can signin with your account using DOMAIN\USER syntax and verify with the command line command whoami that you are really signed in with a domain user.

Using that workaround, I could join 3 Windows Servers and 1 Windows 10 Client without any problem in a short time. One day I am gonna find out what Azure exactly does in the background with these networking options and the redeploy tool. For now I am happy that I’ve found a working workaround 🙂

Published by Andreas

Founder of M365 Evangelists Cloud-Architect, Strategy Consultant, Consultant for Microsoft technologies, Graph API enthusiast, PowerShell enthusiast
%d bloggers like this: