vMX100 Azure Cloud

[Granville]

For the error "subscription not able to depoy"

There is a note at the bottom of the guide stating that we cannot use trial or CSP accounts to deploy. I assume you have one of these?

I don't get that error and am deploying using PAYG.

I planned on using CSP.

[4zap]

We have an EA agreement, no CSP, no trial.... still waiting for an reply from MS....

[Granville]

That would suggest that it doesn't work with trial, CSP or EA?

ultimately we are hoping to use EA.

Would be really interested to hear back from you on this if that's ok...

[4zap]

@Granville: We are on it right now with the MS Azure Support Team, i ll keep you informed if we found a solution today... maybe Monday...

[MJPAGAN]

I really hope it starts working with CSP because we're setting up all new customers and migrating existing PAYG customers to CSP to simplify billing.

Thanks to everyone who's sharing their experiences.

[4zap]

It seems it is related that Meraki rolled out this vMX not in WestEurope. Thats where i need to place the vMX. I created a support ticket in the dashboard and hope that we get it solved.

[techmoc]

Since I was able to use one of our IUR subscriptions (an older Action Pack IUR offer for Microsoft Partners), I tested deployment on West Europe and it was successful.

I think it definitely has to do with the comment on the setup guide regarding the subscription type.

We are also moving our subs to CSP... so will eventually need this issue solved.

[Granville]

Oh Wow, thanks for letting us know. I'm sitting here assuming its not my subscription type. Ill check West Europe just in case..., but otherwise it might be my PAYG sub type. I'm not sure there is another type immediately available for me.

[techmoc]

@Granville just rechecked the guide for any updates... it only states at the end to not choose a Trial or CSP subscription type and a couple of lines below to not use specific characters on the template

"The following characters are not being used in the template: ' ~ ! @ # $ % ^ & * ( ) = + _ [ ] { } \\\\ | ; : ' \\\" , < > / ?.\" '."

[Granville]

I just tried west Europe and I get the same error "The publisher does not offer this product in the billing region....". So if you are able to deploy there Techmoc it must be something to do with my account setup rather the a VMX100 being limited to my area?

[techmoc]

As a double check... Public IP is from region name "europewest" according to most recent Azure IP list XML

[HaloTech]

I can't deploy it anywhere, on any subscription even pay as you go.

Anyone had any luck?

Seems like I'm going to be asking for my money back since this is needless if I can't deploy it.

[JuanK]

I am having exactly the same issue. i have re-deployed this multiple times and i cannot associate the subnet to the vmx100, called support and azure and both are finger-pointing each other.

[Granville]

Hey Techmoc, Which billing region is your Azure tenant? will that be GB?

anyone managed to get past this issue yet?

[4zap]

@Granville I dont get a notification that the issue is fixed but this morning i was able to deploy a vMX100 in Azure WestEU with my EA subscription! I am connected with my meraki network now.... i need to configure the subnets today and then i will see if it is working as expected. But for the first approach it looks good!

[Granville]

Hi 4zap, We tried around an hour ago and it deployed ok. I also just has a message from Meraki to say engineering made an update last night.

So we are up and running...

[4zap]

Nice, it seems they made some improvements last night. I have hustle to assign subnets... we are working with some classic networks... the ressource group that is created while installing the vMX VM in Azure is write protected and i cant remove the lock to make any changes in the subnet assignment. I tried to peer both (classic and ressource based networks) but i always get the error that the vMX RG is locked.....

[techmoc]

@Granville my Azure AD tenant is in US

[techmoc]

@4zapsince it is deployed as a managed application, the deployment generated resource group is basically locked by design. I did test creating subnets in another RG and added them using vnet peering option. I only tested ARM vnet and was able to get it working as needed. I'll see if I can incorporate a classic vnet and let you know

[Granville]

We will have these challenges to start testing very soon. Thanks for your feedback. Have clicked the Kudos button hope you win some socks...

[techmoc]

Thanks @Granville, I did a simple test regarding integration of a classic vnet to the VPN community.

