The following guide assumes that the user has basic knowledge of using Windows. Although some familiarity with PowerShell scripting and the Azure Portal would be beneficial, it is absolutely not necessary, as the scripts are being provided in their entirety and screenshots are shown as of where and how to discover the necessary components in the Portal and Resource Explorer.


The following prerequisites must be met, before performing the ExpressRoute connection steps.

  • Internet connection
  • Valid Azure Subscription
  • ExpressRoute Circuit must have been provisioned from the provider’s side (BT, Equinix, etc.)
  • The person who will perform the below steps must have one of the following roles in the Azure subscription
    • Owner
    • Contributor
  • Latest version of Microsoft .NET Framework (download link)
  • Latest version of Microsoft Windows Management Framework (download link)
  • Latest version of Microsoft PowerShell (download link including detailed installation guide)
  • Latest version of Azure cmdlets (installation guide), although steps are provided below
  • Some familiarity with PowerShell ISE, although not necessary (documentation)
  • Some familiarity with the Azure Portal would be beneficial, although not necessary
  • Some familiarity with PowerShell scripting would be beneficial, although not necessary

Only subscription Owners and Contributors have the access level to perform the below activities.

Windows PowerShell and Windows PowerShell ISE

PowerShell is an automation platform and scripting language for Windows and Windows Server that allows for simplified management of Microsoft systems. Unlike other text-based shells, PowerShell harnesses the power of the .NET Framework, providing rich objects and a massive set of built-in functionality for taking control of Windows environments. As such, PowerShell can be used to communicate with the Azure APIs in an automated format, completely eliminating the need to use the Portal, speeding up deployment and configuration times.

PowerShell Azure cmdlets Overview and Installation

In order to successfully communicate with the Azure APIs, the Azure cmdlets for PowerShell need to be installed, which are a set of modules that provide the ability to manage Azure with Windows PowerShell. The cmdlets can be used to create, test, deploy, and manage solutions and services delivered through the Azure platform.

The Azure PowerShell can be downloaded from the following link: http://aka.ms/webpi-azps

After the installation is complete, within PowerShell, please type the following command:

PS C:\> Get-AzureRmResource

If the following Error occurs:

