Introduction
|
Azure IAAS (Infrastructure As A Service) can be
used to host your own Domain Controller / DNS servers. This could be done by
starting a new domain from scratch or extending your existing on-promise
domain to the cloud.
Name resolution is a critical configuration item
for DCs and domain-joined computers where DCs should be able to register
their resource records and all domain resources should be able to resolve
them properly. In case of malfunction in this resolution system, your AD
environment may face authentication failures or become not available.
On Windows Azure, Microsoft does not support
using static IPs as all the VMs are managed by DHCP service. By fixing a static
IP, the VM may become unstable or not available anytime. This led many AD
administrators to ask the following question: How can I properly manage DNS
resolution in Windows Azure while my DNS servers cannot have a static IP?
This article provides an answer for this question
by sharing one way to manage DNS servers with Dynamic IPs in the cloud. This
is explained via two Scenarios.
Before starting the two scenarios, please note
that Windows Azure provides a dynamic IP that remains the same for a VM as
long as it was not rebooted. Once rebooted, the VM may lose its IP and get a
new one.
|
Scenario 1: Creating a new AD
domain in the cloud
|
Requirements
|
CONTOSO is a company that would like to create a
new AD domain named contoso.com in Windows Azure. This domain will be
maintained by two Domain Controllers that will have AD-integrated DNS zones.
CONTOSO is also planning to host 100 AD-integrated servers in Windows Azure.
Both Domain Controllers will be used for DNS resolution and the
implementation should not require making manual updates on the IP
configuration of the servers if one of the Domain Controllers reboots and
does not keep its old IP.
The Domain Controllers in the cloud will be named
DC1 and DC2.
|

|
Solution
|
As Microsoft does not support using static IPs
for VMs in Windows Azure and having static IPs is required for DC1 and DC2 to
be used as DNS servers, CONTOSO can use the following approach to manage the
IP settings DNS configuration of their Domain Controllers and AD-integrated
servers:
A file Server named FS1 will be
provisioned in Windows Azure and will be member of a WORKGROUP The Domain Controllers DC1 and DC2
will publish their IPs in a text file stored in a shared folder on FS1 The Domain Controllers and AD-integrated servers
will use the shared text file to keep their IP settings up-to-date: The
updates of IP settings will be managed automatically by Powershell scripts
|
Implementation
|
The first step would be to
provision a new file server named FS1.
|

|
Once provisioned, we will be able to use the File
Server to store the IPs of the DCs. To do that, all we need are:
A shared folder on FS1: In our case, it
will be \\192.168.0.6\DNSIPs (where 192.168.0.6 is the current IP address of FS1) A text file named DNSIPs.txt under
\\192.168.0.6\DNSIPs that contains the name of used DCs and their current IPs
using : format:
|

|
|

|
|

|
|
Now, we have DNSIPs.txt text file
on FS1 that
is contains the DCs IP addresses and is updated in a maximum of five (5)
minutes if a DC has a new IP address.
|

|
DNSIPs.txt will then be
used to implement an automatic update of IP settings DNS configuration for
DCs and AD-joined servers in Windows Azure.
As CONTOSO only have two DCs in Windows Azure,
the following IP settings DNS configuration for the DCs will be used:
|
DC name
|
IP settings DNS configuration
|
DC1
|
Primary DNS server: DC2 IP address
Secondary DNS server: DC1 IP address
Third
DNS server:
127.0.0.1
|
DC2
|
Primary DNS server: DC1 IP address
Secondary DNS server: DC2 IP address
Third
DNS server: 127.0.0.1
|
|
This IP settings DNS configuration
could be maintained on both DCs by using the following Powershell script: The
script will read the DCs’ IP addresses from DNSIPs.txt. If a change was detected
then the IP settings DNS configuration of the DCs will be updated. $server1 and $server2 variables
need to be updated to reflect the desired configuration per DC (See the
previous table). The script can be scheduled run every five (5) minutes on
both DCs
|

|
|
Now, the IP settings DNS
configuration is automatically updated on DCs to reflect the correct IPs of
DNS servers for CONTOSO. The next step would be to do the same but for
domain-joined servers.
|

