Saturday, 26 September 2015

Azure VM Instance DNS “Default Server” Unknown and Cannot Join the Windows Server 2012 R2 Domain

Today I run into a strange issue related to DNS with my traditional on premise Active Directory and an Azure VM that was to be promoted to a Domain Controller. I was basically extending an Active Directory domain to Azure to test a DR configuration of AD FS.
There is an IPsec Site-to-Site VPN from my corporate network to the Azure tenancy, this is terminated by a Cisco ASA firewall on our site. As you can see the VPN is established and passing traffic without problem. At this stage I will also mention TCP/UDP 53 is allowed both way in the firewall configuration.


In order to promote an Azure VM to a Domain Controller from an already existent Active Directory, Microsoft recommend configuring the Azure vNet to point to one (or more) of the existing DC/DNS servers so that it can join the domain etc. The guidelines are to then change the Azure DNS Servers to the local Azure server, once the VM has successfully became a DC. Microsoft state that DNS Servers should be configured on the vNet themselves instead of statically configured inside the VM’s, this is to ensure the DNS Server settings are retained if the instance is automatically moved to another underlying Hyper-V host by Azure. Azure instances are addressed dynamically by default.


I did just this, under my vNet/Configuration/DNS Servers I configured the entire vNet to look to a Domain Controller which was at 192.168.1.1. The problems started when I logged onto my Azure instance, the DNS Server had been assigned by the internal Azure DHCP as it was my primary name server if I run the nslookup tool.


As you will see from the image above the DNS requested “timed out”, and the Default Server is “unknown”. This is indeed a well-known problem if you do not have reverse lookup’s configured correctly inside your Active Directory DNS. In my case Reverse Lookups were configured and working correctly so that did not solve my problem. It’s worth noting that at this stage I had already defined an Active Directory Subnet and Site for my Azure tenancy.

Obviously without DNS working correctly I could not promote this Azure VM to a Domain Controller, therefore the troubleshooting began. My first port of call was the BPA’s for both Active Directory and DNS, I run both of these and there were no errors returned.
I then decided to check Active Directory’s general health and replication state. The following commands came in handy to do this;

repadmin /replsummary

repadmin /showrepl

repadmin /replsum

repadmin /syncall

dcdiag /a

In this particular environment there was two Active Directory sites, each with a single Domain Controller (it’s a PoC lab). At first I was not paying much attention to the DC in the secondary site, as the VPN from Azure was only terminated to the primary site. Network routes to the secondary site were also not configured. It turns out there was a replication issues between the two DC’s, they had not replicated in over 4 days.


The replication issue was 1722 The RPC Server is unavailable I followed this guide https://technet.microsoft.com/en-us/library/replication-error-1722-the-rpc-server-is-unavailable(v=ws.10).aspx which sorted the problems. I then rebooted the Azure VM and the DNS resolved properly. I suppose it goes without saying before you make any significant changes to an Active Directory always perform a mini-health check on it to ensure it’s working correctly.

1 comment:

  1. Very nice post. Speaking about start-ups and technologies. To my mind, VDR is one of the most growing industries on the world's market. All of the paperwork is left behind and now it is time to go digital, virtual data room features are very convenient for any kind of business.

    ReplyDelete

Comments system

Disqus Shortname