Peering between vnet and classsic vnet works and I am able to ping devices on classic vnet from the vMX ping tool, the difference is on the ip route since resource doesnt support classic vnet. As mentioned on the VNET peering docs, peering between vnets with different deployment types and even subs is supported and works but to route traffic you need to add azure gateway resources between the vnets to be able to route traffic to/from the vnet/subnet where the vMX is deployed and the classic vnet/subnet. Check Create a virtual network peering - different deployment models, same subscription

During my tests I can see the most important thing is to have the resource groups and vnets/subnets created before and make sure only vMX resources are deployed on the vMX and Managed App resource groups to avoid getting other resources locked that you may need to modify later.

Cuauhtemoc

[Uberseehandel]

It appears that there are capacity issues with Azure's UK West and UK South regions.

[BklynITGuy]

Curious how long the appliances has taken some of you guys to deploy successfully? I have a deployment running now and it's at about 33 minutes... I don't see any errors on the Azure side, it just seems to be taking long.

[BklynITGuy]

Welp, never mind.  After about 40 mins, got the following:

{ "status": "Failed", "error": { "code": "ApplianceDeploymentFailed", "message": "The operation to create appliance failed. Please check operations of deployment 'e66f5b3b08274953a0be4cd24e589cc6' under resource group '/subscriptions/xxxxxx-1d6a-4e8d-87fc-de2382680e4b/resourceGroups/XXXX-VMXicr32w4ebkd6k'." } }

[BklynITGuy]

Ok, so not sure if anyone else has experienced this or figured it out.. Brand new RG/Vnet, etc...

Problem I have now is when I try to associate the vvnet/subnet to the route table, I get an error that it failed to save subnet due to the resource being locked.  , I  cant  figure out if i'm missing something

[4zap]

The lock is the problem, you cant make any changes in the RG.  I run into the same issue. I talked to the Azure Team and the Meraki Support. Meraki told me that there may be an issue with the lock and they notify me when the problem is solved. Seems the vMX isn't ready yet, lets wait till monday.

[BklynITGuy]

Yea last I checked with Meraki, this was by design to have that lock. But it makes it impossible to go through their remaining steps. I haven't tried via powershell, i wonder if that'd make any difference

[PRISMI]

Hi ,

Today i have deployed on azure trial of vmx100. I have create all the static vpn. 
the problem now is that i can't stop, restart the VM. I recive error with resource locked.
i can't change Managed resource group too.

error is :

The scope '/subscriptions/dc63112c-4031-43f4-a43b-3cc6cbb74795/resourcegroups/MerakiRGoupfteqm5i5vgjp2' cannot perform write operation because following scope(s) are locked: '/subscriptions/dc63112c-4031-43f4-a43b-3cc6cbb74795/resourceGroups/MerakiRGoupfteqm5i5vgjp2'. Please remove the lock and try again. (Code: ScopeLocked)

[CiscoKid78]

I think it's pretty much unanimous that the problems described here with other Azure subscribers trying to deploy the vMX100 that there is indeed an issue with the lock on the named Azure Resource Group.  The result of this deployment cause a "Shadow" Resource Group where the VM for the vMX100 lives.  My suspicion is that even though PowerShell one would run into this probably unless we can isolate just the VMImage deployment via PowerShell.  Deploying the vMX100 from the MarketPlace does so as an application where it's deployment tasks places a lock on the Resource Group almost immediately.  I'll try to create a PowerShell VMImage deployment task now that I have the some time and that the vMX100 is now out of the Beta phase.  I'll report back.

What is so secret about the vMX100 deployment versus the Cisco CSR1000V that requires a lock on the Resource Group?  Cisco felt it necessary to empower Azure subscribers by offering the flexibility to manipulate the Resource Group associated with the CSR1000V.  Why the 180 degree change dealing with this particular vMX100 appliance?  Cisco?

[PRISMI]

Thanks a lot for all the informations.

[techmoc]

@CiscoKid78 

In my case I did mention regarding the resource lock the following on a previous post:

"have the resource groups and vnets/subnets created before and make sure only vMX resources are deployed on the vMX and Managed App resource groups to avoid getting other resources locked that you may need to modify later"

The Setup Guide also warns. What it doesn't say is that only deployment resources should be added automatically to the created RG to avoid the resource lock. If all vnets, subnets, route table, etc are added to a separate RG they can be modified and associated without a problem.

