Cloud Academy Team

Microsoft Azure ExpressRoute: Resolving a Frustrating Setup Conflict

ExpressRoute: creating a private connection to the cloud

Over at my day job, we’ve been Microsoft Azure customers now for coming up to three years, and during this time it has generally been a positive experience.  Recently we decided that, with our increased demand on cloud services, we needed to upgrade from our Internet VPN connection to a dedicated private connection using Azure’s ExpressRoute. ExpressRoute had only recently been released in Singapore.

Having read through Microsoft’s setup process documentation, this seemed like a pretty straight forward process.

We engaged our Exchange Provider, and the required infrastructure was configured in the Partner Location. We were now ready to execute the following tasks:

  1. Import the PowerShell module for ExpressRoute
  2. Get the list of providers, locations, and bandwidths supported
  3. Make a request for a service key and pass it to your exchange provider
  4. Send the Service Key to your exchange provider
  5. Periodically check the status and the state of the circuit key
  6. Configure routing for virtual network
  7. Configure routing for services hosted on public IP addresses
  8. Configure your Virtual Network and Gateway (we configured this activity in advance of the above steps in preparation for the commissioning process)

All the above tasks completed without issues and we launched the final command to execute to link the network to a circuit and…Error Message!
ExpressRoute error message
At this point we suspected that maybe one of the variables was incorrect so we double checked `$ServiceKey` and `$VNetName` to see if a simple typo had caused the error, but alas all was correct.

Troubleshooting our ExpressRoute installation

We then undertook a more detailed visual inspection from the Management Console to make sure that the configuration of our Virtual Network and Gateway cmdlets (`Get-AzureVNetSite` and `Get-AzureVNetConfig | fl`) were correct. This search, too, confirmed that everything was configured correctly.

We then executed:

Get-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $VNetName -debug

to get more detailed information about what could be causing the error to isolate:
ExpressRoute output
You will notice that the first couple of lines provide the Subscription ID, and this is where the problem lies. We have multiple subscriptions, and as part of the provisioning process with the Exchange Provider, we provided them with the correct ID. But when we ran the PowerShell Commands there was no variable to define the Subscription ID or Name, nor was any method mentioned in the documentation. Everything worked as expected throughout the process with no indication of potential conflicts until the final step.

To back out of the changes we used the corresponding `Remove- `command for the PowerShell commands that were previously running, working backward from the last the to the first command executed.  The following image is the list of the Express Route PowerShell Commandlets.
ExpressRoute PowerShell Commandlets

Key Takeaway

Before you start provisioning your Express Route setup, open PowerShell and run

Get-AzureSubscription -Current

to make sure you are executing commands against the right subscription.  If you aren’t, you’ll need to change it. Use:

Select-AzureSubscription -Current -SubscriptionName "subscription name"

It’s really a simple oversight, but if you have multiple subscriptions, it is one that could be the source of some frustration. Once corrected, the process ran smoothly without any further errors and all is now working well.

Cloud Academy