@IngramLeedy ... View more

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   ... View more

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.     ... View more