|
All you need are:
A text file named FileServerIP.txt that
will store the current IP of the File Server FS1 The following Powershell script to run on every
domain-joined server: The script will read the DCs’ IP addresses from DNSIPs.txt.
If a change was detected then the IP settings of the domain-joined servers
will be updated. $server1 and $server2 variables need to be
updated to reflect the desired configuration – In this case, we make DC1 used
as primary DNS server and DC2 as secondary. The script can be
scheduled run every five (5) minutes on domain-joined servers.
|
 |
|
After implementing the script, the IP settings
DNS configuration will be up-to-date on domain-joined servers.
Let’s suppose now that DC1 was rebooted
and has now 192.168.0.8 as IP address. Within five (5) minutes, DC1 will
update DNSIPs.txt text file to reflect its new IP:
|

|
Once updated, the Domain
Controllers and domain-joined servers will adjust their IP settings after
detecting the changes. This is done within five (5) minutes after the update
of the text file.
|

|
This implementation will work properly as long as
the File Server FS1 has not lost its current IP. This means that, as
long as the server was not rebooted, the Domain Controllers and domain-joined
servers can keep their IP settings DNS configuration up-to-date.
To periodically check that FS1 is still
using the same IP address, all you need are:
|

|
A Powershell script that will be
used to periodically check the IP address of the file server, compares it
with the one registered in FileServerIP.txt
and then inform the administrator by mail if the IP was changed. $smtpServer variable
need to be updated to have the DNS name / IP of the SMTP server to use while $sendermail and $receivermail need
to be updated to have the e-mail addresses to use for sending / receiving the
mail notifications.
|

|
|

|
The following script can be
launched manually on an AD-Integrated server having Active Directory
Powershell module to update the local FileServerIP.txt
file on DCs and domain-joined servers (The file becomes to copy up-to-date on
the File Server after that the server detects that its IP was changed). $DN need to be
updated to specify the start of search for servers in AD while $newFileServerIP need
to be updated to specify the new File Server IP address.
|

|
|
Scenario 2: Extending an existing
on-promise AD domain to the cloud
|
Requirements
|
CONTOSO is a company that would like to extend
its existing on-promise AD domain to Windows Azure. CONTOSO already have two
on-promises Domain Controllers and would like to add two Domain Controllers
in Windows Azure that will belong to the same domain. CONTOSO is also
planning to host 100 AD-integrated servers in Windows Azure. Both Domain
Controllers in the cloud will be used for DNS resolution and LDAP queries /
authentication if the on-promise Domain Controllers are no longer reachable.
The implementation should not require making manual updates on the IP
configuration of the servers if one of the Domain Controllers in Windows
Azure reboots and does not keep its old IP.
CONTOSO have implemented a site to site VPN tunnel between their Datacenter
and Windows Azure.
The on-promise Domain Controllers are named DC1
and DC2 while the new Domain Controllers in Windows Azure will be
named DC3 and DC4.
|

|
Solution
|
The solution would be the same as
the one described in the previous scenario. On-promise servers will not be in
the scope of automatic updates for IP settings DNS configuration.
|
Implementation
|
The method discussed for the
previous scenario can be re-used here. However, it is recommended to have at
least one on-promise DNS servers configured as the primary DNS server for DCs
and AD-integrated servers in Windows Azure. DCs in Windows Azure need to be
configured as secondary DNS servers so that if the Site to Site VPN tunnel
between CONTOSO HQ and Windows Azure fails, the DCs in Windows Azure can be used
for DNS resolution and LDAP authentication / queries.
|
Conclusion
|
|
This article shared an idea that
can be used to manage DC/DNS servers with dynamic IPs in Windows Azure. The
described implantation is like implementing an “intelligent” HOSTS file that
can be used by DCs and AD-integrated servers in Windows Azure to identify the
IP addresses of the DNS servers and automatically correct their IP
configuration. By following this method, AD administrators can host Domain
Controllers in Windows Azure for a new domain or as an extension of an
existing domain that can be reliable for DNS resolution. See Also Central Management of DNS Configuration Compliance and
Updates
Active Directory Replication Issues – Basic
Troubleshooting Steps (Single AD Domain in a Single AD Forest)
How to assign a Static
IP to a Windows Azure VM
|