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.