Get-AzureRmResource : The term 'Get-AzureRmResource' is not recognized as the name of a cmdlet, function,script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Get-AzureRmResource
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (get-azurermresourcefork:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

The machine must be restarted and the cmdlets need to be imported from:

C:\Program Files\WindowsPowerShell\Modules\Azure\XXXX\ as following (where XXXX is the version of PowerShell installed:

import-module "C:\Program Files\WindowsPowerShell\Modules\Azure\XXXX\azure.psd1"

import-module "C:\Program Files\WindowsPowerShell\Modules\Azure\XXXX\expressroute\expressroute.psd1"

Alternatively, the cmdlets can be installed from the PowerShell Gallery:

# Install the Azure Resource Manager modules from the PowerShell Gallery
Install-Module AzureRM

PowerShell ISE

The PowerShell Integrated Scripting Environment (ISE) is a Windows application that supports enhanced usage of PowerShell for beginners and experts alike. The ISE’s many features include:

  • A built-in editor for writing, testing, and debugging scripts
  • Full IntelliSense tab completion, syntax highlighting, and context-sensitive help
  • Support for right-to-left languages
  • Extensible add-ons

Windows PowerShell ISE can be found by searching for “ISE” in the search area of Windows 7/8/10 (see Figure 1).


Figure : Finding PowerShell ISE in Windows

In the ISE window (see Fig. 2), the “New” icon (1), creates a new Untitled.ps1 (2) empty script.


Figure : Example view of PowerShell ISE window

Once the script is complete, upon saving it, a new name must be provided (see Fig. 3).


Figure : Saving a script

Finally, hitting the run button (see Fig. 4) will run the script and give the output in the blue console, at the bottom of the ISE window.


Figure : Running a script with example output

Azure Resource Explorer

Apart from Azure Portal (https://portal.azure.com), the created resources/components can be found in the Resource Explorer (https://resources.azure.com), where all resources are shown in JSON format. Login with the Azure credentials is required and all subscriptions and components can be browsed in a grouped, drop-down menu fashion, removing all the “visualisation” part of the Portal, making it easier to find IDs and internal components of the various resources (see Fig. 5).

It also provides the capability to search by name, similarly to the Azure Portal search capability, which leads directly to the desired resource JSON object, effectively eliminating the need to manually browse through the resources.

Finally, due the fact that it communicates with the Azure API and gets the resources in their native format as represented in Azure, skipping the visual part, it is sometimes the only way to find specific details. An example can be seen below, as the drop down list under the AZ-EC-ER-EXCIR001 ExpressRoute Circuit is the only way to see the Authorisation Keys in order to use this circuit (explained in detail later).


Figure : Resource Explorer View of ExpressRoute

ExpressRoute Provisioning

Express Route is firstly provisioned through the desired provider in “blocked” state and once the connection process is about to begin, the provider has to unblock in “Enabled” status, for the rest of the process to take place.

The high level steps are as follows:

  • Create and provision the ExpressRoute object in the Azure subscription (guide Link)
  • Generate the ExpressRoute Service Key
  • Send the ExpressRoute Service Key to the ExpressRoute provider of your choice
  • Provider provisions the ExpressRoute circuit on their side
  • Upon successful provision, ExpressRoute status changes to “Enabled” in the Portal, allowing for the rest of the process to be completed

Although it is provisioned with the pre-agreed configuration, the settings can be changed through either the portal (Fig. 6) or via PowerShell.

Figure : ExpressRoute View in Azure Portal and Configuration


Once the Billing Model is changed from Metered to Unlimited, it cannot be reverted back.

Similarly the bandwidth on an ExpressRoute connection can be increased without too much effort (i.e. agreement with provider), however decreasing the bandwidth will result in a new S-Key being generated which may require an entire tear-down of the ExpressRoute circuit

PowerShell Script 1 – Creating New ExpressRoute Circuit

# Pass Azure Credentials
$azureAccountNameEA ="<Your Azure Username>"
$azurePasswordEA = ConvertTo-SecureString "<Your Azure Password>" -AsPlainText –Force

# Create the Login object
$psCredEA = New-Object

# Set credentials
System.Management.Automation.PSCredential($azureAccountNameEA, $azurePasswordEA)

# Automatically login to Azure using above credentials
Login-AzureRmAccount -Credential $psCredEA

<# Get the list of supported providers, locations, and bandwidths, make a note of the following information because you'll need it later when you create a circuit:
- Name
- PeeringLocations
- BandwidthsOffered


<#Sample output is seen below for Service Provider "British Telecom"
Name : British Telecom
Id : /subscriptions//resourceGroups//providers/Microsoft.Network/expressRouteServiceProviders/
ProvisioningState : Succeeded
Type : Microsoft.Network/expressRouteServiceProviders
PeeringLocations : [
"Hong Kong",
"Silicon Valley",
"Washington DC"
BandwidthsOffered : [
"OfferName": "50Mbps",
"ValueInMbps": 50
"OfferName": "100Mbps",
"ValueInMbps": 100
"OfferName": "200Mbps",
"ValueInMbps": 200
"OfferName": "500Mbps",
"ValueInMbps": 500
"OfferName": "1Gbps",
"ValueInMbps": 1000
"OfferName": "2Gbps",
"ValueInMbps": 2000
"OfferName": "5Gbps",
"ValueInMbps": 5000
"OfferName": "10Gbps",
"ValueInMbps": 10000
#Create a Resource Group which will host the Express Route (if it already does not exist)
New-AzureRmResourceGroup -Name "<ResourceGroup Name>" -Location "<Location>"

#Create the new ExpressRoute Circuit
New-AzureRmExpressRouteCircuit -Name "<ExpressRoute Circuit Name>" -ResourceGroupName "<ExpressRoute ResourceGroup Name>" -Location "<Location>" -SkuTier Standard -SkuFamily MeteredData -ServiceProviderName "<Service Provider Name>" -PeeringLocation "<Peering Location>" -BandwidthInMbps <bandwidth required e.g.50>
PowerShell Script 2 – Uplifting an Existing ExpressRoute Circuit

# Pass Azure Credentials
$azureAccountNameEA ="<Your Azure Username>"
$azurePasswordEA = ConvertTo-SecureString "<Your Azure Password>" -AsPlainText –Force

# Create the Login object
$psCredEA = New-Object

# Set credentials
System.Management.Automation.PSCredential($azureAccountNameEA, $azurePasswordEA)

# Automatically login to Azure using above credentials
Login-AzureRmAccount -Credential $psCredEA

# Select the subscription where the ER is provisioned
Select-AzureRmSubscription -SubscriptionId <the subscription id WITHOUT QUOTES>

# Get the ExpreeeRoute circuit object into the variable
$ckt = Get-AzureRmExpressRouteCircuit -Name "<ExpressRoute Circuit Name>" -ResourceGroupName "<ExpressRoute ResourceGroup Name>"

# SKU tier (Standard, Premium), depending on what the client has selected
$ckt.Sku.Tier = "Standard" # (Standard or Premium add-on)
$ckt.sku.Name = "Standard_UnlimitedData" # (MeteredData, UnlimitedData)
$ckt.ServiceProviderProperties.BandwidthInMbps = 1000 # Bandwidth in Mbps

# Set the ExpressRoute configuration
Set-AzureRmExpressRouteCircuit -ExpressRouteCircuit $ckt -SkuTier Standard -SkuFamily StandardUnlimitedData

Environment Preparation

In order for the VNETs to connect to the ExpressRoute Circuit, a Virtual Gateway of type ExpressRoute must be created for each one of them.

Prior to any further task being performed, the Public IPs (PIPs) for the Virtual Gateways must be created. Upon creation, no IP will be given to the PIP objects (see Fig. 3). These will be assigned once the IPs are attached to the Network Configuration objects, e.g. Virtual Gateway(s), Virtual Network Interface Card (vNIC), etc.


Figure : Public IP view in Portal, having no PI assigned yet

PIPs can be created from either the Portal or via PowerShell (In this example no PIP script will be provided).


Upon Public IP object creation, the IP must be set to DYNAMIC, or else the next step will fail.


Upon Public IP object creation, NO IP will be associated to the object, until it is successfully connected to the ExpressRoute Virtual Gateway.


ExpressRoute Connection Process

The actual process consists of 3 distinct steps, which will be explained in detail below. For the sake of simplicity, this guide will only cover the connection process to a single VNET, however, the exact same steps can be performed for multiple environments and VNETs, simply changing the subscription ID and variable values in the scripts to fit the additional environments-VNETs requirements.


VNET connection to ExpressRoute can only be implemented through PowerShell.

Creating the Virtual Network Gateway Object

The first step is to create the actual Virtual Network Gateway object, which will attach the Public IP to it as well.

PowerShell Script 2 – Connecting the Virtual Network Gateway and associating it to Public IP

# Pass Azure Credentials
$azureAccountNameEA ="<Your Azure Username>"
$azurePasswordEA = ConvertTo-SecureString "<Your Azure Password>" -AsPlainText –Force

# Create the Login object
$psCredEA = New-Object

# Set credentials
System.Management.Automation.PSCredential($azureAccountNameEA, $azurePasswordEA)

# Automatically login to Azure using above credentials
Login-AzureRmAccount -Credential $psCredEA

# Select the subscription where the virtual gateway onject will be created in
Select-AzureRmSubscription -SubscriptionName "<subscription name string as shown in portal>"


Figure : Subscription pane in portal, showing Name (highlighted) and ID

$vnetname<your identifier> = "AZ-VN-<YOUR IDENTIFIER>-VNET001" # VNET that is about to be connected to ER
$rgname<your identifier> = "AZ-RG-<YOUR IDENTIFIER>-VNET001" # Resource Group under which VNET is created
$region = "North Europe" # Azure Region where VNET “lives”
$asn<your identifier> = 65010 # DO NOT CHANGE THIS VALUE
$GWName<your identifier> = "AZ-GW-<YOUR IDENTIFIER>-EVNG001" # Gateway Object Name that will appear in portal
$gwipconfname<your identifier> = "AZ-<YOUR IDENTIFIER>-VNGIC001" # gateway ipconfiguration object name

# The following command gets the Public IP object created in the preparation step where "AZ-IP-<YOUR IDENTIFIER>-VNGPIP001" is the Public IP name
$gwpip<your identifier> = Get-AzureRmPublicIpAddress -Name "AZ-IP-<YOUR IDENTIFIER>-VNGPIP001" -ResourceGroupName $rgname<your identifier>

# Get the VNET name
$vnet<your identifier> = Get-AzureRmVirtualNetwork -Name $vnetname<your identifier> -ResourceGroupName $rgname<your identifier>

# Get the VNET Gateway Subnet which is always named as "GatewaySubnet"
$subnet1 = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet<your identifier>

# Create virtual gateway configuration object
$gwipconf<your identifier> = New-AzureRmVirtualNetworkGatewayIpConfig -Name $gwipconfname<your identifier> -Subnet $subnet1 -PublicIpAddress $gwpip<your identifier>

# Create the Virtual Gateway Object, passing the variables defined above
New-AzureRmVirtualNetworkGateway -Name $GWName<your identifier> -ResourceGroupName $rgname<your identifier> -Location $region -IpConfigurations $gwipconf<your identifier> -GatewayType ExpressRoute -VpnType RouteBased -GatewaySku Standard -EnableBgp $true

In the above script:

Make sure the –GatewayType is ExpressRoute and not VPN, as Azure distinguishes the two different types of gateways depending on the requirement.

Make sure the –EnableBgp option is set to $true, as if this isn’t setup, BGP, which is critical for the ExpressRoute routing, will not be configured.

The -Asn option is not necessary for the Gateway to be successfully created.

The above script creates the Virtual Gateway and associates the Public IP to it, while at the same time assigns a new IP to the Public IP object, as seen below (Fig. 9).

Completion time: 15 minutes – 1 hour.


Figure : ExpressRoute Virtual Gateway as seen in the portal, with Public IP attached to it

Generating the Authorisation Key to Connect VNETs to ExpressRoute

The next step creates the authorisation key to connect the previously created Virtual Network Gateways to the ExpressRoute Circuit.


The Authorisation Keys can only be created via PowerShell.

PowerShell Script 3:

# Pass Azure Credentials
$azureAccountNameEA ="<Your Azure Username>"
$azurePasswordEA = ConvertTo-SecureString "<Your Azure Password>" -AsPlainText –Force

# Create the Login object
$psCredEA = New-Object

# Set credentials
System.Management.Automation.PSCredential($azureAccountNameEA, $azurePasswordEA)

# Automatically login to Azure using above credentials
Login-AzureRmAccount -Credential $psCredEA

# The ExpressRoute circuit is selected
$circuit = Get-AzureRmExpressRouteCircuit -Name "AZ-EC-ER-EXCIR001" -ResourceGroupName "AZ-RG-ER-EXRTNE001"

# The circuit owner creates an authorization object, which will holds the auth key
Add-AzureRmExpressRouteCircuitAuthorization -ExpressRouteCircuit $circuit -Name "AZ-AT-<YOUR IDENTIFIER>-AUTH001"

# The ExpressRoute Circuit is set as the desired circuit
Set-AzureRmExpressRouteCircuit -ExpressRouteCircuit $circuit

# The authorisation key is selected (this step is not necessary. It’s only being used to print the key)
$auth<your identifier> = Get-AzureRmExpressRouteCircuitAuthorization -ExpressRouteCircuit $circuit -Name "AZ-AT-<YOUR IDENTIFIER>-AUTH001"

Completion of the above script will give the output seen in Figure 10, below.

Completion time: 1-2 minutes.


Figure : Authorisation Key script PowerShell console output


The output will show the other authorisation keys previously created as well, if any. Make sure the right key is noted down to be used during the next step.

The right key can be identified by its “Name”, as highlighted in the output (Fig. 10), which should match the variable value given in the script (e.g. “AZ-AT-<YOUR IDENTIFIER>-AUTH001”), with the actual key being shown as “AuthorizationKey” (highlighted in Fig. 10).

Using the Auth Key to Connect the Virtual Network Gateway to the ExpressRoute

Finally, the actual connection between the ExpressRoute circuit and the Virtual Network Gateway has to be established, using the Authorisation Key that was generated in the previous step.

PowerShell Script 4 – Establishing the connection between ExpressRoute and Virtual Network Gateway

# Pass Azure Credentials
$azureAccountNameEA ="<Your Azure Username>"
$azurePasswordEA = ConvertTo-SecureString "<Your Azure Password>" -AsPlainText –Force

# Create the Login object
$psCredEA = New-Object

# Set credentials
System.Management.Automation.PSCredential($azureAccountNameEA, $azurePasswordEA)

# Automatically login to Azure using above credentials
Login-AzureRmAccount -Credential $psCredEA

# Circuit User redeems the ExpressRoute Connection Authorization using the authorization key

# Select the subscription where the Virtual Gateway is created in
Select-AzureRmSubscription -SubscriptionName "Microsoft Azure Enterprise"

# Select the id of the ExpressRoute circuit (this entire string object is custom for every distinct ExpressRoute, so has to be retrieved from the Resource Explorer. See Figure 11 below)
$id = "/subscriptions/<subscription id>/resourceGroups/AZ-RG-ER-EXRTNE001/providers/Microsoft.Network/expressRouteCircuits/AZ-EC-ER-EXCIR001"

Figure : ExpressRoute ID string to be used in the above command

$rgname<your identifier> = "AZ-RG-<YOUR IDENTIFIER>-VNET001" # VNET Resource Group
$region = "North Europe" # VNET region
$GWName<your identifier> = "AZ-GW-<YOUR IDENTIFIER>-EVNG001" # Virtual Network Gateway Name, as created in step 1

# Get the Virtual Gateway Object
$GWVnet<your identifier> = Get-AzureRmVirtualNetworkGateway -Name $GWName<your identifier> -ResourceGroupName $rgname<your identifier>

# Create a new connection object that establishes the VGateway – ER conection
$connection = New-AzureRmVirtualNetworkGatewayConnection -Name "AZ-CN-<YOUR IDENTIFIER>-ER001" -ResourceGroupName $rgname<your identifier> -Location $region -VirtualNetworkGateway1 $GWVnet<your identifier> -PeerId $id -ConnectionType ExpressRoute -AuthorizationKey "<Auth Key from step 2>"

Completion time: 5-10 minutes


Figure : Authorisation Key view in Resource Explorer

The -AuthorizationKey “<Auth Key string>” string that is used as a value in the above script can be found in the Resource Explorer (see Fig. 12), by simply searching for it in the provided search box on the top and can be retrieved from the JSON object by copying and pasting it in the script.


Successful completion of script 4 will not output anything to the PowerShell ISE console. The connection can be seen as being established in either the Portal or Resource Explorer (see Fig. 13).


The AuthorizationKey value MUST be added as a string in the script, or else it will fail.


Verifying the Connection

After the last script is completed, the established connection can be verified through the Portal and Resource Explorer.


Figure : ExpressRoute Virtual Network Connection view in Azure Portal

Figure : ExpressRoute Connection object view in Azure Portal


Figure : ExpressRoute Virtual Gateway view in Azure Resource Explorer


Figure : ExpressRoute Connection object as seen in the Resource Explorer

Finally, the VNET address space will be advertised to the other end of the ExpressRoute circuit and needs to be verified from the circuit provider’s site.


VNET address space takes between 2 and 5 minutes to be advertised to the other end of the ExpressRoute circuit.



As parts of the scripts are case sensitive and PowerShell doesn’t provide the capability to automatically identify variable mismatching or syntax errors, there is always the possibility that one of the above scripts fails. Below can be found troubleshooting instructions for each one of the above scripts.

Troubleshooting ExpressRoute Virtual Network Gateway Script

In case this Script 1 fails, the Public IP and ExpressRoute Virtual Gateway will show up as “Failed” in the Portal.

In that case all the objects that are related to that task in Azure must be destroyed. This includes:

  • ExpressRoute Virtual Gateway
  • Public IP Object

Finally, the script can be re-run to successfully create the ExpressRoute Virtual Gateway.

Troubleshooting Authorisation Key Script

In case Script 2 fails, there will be no Authorisation key created to use for the next step, which will connect the ExpressRoute Virtual Gateway to the actual circuit.

In that case, the script needs to be re-run in order to get a valid key.

Troubleshooting Authorisation Key Script

In case Script 3 fails, the connection between the ExpressRoute Virtual Gateway and the actual circuit will not be successful.

In that case, the script has to be rerun in order to successfully establish the connection.


Variables in the scripts are case sensitive, so ensure commands are double-checked before they are executed.

Always check the type of the values passed in the commands (i.e. an object is different than a string value even if they are written in the same way).


Testing the ExpressRoute Connectivity

After the scripts have been successfully completed, in order to test whether connectivity between the on-premise site and the Azure subscription has been successfully established, the following requirements should be met:

  • Access to Azure VM
  • Access to On-Premise VM/Server
  • Network Team for testing on On-Premise side
  • ExpressRoute Provider to confirm traffic is travelling over ExpressRoute

The steps that need to be followed to verify connectivity are as follows:

  • Ping from on-premise to Azure
  • Ping from Azure to on-premise
  • Tracert from on-premise to Azure
  • Tracert from Azure to on-premise
  • Repeat the steps for every VNET in Azure that is connected to ExpressRoute
  • Ensure the correct route is being followed from on-premise to Azure and vice versa for all VNETs

The exact routes followed from both sides depend on the on-premise, Azure and provider’s infrastructure architecture and design, hence no accurate example can be provided that would match all scenarios.

Leave a Reply

Your email address will not be published.

Close Bitnami banner