I think the lock by design is more of a managed application practice on the Azure side

[BklynITGuy]

So when I created the resource group, vnet, and subnet first, I try to add that VMX appliance to the resource group and it says the following:

That RG has the vnet/subnet already. Am I going in the wrong order on this?

[BklynITGuy]

So I was able to get it deployed, it was a bit unorthodox, but it worked.

-I assigned the VMX to the new (empty) RG

-Then on another tab, I created the vnet/subnet and assigned them to that RG

-Then went back to the VMX creation page and used the newly created vnet/subnet

It deployed successfully. Now Meraki support said you should be able to create this in an existing vnet, however I was unsuccessful in doing so. So I created peerings between the 2 vnets. I tested a VM and confirm it could ping the VMX from a different vnet.

Still having some issues pinging from Azure to our on-prem site, but I think that could be resolved once we look into the routings a bit more.

[HaloTech]

I totally just gave up on it, since I was testing it out as a proof of concept for another project. After 2 days of head desking I asked for RMA.

[4zap]

Nice! Will try it this way...after i tried it 2 times to redeploy in different ways i gave up today, but with this info i will try again.

[4zap]

failed again. Did not get it running. Need to connect it to a classic created network ressource. From the vMX RG i cant peer this network because of the lock (that i can not remove or change). And the classic network has no option for peering, only ARM RG networks does provide the peering option. I need to setup different DNS Servers in the vMX network, but i run always in the lock. This i anoying. Any changes i need to do are restricted by the lock. when i try to remove the lock i get the message that this is a child lock, i need to delock the parent ressource group, but in the parent RG is no lock visible...... i give up till the support tells me that they had fixed it.

[Andreas]

I have the same issues, installing the vmx into our test subscription. With a prepared vnet and subnet, all fine. If i want to create a route and attach this to the meraki subnet.. no chance. It says it cant added to the resource group, because it is write protected. 

Looks like a beta test... 

[4zap]

Still stuck at the same point once again. Locked ressource, it tells me that a child lock is set. When i try to delock the parent there is no lock visible. While i deployed the vMX in Azure the deployment creates a "shadow" - ressource group where all the deployments are included (network card, network, VM, disks ....) This shadow RG is locked by design as far as i figured out.

I talked to a Meraki Support Engineer today, he will provide me a solution till monday. I let you know if i will be able to solve it and if so  i will post the workaround here next week.

[4zap]

Ok, it runs well now. What we did:

- create a virtual network (ARM) in your default network ressource group where you need it -> give the network a unique name

- deploy a vMX100 in Azure, when you get asked at step2 to define a virtual network there is already a proposal for a new virtual network visible ->(new)vmx-net. Dont use this. choose the virtual network which you had created before with the unique name. finish all the steps from the deployment -> setup a routing table as in the documentation described. Thats it! It is running, After i assigned my subnets i was able to ping the vMX from any tenant and from any office (we have a full meshed meraki network onprem with site2site Meraki VPN).

Additional to this deployment i was able to peer classic virtual network ressources to the new virtual network. From the old ressources i am now able to ping the vMX and any Meraki in any country.

Good Luck!

[AbhilashRN]

My findings: 

Unfortunately you will not be able to remove the locks on the Resource Group created by default while deploying the vMX100 Appliance on the Azure VM. We have observed several similar issues raised and this by vMX10 is getting the Resource Group locked.

So below is the best practice work around – to avoid any other resources being locked.

Scenario: If you have a VNET: VNET1 in a Resource Group: RG1 in the location: US East (Example) where you would like to deploy the vMX100 appliance.

• Step 1: Create an empty Resource Group: RG2 in the US East (Same as where your VNET is) location.
• Step 2: While deploying the vMX100 using the documentation at https://documentation.meraki.com/MX-Z/Installation_Guides/vMX100_Setup_Guide_for_Microsoft_Azure while configuring the basic settings (Step 1), instead of creating a new Resource Group use the existing RG option to select RG2
• Step 3: As the RG2 resource group is in the same location you be able to select VNET1 virtual network/subnet to deploy the vMX100 on the VM1 in VNET1.
• Step 4: Once you complete the rest of the deployment you will also find that from RG2 there will be a new RG2XXXXXXXX resource group created, which is being done by the vMX100 image itself. And this RG2XXXXXXXX is being locked.
• Step 5: Following the above steps you will only have vMX100 VM on the locked Resource Group: RG2XXXXXXXX and therefore you still be able to make changes to the VNET1.
• This work around will isolate the locked Resource Group: RG2XXXXXXXX to contain only one resource the vMX100.
• After deploying the vMX100 VM, please create the route table as per the https://documentation.meraki.com/MX-Z/Installation_Guides/vMX100_Setup_Guide_for_Microsoft_Azure in the RG2 resource group only.

