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.
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.
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.
@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!
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..... 😞
@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
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.
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!
@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.
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
No luck in West-europe...
Could not create the marketplace item
This marketplace item is not available.
... And all we wanted is to build a route based (dynamic) VPN with the MX84... Since this could be done (Meraki does not support that), we waiting for the vMX100 to bypass the limitations of a policy based (static) VPN in azure... a bit disappointed
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.
Welp, never mind. After about 40 mins, got the following:
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
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.
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
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)
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?
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
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?
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.
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.
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.
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...
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.
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.
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.
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.
@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)?
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.
@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.
Because of the lock problem with my 2 vMX, I was not able to stop 2 VMs in Azure. I open a case with Meraki support and here their response. I did it and it worked fine.
"When the appliance is created and you create a new Resource group it also creates another read only resource group. This is what is locked and caused a lot of the issues as I create the network during setup it became read only effecting the rest of our Azure setup. If you need to delete the appliance and start again you need to do the following:
1) Bring up all the resource groups in the Azure portal.
2) open the resource group that you created in the guide above.
3) In this resource group you will see a managed application which is a large bunch of letters and numbers. This is also the name of the lock that is in the read only resource group. If you delete this managed application it will also delete the read only resource group and the locks allowing you to start again."
I seem to have run into this same issue.
I want to make sure that i am understanding this correctly. I have a couple questions.
1. Before I start the vMX deployment i need to create a RG and a Vnet?
2. Your step 3 ) At this point select that Vnet. What about the subnet? Does that also need to be pre-created or can that be done during the deployment? Or do i just leave that as default?
3. If i want to have the vmX in a /24, but I also want several other /24's available for VM's how do I accomplish that?
Very new to Azure, any help would be greatly appreciated.
@bholmes12 I'll try to answer these as best I can from memory:
1) Before you deploy the vMX, you should have two resource groups. One of them should be for your servers, the other should only be for the vMX. You should also create the VNet you want the vMX to be in ahead of time and place this in the first resource group - NOT the RG that's only for the vMX.
2) Pick the VNet that is in the first RG. This will be the VNet that the vMX gets an IP from. I use a dedicated subnet in the VNet just for the vMX.
3) Add multiple subnets to the VNet. As an example, I use the 192.168.0.0/16 address space for my VNet. This is set on the "Address space" page under the VNet. Under the "Subnets" page, I then have multiple /24's defined (within the 192.168.X.X space). One of these I call vMX-Net and it is the /24 I use for the vMX and nothing else.
One other thing - when you create the route table for the vMX, you should create this in the RG that is only for the vMX. Don't create the route table in the RG you use for other servers. After you've deployed the vMX, don't add anything else to the vMX RG.
i have a problem to make changes at the vnet configuration. The problem is that the meraki managed application locked the thr resource group at azure. In this case a want remove the lock from the resource group but i get a error message that this change is not possible.
Have anybody some ideas to solve my problem to remove the locked on the resource group. I want to move the resource to another resource group and recreating the lock.
Thanks for your help.
You cannot remove the lock on the resource group the vMX is deployed in. Because of this, you need to place the vnet in another RG. Nothing should be in the RG with the vMX as it will be locked during the deployment. You'll need to redeploy the vMX to correct this.