Connecting Networks

Assuming everything is in order, you need to lay the foundation to connect your local network with the Azure network. To do this, you set up a site-to-site VPN that you configure on both the local network and in Azure. In Azure, this configuration involves three steps: First, you set up a local area network. This network includes, as the name implies, the on-premises IP address space plus a public IP address for the VPN gateway. You then register a DNS server from the local AD, which will later be used by the VMs in Azure. Finally, you create the virtual network, consisting of the appropriate subnets.

In Azure, all three settings for this procedure are available in the classic portal in the Networks section of the left navigation bar. The configuration of the DNS servers and the local network is self-explanatory. During the configuration of the virtual network, select the previously created local network and the DNS server you added. Figure 2 shows the settings of the subnets used to create the virtual network. What is not shown is the dynamic gateway, which is activated via the same link (located at the bottom of the dashboard for the virtual network) with a single click.

Figure 2: Dividing the different address ranges for a virtual network.

You do not need certificates, by the way. Certificates are only necessary for a point-to-site VPN. In this example, Azure uses a shared secret for the connection with the remote access server. After completing all three steps in Azure, continue with the settings on your local network.

A pre-built script helps to configure the VPN device on the local network; Azure generates this script based on network information you furnished. You will find the script in the dashboard of the newly created virtual network by following the Download VPN Device Script link (Figure 3). Azure supports various network equipment manufacturers, including Juniper and Cisco.

Figure 3: Downloading the pre-built VPN script.

As an example, select Windows Server 2012 R2 as a remote access server, and you are given a config file; now rename the extension to .ps1. When run in PowerShell, the script configures the local RAS server without any manual intervention.

You can see the successfully established tunnel connection in the dashboard of the virtual network. If the remote access server is restarted, or is temporarily unavailable for some other reason, Azure attempts to restore the connection (Figure 4). For more details on the topic of networking, search the Azure document library.

Figure 4: In the case of an interruption to the VPN connection, Azure automatically tests whether it can be recovered.

Creating the Azure VM

Next, I will create the virtual machine for the first DC; use the classic portal for this purpose. First,you need to create the cloud service and the storage account for the VM. It is important that both follow a special notation: Additionally, the cloud service should be a public name that is unique on the Internet. The input is checked directly with a message telling you whether the names are valid.

Now you can create the virtual machine. Select the image Windows Server 2012 R2 with a size of A1 , which is sufficient for a domain controller. The rest of the settings are self explanatory, except for one: Select the previously created subnet for the DCs – in this case, DCSubnet . This will ensure that the DHCP server is equipped with the necessary configuration and takes notice of the on-premises DNS server.

After the VM becomes available, open the dashboard for the VM. The dashboard gives you an overview of all the relevant data for the server. From here, you can also download an RDP file that takes you to the server via a Remote Desktop connection.

Preparing Active Directory

From an AD perspective, the new Azure site is just another site across a VPN connection. In the AD Sites and Services management console, create the subnet and the site based on the information from Azure. The name for the site is arbitrary. After the DCPROMO (when DC is promoted) process, the DC ends up on the right AD site thanks to its IP configuration.