Note: Resource Group is only a logical container to put all the related resources in to one container, to make it easier to manage. So the extra resource group will not create any additional charges.

[MRCUR]

@AbhilashRN  Thanks for the excellent directions. These worked perfectly for me and now I have a vMX in its own RG that isn't locked. 

Forgive my unfamiliarity with Azure - but did you create a subnet dedicated to the vMX WAN port and then have another subnet used for the inside (what's supposed to be tunneled out the vMX)? 

Also, anyone figure out a way to set a static IP on the vMX WAN (not sure this really matters)? 

[IngramLeedy]

Does the license you buy from Meraki include the VM or is the VM an additional cost. From what I can tell the VM is about $85/month. Any clarification would be helpful. THanks!

[MRCUR]

@IngramLeedy Azure or AWS charges are not included in the vMX license. There is no hardware cost to the vMX from Meraki since you need to pay Microsoft or Amazon to run the appliance. You're just paying Meraki for the software license. 

[AbhilashRN]

I can confirm from the Azure side, you will have to pay for the compute power, in this case, the Virtual Machine on which you deploy the Meraki image. The overall cost per month depends on the Tier of the Azure VM, Disk Size, number of cores,  Disk Type (Managed or Unmanaged) and if you would like Azure support services for any issues with the VM instance itself. 

Please use the following link to calculate the costs for your virtual machine - https://azure.microsoft.com/en-us/pricing/calculator/#virtual-machines1

- Opting for the Azure Support plan, Azure teams will assist you with any issues with the NIC, underlying network infrastructure, migration to a different network for example. 

- Please note that the Meraki documentation recommends an Azure VM of minimum size Standard D2_V2, you can also find the detailed documentation of Azure VM sizes and types at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes

- Detailed documentation on the managed disk feature for Azure IaaS VMs can be found at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/faq-for-disks

[AbhilashRN]

@IngramLeedy

[Speightz]

Did anyone figure out how to set static IP? I also cannot set static IP address which I require as I want to terminate 3rd party VPNs into Azure also... due to the lock. 

I tried to delete the lock with powershell but it wouldn't let me. I dont like the Resource Group it creates and was trying to move the resources to a tidy RG.

Feels very Beta TBH. Its a shame it doesn't have NAT mode either.

[MRCUR]

@Speightz You definitely can't change the public IP to be static because of the lock. But as long as you don't de-provision the vMX, the IP won't ever change so it shouldn't be an issue to set up the S2S VPN's. 

[MRCUR]

For those who have deployed the vMX in Azure, is the "Historical data" working for you on the Uplink page? I have the default destination of 8.8.8.8 configured on the Traffic Shaping page along with an additional IP. I can see the traffic through a pcap, but am not seeing anything reflected in Dashboard.

[MRCUR]

---

@MRCUR wrote:

For those who have deployed the vMX in Azure, is the "Historical data" working for you on the Uplink page? I have the default destination of 8.8.8.8 configured on the Traffic Shaping page along with an additional IP. I can see the traffic through a pcap, but am not seeing anything reflected in Dashboard.

---

This is corrected in firmware 14.19. 

[Speightz]

Update from my testing so far. My vMX100 has been down for about 3 weeks while I bounce between Azure support and Meraki support.

The issue was I ran out of credit and the vMX was de-allocated after de-allocation I cannot start the VM again due to you guessed it the "lock" 

Azure support say they cannot remove the lock cause it is placed by Cisco in the logs. 

Cisco Meraki support say they didn't put the lock there...

Can anyone else de-allocate their vMX100 and can start it again?

I think RMA for me is best option at this stage the lock has to go!