vMX install in Azure fails

[JGrantB]

I have already engaged Meraki support but thought I would ping on the community too!

I am using the vMX Setup Guide for Microsoft Azure for reference.

I have tried 7 deployments and they all failed. On three of them, I tried fix suggestions from Reddit/Meraki community posts and those are:

#1 Set the zone field property to 'None'

#2 Used the Azure 'preview' portal

#3 Set the DNS servers property on the VNet to 8.8.8.8

The error is the same on all 7 attempts I have made today,

"The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'. (Code: ResourceDeploymentFailure)"

AND

specifically, "OS Provisioning for VM '[myvmname]' did not finish in the allotted time."

The time to failure is approximately 22 minutes after I start the deployment. The deployments are all to US East Azure region & I am owner on the subscription.

Is there an alternative way to deploy the vMX in Azure?

[PhilipDAth]

The #1 most common reason for Azure VMX failure (in my experience) is DNS.

In Azure, get the public IP address assigned to the VMX.  Then when it is deploying, point your web browser at that public IP address.  After a while it will start responding.  Now you'll be able to see the reason why the VMX is reporting a failure.

I mention DNS; if your DNS is set to point to "internal" servers (such as AD controllers) the VMX will often fail to deploy.  In this case, make the DNS statically point to something like 8.8.8.8 via the local status page.

[patw-agr]

This is a great response, I think this is where I'm confused about the VMX devices. If I deploy the VMX's with Azure public DNS servers for the vnet they're deployed in, they are happy but the clients using the Meraki VPN tunnel cannot reach my internal DNS servers (sitting on-prem behind MX95's).

If I change the Azure vnet to look at my internal DNS servers (then reboot the Azure clients), then everything works perfectly -- but once the VMX's are rebooted, they start using those internal DNS servers and then they are unhappy. I think I have a fundamental misunderstanding of how this is supposed to work, but I don't really know how to proceed.

[JGrantB]

My apologies for not replying with my solution. My deployments were being blocked by Azure security polices that our cloud services team implemented without my knowledge, that probably doesn't help too many people but something to look out for.

@patw-agr, I am using the vMXs coupled to Azure vWAN so not entirely sure this applies to your situation.

My vMXs are deployed by setting the Azure NIC to static with the private IP address and the associated public IP address. In the Meraki portal, on the vMX local status page, uplink I have the WAN interface set for 'Auto'. That is picking up DHCP Azure settings of the static IP I set and then default gateway and DNS (Azure wire server - 168.63.129.16). The vMXs are BGP peered to vWAN so I just have to make sure that the proper routes are propagated to the remote site so they can access the DNS servers, in Azure, that the remote offices have configured in DHCP.

This works flawlessly, I hope it gets you to some sort of resolution for your situation.
-Grant

[PhilipDAth]

Use a VNET that uses your internal DNS - then then change the DNS servers used by the VMX using its local stays page to point to something external.

[patw-agr]

That makes total sense; however I'm not sure how to set only the DNS server manually for the VMX (from the Meraki side, anyways). I have the VNET using the internal DNS servers, but looking at the 'uplink' page for the VMX in Meraki makes me enter all info for the public IP associated with it to be able to change the DNS server. I do have the public IP it got from Azure but not the required subnet mask or gateway to be able to submit the info:

[PhilipDAth]

Start the VMX deploying.  Get it's public IP address fro the Azure console.  After a minute or two it will be running enough for you to point your web browser at it.  Log into the local status page.  Update the DNS servers.

https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Me... 

ps. I would disable the local status page from the Meraki Dashboard once deployed.

[patw-agr]

Super late in replying but this was everything I needed, thanks so much for the help.

[TyShawn]

Just to verify when you say you set the DNS on the V-Net to 8.8.8.8 was it on DNS 1 or 2? The reason for this question is if it's set to 3 or lower the vMX will not honor any DNS below 2.

[PhilipDAth]

I mean set the DNS on the VMX appliance via the local status page.

You can use 8.8.8.8 for DNS #1, and 8.8.4.4 for DNS #2.

[TyShawn]

You're good @PhilipDAth. for me I never set the vMX DNS until I see the unit come up. This is my method doesn't make it right. Once it comes up I point DNS 2 to my internal DNS server and DNS 1 to an external server. 

The tip I gave @JGrantB was due to an issue I ran into a few months back when I had DNS 3 set to 8.8.8.8 on the VNET.

[JGrantB]

I had only tried the DNS setting on the 'DNS Servers' on the VNet blade in Azure and only added 8.8.8.8.

Meraki support has passed this off as an Azure problem but I am going to try setting the DNS on the local status page and see what happens. I also spotted in the deployment guide under (Re)deployment failure:
A few common fixes for (re)deployment failures could be:
• updating the VNET DNS settings <-- Already tried this
• removing any special characters in the name of the vMX <-- I do have dashes in my naming convention so this might be the smoking gun.

Thank you both for the suggestions!

[TyShawn]

removing any special characters in the name of the vMX <-- I do have dashes in my naming convention so this might be the smoking gun. <--- When I ran into this issue the device wouldn't even complete the install process. 

Meraki support has passed this off as an Azure problem <-- To a point, they are kind of right. If the DNS servers you could be using don't have access to the internet to complete the DNS requests then it should and would fail. That being said if they do have a path to the internet then I don't see why it would fail.

The good news for anyone else running into this issue is the secondary server method of 8.8.8.8 is only required while spinning up the device. Once it has been installed you can change your DNS servers in the dashboard to the DNS servers of choice then revert your Azure secondary DNS server to what you had it set to previously.