Deploying Domain Controllers in Azure

When deploying VM’s in Azure, there are some things you should be aware of depending on the roles you’re going to use. One of them is Active Directory Domain Controllers which I’ll go through in this post.

You should consider your goal before deploying any Domain Controllers. Are you going for a hybrid setup with on-premise and Azure DC’s with a site-to-site VPN? If so, you should create AD sites with associated subnets, site links etc. Another thing to consider is replication, how often do you want to replicate data between your DC’s? These things are not specific to Azure, but people tend to forget them. 

Public IP’s
When using Azure your VM’s are placed in “Cloud Services” which has an external IP address. Standard configuration when creating a VM is to NAT remote desktop (RDP) and PowerShell (WinRmHTTPs) ports to your servers. This means you – and other people! – can access the servers remotely using a public IP. You probably don’t want this, so consider removing the endpoints when you create the VM. See below how you do this.

Through the portal:
Go to Virtual Machines in the portal:

Select the VM:

Click on Endpoints:

Select the endpoint you want to delete:

Choose delete in the bottom of the page:

With PowerShell:
You can use Get-AzureEndpoint to list the Endpoints:

[powershell]Get-AzureVM -ServiceName jjlab -Name DC1 | Get-AzureEndpoint

LBSetName :
LocalPort : 3389
Name : RDP
Port : 51403
Protocol : tcp
Vip :
ProbePath :
ProbePort : 0
ProbeProtocol :
ProbeIntervalInSeconds :
ProbeTimeoutInSeconds :
EnableDirectServerReturn : False
Acl : {}[/powershell]

And Remove-AzureEndpoint with Update-AzureVM in the end. Important to remember the update:

[powershell]Get-AzureVM -ServiceName jjlab -Name DC1 | Remove-AzureEndpoint -Name RDP | Update-AzureVM[/powershell]

In order to get 99.95% uptime we need to deploy 2 or more instances of the same VM role (DC in this topic). This is partly because Microsoft patches it’s Azure hosts regularly and VM’s are not live migrated between hosts. Therefore it’s important to add your VM’s to availability sets which encures that your VM’s a placed in different fault domains (which basically is just different racks) in the datacenter. That way Microsoft can update the host in one rack without affecting both your VM’s.
In case you have web servers that depend on SQL servers or similar you should deploy at least 2 of each and add them to different availability sets, for examples WEB01 + SQL01 to AvailabilitySet01 and WEB02 + SQL02 to AvailabilitySet02.

How to do it in the portal:
After you’ve selected the VM, click on Configure:

Choose to create a new Availability Set and give it a name:

Click save:

With PowerShell:

[powershell]Get-AzureVM -ServiceName jjlab -Name DC1 | Set-AzureAvailabilitySet -AvailabilitySetName DC_AvailSet | Update-AzureVM[/powershell]

File locations
Operating System disks in Azure uses read and write caching by default which is not recommended for roles like AD, because there’s a risk of losing data in the event of a VM failure. You should attach a second disk to your VM through the portal or using PowerShell, and place NTDS and SYSVOL folders on this disk.

Using the portal:
On the VM click Attach and then Attach empty disk:

Give the disk a name so you can identify it in the future, specify the size (you only pay for what you use, so you can make this as big as you want up to 1023 GB) and select None on Host Cache Preference:

With PowerShell:

[powershell]Get-AzureVM -ServiceName jjlab -Name DC1 | Add-AzureDataDisk -CreateNew -DiskLabel DC1-Datadisk -DiskSizeInGB 10 -LUN 2 | Update-AzureVM[/powershell]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s