Deploying replica DCs in Microsoft Azure

September 28, 2015 at 7:22 pm in Azure, Cloud, DC, IaaS by Wim Matthyssen

Hi all, my next blogs posts are a step by step series on how to deploy additional domain controllers (replica DCs) on IaaS virtual machines (VMs) in Microsoft Azure to extend the on premise Active Directory domain to Azure. The different parts provide details about the process of creating the necessary Cloud Service, creating the necessary Storage Accounts, deploying the servers, configuring Active Directory Domain Services (AD DS) and all other necessary steps for a secure and stable expansion of your AD to Azure.

So bookmark this post to get regular updates when new topics are available!

Below, you can find the setup Visio diagram:

clip_image002

Before we get started there are a number of import remarks you should know about before deploying this solution. Please read them all carefully.

  • A Site-to-Site (S2S) VPN needs to be set up (ExpressRoute is also an option if a faster and more secure connection is needed) to connect the Azure Virtual Network (VNet) with the on-premises network (Cross-Premisse Connectivity)
  • You need to provide your own DNS infrastructure to support AD DS on an the Azure VNet because the Windows Azure-provided DNS infrastructure does not support some features that AD DS requires, such as dynamic SRV resource record registration.
  • It is a good idea to create a site in Active Directory that represents the network region corresponding to the VNet. That helps optimize authentication, replication, and other DC location operations.
  • In this series I will use IaaS V1 VMs to set all things up.
  • You should shut down and restart a VM that runs the DC role in Azure within the guest operating system instead of using the Shut Down option in the Azure Management Portal. Today, using the Management Portal to shut down a VM causes the VM to be deallocated. A deallocated VM has the advantage of not incurring charges, but it also resets the VM-GenerationID, which is undesirable for a DC. When the VM-GenerationID is reset, the invocationID of the AD DS database is also reset, the RID pool is discarded, and SYSVOL is marked as non-authoritative.
  • By default, the AD DS installation process installs the AD DS database and SYSVOL in the %systemroot% folder, which is NOT recommended for Azure. So ensure that the DCs have an additional data disk (With NO caching) added to the DCs VMs. Store the NTDS and SYSVOL content on this data disk. This is to prevent data corruption in case of recovery, as data disks with NO caching ensures that the all the committed transactions are written to the database/disk. Because failure to disable write caching may, under certain circumstances, introduce USN rollback resulting in lingering objects and other problems.
  • For security reasons it is advisable to install an antivirus on every VM running on Azure. For an additional cost antivirus extensions can be added to all VMs trough the Azure Management Portal.
  • Windows Azure does not push Windows Updates to Windows Azure VMs since these machines are intended to be managed by the user. This is just like any on-premises machine.
  • Hackers utilize brute force tools that try frequently used usernames and passwords.  So the first step is to make sure and utilize complex usernames and passwords for your VMs. That’s why using a local admin with the name Administrator is not a good idea.
  • Its preferable to have the Global Catalog (GC) and DNS roles on the replica DCs. This reduces the traffic going to the GCs on-premises for evaluating the universal group membership. And you know, inbound data to Azure is free, but outbound data is charged based on the total amount of data moving out of the Windows Azure datacenters via the Internet in a given billing cycle (first 5 GB of outband data per billing month are free).
  • Endpoints allow you to communicate with your Azure VM from the Internet.  When creating a Windows VM in Azure, two endpoints get created by default to help you manage the VM – Remote Desktop and PowerShell.  The first recommendation is to eliminate any endpoints you do not need and to only add them when and while you need them.  If you must have an endpoint open, the recommendation is to change the public port that is used whenever possible. Creating a S2S VPN connection between your on-premises network and your VNet in Azure gives you a secure, dedicated, IPsec tunnel for communicating.  With a S2S VPN connection in place, you can completely remove certain public endpoints and then just connect via the internal ports like you would with any other machine on your internal network.  For example, you could remove the Remote Desktop endpoint in your VM and then just connect directly to the VM over the standard RDP port 3389 via the secure VPN tunnel.

Herewith you will find my blog series topics to get all things up and running:

1) Create the Cloud Service and Storage Accounts

2) Create the VMs with Azure PowerShell

3) Create the Active Directory site for the Azure VNet

4) Initialize and format the additional data disk

5) Adjustment of some server settings before promoting the DCs

6) Add the Active Directory Domain Services role

7) Promote the Azure IaaS VMs to a Domain Controller

8) Domain Controller Health Check

9) Manage the Time Configuration settings on the DCs

10) Transferring FSMO roles to the IaaS DCs

11) Switch DNS servers for the VNet

12) Removing the Azure Endpoints

Hope it helps!

Wim Matthyssen (@wmatthyssen)

Share on LinkedInTweet about this on TwitterShare on Google+Share on Facebook