Disclaimer: Use this solution at your own risk. What I describe here is purely my practical observation and is based on repeatable reproduction. Things might change in the future.

The foundation pillar for my setup is the following (totally mine!) statement: The first Virtual Machine you create into an empty Virtual Network in Windows Azure will get the 4th IP Address in the sub-net range. That means, that if your sub-net address space is 192.168.0.0/28, the very first VM to boot into that network will get IP Address 192.168.0.4. The given VM will always get this IP Address across intentional reboots, accidental restarts, system healing (hardware failure and VM re-instantiating) etc., as long as there is no other VM booting while that first one is down.

First, lets create the virtual network. Given the knowledge from my foundation pillar, I will create a virtual network with two separate addressing spaces! One addressing space would be 192.168.0.0/28. This will be the addressing space for my Active Directory and Domain Controller. Second one will be 172.16.0.0/22. Here I will add my client machines.

Next is one of the the most important parts – assign DNS server for my Virtual Network. I will set the IP Address of my DNS server to 192.168.0.4! This is because I know (assume) the following:

The very first machine in a sub-network will always get the 4th IP address from the allocated pool;

I will place only my AD/DC/DNS server in my AD Designated network;

Now divide the network into address spaces as described and define the subnets. I use the following network configuration which you can import directly (however please note that you must have already created the AffinityGroup referred in the network configuration! Otherwise network creation will fail):

Let's add some clients to it. Create a new VM from gallery. When prompted, add it to the Clients sub-net. When everything is ready and provisioned, log-in to the VM (RDP). Change the system settings – Join a domain. Enter your configured domain name. Enter domain administrator account when prompted. Restart when prompted. Voilà! Now my new VM is joined to my domain.

Why it works? Because I have:

Defined DNS address for my Virtual Network to have IP Address of 192.168.0.4

Created dedicated Address Space for my AD/DC which is 192.168.0.0/29

Placed my AD/DC designated VM in its dedicated address space

Created dedicated Address Space for client VMs, which does not overlap with AD/DC designated Address Space

I put client VMs only in designated Address Space (sub-net) and never put them in the sub-net of AD/DC

Of course you will get same result if with a single Address Space and two sub-nets. Being careful how you configure the DNS for the Virtual Network and which sub-net you put your AD and your Client VMs in.

This scenario is validated, replayed, reproduced tens of times, and is being used in production environments in Windows Azure. However – use it at your own risk.

One of the reasons for new address space is to avoid client machines grabbing the 192.168.0.4 in case DC is temporary down. The other is security isolation - much easier to maintain security and firewall rules when I have separate address spaces, rather then just a subnet within same address space.

Hi Anton, Great timing and very good stuff. As of now I am doing exactly the same thing and after a few tries (and a few attempts at creating AD VMs) I had realized that 192.168.0.4 needs to be set up as the preferred DNS server in the VNet config before any compute resources is assigned to my VNet.While everything else works fine, one problem I see is that DNS always fails to resolve any domains that belong to MS Azure properties, like *.cloudapp.net, *.windowsazure.com, *.accesscontrol.windows.net and such. Have you faced a similar issues yourself? Any hints on what might be wrong?

Thanks for this article Anton. I'm running into an issue where I can't create the Domain Controller VM within a virtual network as you describe because of the following :Allocation failed; unable to satisfy constraints in request. The requested new service deployment is bound to an Affinity Group, or it targets a Virtual Network, or there is an existing deployment under this hosted service. Any of these conditions constrains the new deployment to specific Azure resources. Please retry later or try reducing the VM size or number of role instances. Alternatively, if possible, remove the aforementioned constraints or try deploying to a different region.

As for creating multiple DC for high availability - there is no technical issue to stop from deploying more than one DC. I would just put both in their own designated sub-nets. To be absolute sure about both IP addresses.

As for unable to resolve MSFT (Microsoft) propriety domains - this is known issue which happens under certain circumstances and hopefully there will be a fix soon for it. The workaround is to use FQDN when navigating to such site. Please note that FQDN includes a trailing dot at the end of the domain name (i.e. blogs.staykov.net. and not just blogs.staykov.net )!

Anton, I use Your instruction but can You help what am I doing wrong? Should there be two AddressSpaces or one is enough? I posted my question on forum more detailed, maybe You will see it if have free time?

Disclaimer

This is my personal blog space. Everything which I write here or anywhere on the web is solely my own subjective opinion and shall not be associated (neither affiliated) with any company - neither the company I currently work for, nor any company I have worked for in the past. Use the information and any code / links provided at your own risk.