Installing and configuring Active Directory entirely with PowerShell

Creating a new Active Directory for a test environment is something I seem to have to do multiple times a week. I hope to never have to do it the long way with the GUI again.

The following PowerShell commands installed AD DS and creates a new forest/domain called “domain.co.uk”. You are prompted for the AD Restore Password, the rest is automated.

Import-Module ServerManager

Add-WindowsFeature AD-Domain-Services

ADD-WindowsFeature RSAT-Role-Tools

Install-AddsForest -DomainName domain.co.uk -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "Win2012R2" -DomainNetbiosName "DOMAIN" -ForestMode "Win2012R2" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true

Azure VHD Upload Fails “An upload is already in progress on machine HOSTNAME with process ID”

Uploading VHD’s to an Azure Storage Account is straight forward, the following command;

Add-AzureVHD -Destination https://storageaccountcontainer -LocationFilePath “C:\Win7.vhd”

You must create your Storage Account and relevant containers prior to running the command. I tried to upload a VHD, which failed to complete successfully this was due to a network connectivity issue on the client uploading the VHD file.

I tried to run the command again and received the following error “An upload is already in progress on machine HOSTNAME with process ID” even though I knew it had failed.

The fix here was to manually delete the partially uploaded VHD file. This can be done using the Web-GUI if you enter the Container that the original VHD select it and Delete the disk.

Run the Azure command again and the VHD should begin uploading again. 

Configuring Multi-Site VPN for Azure vNet's

It is possible in Microsoft Azure to configure your vNet to terminate multiple IPsec VPN connections to enable you to create mesh-like connectivity between your on premise sites and Azure.

In my example I have two on premise networks Network_A and Network_B, it is very important if you have two networks sharing a vNet gateway that they do not have overlapping address spaces.

            Network_A 10.25.1.0/16 (10.25.0.1 – 10.25.255.254)

            Network_B 10.22.1.0/16 (10.22.0.1 – 10.22.255.254)

The overlaps must also include the Gateway subnet, as this is a network in itself.

One thing to note if you are provisioning your vNet for the first time, is that for a multi-site VPN to be possible your Azure Gateway must be configured to use Dynamic Routing. If you are like me and you are re-configuring an existing gateway you can delete it and recreate it with a Dynamic Routing gateway. You will need to re-run your VPN script on your firewall though, as the Azure Gateway will be assigned a new IP.

Dynamic Routing is also known as Route-based in the context of networking. It is important to ensure your VPN devices support route-based routing. The following link can be referenced to check this;

https://azure.microsoft.com/en-gb/documentation/articles/vpn-gateway-about-vpn-devices/

Before you start your configuration, confirm your VPN devices at each of the sites can support route-based routing.  Surprisingly devices such as Cisco ASA’s and Palo Alto PAN-OS devices are not compatible- they only support policy-based VPNs.

Confirm you want to create a new Azure Gateway. It takes anywhere between 10-30 minutes to provision a new Azure Gateway so be patient.

Before you export your network configuration to XML you must first define the additional local networks that are being used at your other on premise sites.

Enter a descriptive name for the new network, if you forget to do this before you export the network configuration to XML you will be an XML validation error when you do the re-import.

Define the Address Space being used within the site. It is best to ensure your Address Spaces to not overlap, this is an easy mistake to make if you enter a "catch-all" mask to encapsulate the entire Class A, B or C subnet. A work around for overlaps if you do use general network ranges is to manually enter in the exact network ranges used in each of the on premise networks.

At this point you should have all the on premise networks defined under the Virtual Network.

The next step is to export the network configuration to XML. This can be done using the GUI.

You then have to edit the XML file to include your additional Local Networks that have been defined within your vNet.

If you export the network configuration before you define the Local Networks they will not be defined as <LocalNetworkSites> and you will receive a general XML validation error.

In my example script below, I have two Local Networks "Network_A" and "Network_B". The XML should be set like it is highlighted below (the variable is the local network name).

<Gateway>     <ConnectionsToLocalNetwork>       <LocalNetworkSiteRef name="Network_A"><Connection type="IPsec"   /></LocalNetworkSiteRef>       <LocalNetworkSiteRef name="Network_B"><Connection type="IPsec"   /></LocalNetworkSiteRef>     </ConnectionsToLocalNetwork> </Gateway>

Save the XML file and return to the Azure Portal. Use the New wizard and select Network Services, Virtual Network and Import Configuration.

Browse for the edited XML file and click Next. The XML is validated before the import can complete, if Azure does detect a syntax error in the code it will state exactly what line is causing the problem.

Once the import is completed, the next step is to import the configuration script automatically generated by Azure. This script should be imported into each of VPN devices. It is important to read and understand the configuration script, as there are some assumptions made by Azure.

For example, the default configuration script creates an Internet Key Exchange (IKE) policy with a number of 10, if you have used this for another VPN tunnel you could cause a conflict on your firewall which could cause an outage.

Multi-Site VPN’s with Microsoft Azure and Hardware VPN Concentrators (Cisco ASA's)

Although it’s possible to terminate multiple VPN (multi-site) into a single Azure vNet, there are some limitation around the VPN hardware you use to do this. The following document from Microsoft outlines all of the supported VPN devices to work with Azure.

https://azure.microsoft.com/en-gb/documentation/articles/vpn-gateway-about-vpn-devices/

If your project requires multi-site VPN, the important column to review here is the Route-based, in short if you want to terminate multiple VPN’s into a single vNet your VPN device must support Route-based.

This is somewhat confusing as Route-based also means Dynamic Routing

·         Static Routing = Policy-based

·         Dynamic Routing = Route-based

The difference between the two is, Policy-based routing encapsulates and encrypts traffic and then forwards it out a specific interface according to an Access Control List. Route-based routing on the other hand forms dedicated tunnels with a neighbouring VPN device and forwards all of the traffic across this tunnel.

The Microsoft documentation to create a multi-site VPN states that the Azure vNet Gateway must be created as a Dynamic Routing gateway, or in other words a Route-based gateway.

https://azure.microsoft.com/en-gb/documentation/articles/vpn-gateway-multi-site/

This is to allow multiple VPN connection to be terminated into the vNet. If you are using the Cisco ASA for example this will not work, if you check the supported devices list above. The Cisco ASA does not support Route-based routing. In reality if your vNet is configured to use Dynamic Routing and you try and connect it to a Cisco ASA it simply does not work.

In short this basically means that if you have two sites with Cisco ASA’s you cannot create a multi-site VPN to Azure. There is a very small amount of hardware supported for such a topology by Microsoft.

Unless you are running one of the following you basically can’t do multi-site VPN to Azure (these are the only supported device for multi-site VPN);

·         Checkpoint Security Gateway

·         Cisco ISR, ASR

·         Dell SonicWALL

·         Fortinet

·         Juniper SRX, J-Series, ISG, SSG

·         Windows RRAS

The “work around” that doesn’t work

There are a number of forums on the Internet listing this exact problem with ASA’s, Palo Alto’s etc. and some people claim the ingenious workaround is to;

·         Create two separate vNet’s (one for each site you want a VPN from)

·         Create two VPN’s from each of the sites, terminating into their own vNets

·         Create a vNet to vNet VPN between the two separate vNets

I must admit before I did some research on this I did think this could be an option, but again if you review some of the Azure documentation you will notice that for any vNet to vNet VPN you must also create your Gateway using Dynamic Routing.

 

 

 

The bottom line

 

In summary as of January 2016, if you are running a Brocade, Citrix, Palo Alto, WatchGuard, F5, Barracuda or Cisco ASA firewall you cannot create a multi-site VPN to an Azure vNet.