I recently ran into an issue where an ExpressRoute had been migrated from Classis (ASM) to the new portal (ARM), however legacy Classic Virtual Networks (VNets) were still in operation. These VNets refused to be deleted by either portal or PowerShell. Disconnecting the old VNet’s Gateway through the Classic portal would show success, but it would stay connected.
There’s no option to disconnect an ASM gateway in the ARM portal, only a delete option. Gave this a shot and predictably, this was the result:
Ok, let’s go to PowerShell and look for that obstinate link. Running Get-AzureDedicatedCircuitLink resulted in the following error:
PS C:\> get-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
get-AzureDedicatedCircuitLink : InternalError: The server encountered an internal error. Please retry the request.
At line:1 char:1
+ get-AzureDedicatedCircuitLink -ServiceKey xxxxxx-xxxx-xxxx-xxxx-xxx...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzureDedicatedCircuitLink], CloudException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ExpressRoute.GetAzureDedicatedCircuitLinkCommand
I couldn’t even find the link. Not only was modifying the circuit an issue, but reads were failing, too.
Turned out to be a simple setting change. When the ExpressRoute was migrated, as there were still Classic VNets, a final step of enabling the circuit for both deployment models was needed. Take a look at the culprit setting here, after running Get-AzureRMExpressRouteCircuit:
"serviceProviderProperties": {
"serviceProviderName": "equinix",
"peeringLocation": "Silicon Valley",
"bandwidthInMbps": 1000
},
"circuitProvisioningState": "Disabled",
"allowClassicOperations": false,
"gatewayManagerEtag": "",
"serviceKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"serviceProviderProvisioningState": "Provisioned"
AllowClassicOperations set to “false” blocks ASM operations from any access, including a simple “get” from the ExpressRoute circuit. Granting access is straightforward:
# Get details of the ExpressRoute circuit
$ckt = Get-AzureRmExpressRouteCircuit -Name "DemoCkt" -ResourceGroupName "DemoRG"
#Set "Allow Classic Operations" to TRUE
$ckt.AllowClassicOperations = $true
More info on this here.
But we still weren’t finished. I could now get a successful response from this:
get-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
However this still failed:
Remove-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
So reads worked, but no modify. Ah—I remembered the ARM portal lock feature, and sure enough, a Read-Only lock on the Resource Group was inherited by the ExpressRoute (more about those here). Once the lock was removed, voila, I could remove the stubborn VNets no problem.
# Remove the Circuit Link for the Vnet
Remove-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
# Disconnect the gateway
Set-AzureVNetGateway -Disconnect –VnetName $Vnet –LocalNetworkSiteName <LocalNetworksitename>
# Delete the gateway
Remove-AzureVNetGateway –VNetName $Vnet
There’s still no command to remove a single Vnet, you have to use the portal (either will work) or you can use PowerShell to edit the NetworkConfig.xml file, then import it.
Once our legacy VNets were cleaned up, I re-enabled the Read-Only lock on the ExpressRoute.
In summary, nothing was “broken”, just an overlooked setting. I would recommend cleaning up your ASM/Classic Vnets before migrating your ExpressRoute, it’s so much easier and cleaner, but if you must leave some legacy virtual networks in place, remember to set the ExpressRoute setting “allowclassicoperations” setting to “True” after the migration is complete.
And don’t forget those pesky ARM Resource Group locks.