There are many reasons you might want to extend your Microsoft Windows Active Directory (AD) forest into Microsoft’s public cloud — Windows Azure. Microsoft announced in June 2012 that Infrastructure as a Service (IaaS) features such as Virtual Machines (VMs) were available in Windows Azure. While still in a “trial” phase after six months, Microsoft has continued to add new functions to Azure and publish new prescriptive guidance about using Azure IaaS with Microsoft products.

Running and extending AD into Azure

An important Microsoft document, “Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines” was published in October 2012. Directory, enterprise, and cloud architects appreciate–and can rightfully insist on–Microsoft publishing “best practices” for key architectures as they apply to Windows Azure. Following these architecture frameworks reduces risk by creating common and public ground rules that, when followed, enable the Microsoft ecosystem to work at its best.

Microsoft accelerates the adoption of Azure IaaS by empowering customers and partners to keep pushing the limits on what’s possible with Azure IaaS. To extend AD services such as directory and authentication to VMs in Azure, an architect can now start to include Domain Controllers (DCs) and Read-only DCs (RODCs) in Azure as part of a design or solution. Microsoft lets you BYON (bring your own network) into Windows Azure, so it’s technically feasible to securely connect on-premise, WAN, and private cloud networks with Azure virtual networks.

Drivers towards extending AD into Azure

Once you have a bunch of VMs in the Azure cloud that are joined to your on-premise domain, you will discover that having a DC or RODC in the same Azure virtual network might be a good idea. Here are some technical and business drivers for this:

  1. Latency in the AD authentication because the traffic is moving at Internet speed rather than LAN speed. AD client processes like Kerberos are sensitive to timing. Some Azure virtual network connections can prove too slow for demanding applications or those with short authentication timeouts.
  2. Resiliency of the applications running on the IaaS VMs. Consider that should the Azure virtual network to the on-premise DCs fail, AD-based operations in the cloud will cease. However if there is an AD replica in Azure, such as that found on a DC or appropriately configured RODC, then the Azure cloud can survive temporary loss of connectivity to the on-premise network.
  3. Azure download bandwidth charges are saved by keeping AD-related network traffic such as DNS and LDAP in the cloud. There is no charge for uploads into Azure, so an RODC in Azure, which has no outbound replication channel, will save money compared to having Azure VMs use the Azure virtual network for all AD traffic.
  4. You may just need AD in Azure, not necessarily to extend your existing AD into Windows Azure using Azure virtual network; in fact, you may deploy AD completely within your Azure virtual network. A self-contained AD that lives only in your Azure cloud might provide directory and authentication services to elastic clusters or farms of computers that have no need for authentication with an on-premise AD.

Create an AD site in Windows Azure

Microsoft makes clear that Azure VMs hosting AD DS roles differ little in terms of how you would employ and manage DC and RODC roles on VMs in any virtualization environment. Windows Azure is fundamentally a massive network of Hyper-V hosts, so general precautions about ensuring AD recoverability when AD is deployed on VMs apply to VMs in Azure.

A simple issue to overcome involves Azure IaaS VMs always having dynamically-assigned network addresses. Actually, Azure IaaS VMs will receive addresses in the network subnet you specify during configuration of the Azure virtual network. Also, the dynamic addresses are permanent for the lifetimes of the VMs. So you can ignore DCPROMO warnings about DCs having dynamically assigned addresses and treat the Azure addresses as permanent-while keeping the VM’s network interface set to use DHCP.

Since Azure virtual network setup will force you to define a specific subnet for servers, the server subnet(s) you specify should naturally be defined in AD Sites and Services. This is something you should do as soon as you establish an Azure virtual network and before joining Azure VMs to the on-premise domain. DCs and RODCs promoted in the Azure virtual network will be correctly associated with the new AD site for Azure that you will create. Conventional IP site transport is used for AD replication. Figure A shows how an RODC in Azure looks-like any other AD site with an RODC.

Figure A

Create subnets for Azure virtual networks, and install Azure-based DCs and RODCs in their own Azure site(s).

Provision a DC with the Azure data disk type

Here is the really important and special detail when it comes to domain controllers in Azure: You must add an additional disk to the Azure VM that will be a DC, before running DCPROMO. This second disk must be of the “data” type, not the “OS” type. The C: drive of every Azure VM is of the “OS disk” type, which has a write cache feature that cannot be disabled. Running a DC with the SYSVOL on an Azure OS disk is not recommended and could cause problems with AD.

This means you must not perform a default installation of DCPROMO on an Azure VM, but rather you attach a data disk, then run DCPROMO and locate AD files such as SYSVOL on the data disk, not the C: drive. This link at Microsoft has checklists to add an Azure VM data disk or attach an empty data disk:

Note about a different product: Take into account there is another Microsoft product, Windows Azure Active Directory, which is essentially an outsourced AD that lives completely and only in the cloud. That service appeals to Microsoft Office 365, Dynamics CRM Online, and Windows InTune customers-and that service is NOT the topic of this article. This article introduces the concept of running conventional Windows Server VMs with the AD Directory Services (AD DS) role installed in Windows Azure, particularly as part of hybrid cloud including on-premise and/or private cloud AD.