The MX will attempt to dhcp an ip on the WAN port. It will then connect to the Meraki cloud back-end to pull config and firmware updates.   https://documentation.meraki.com/MX/MX_Quick_Start ... View more

The key to Meraki zero touch provisioning is that you can create a network and configure settings and policies without having the devices. This removes the requirement for staging. Once the devices check in to the dashboard and are adopted into the network, they will automatically pull the configuration from the cloud.   Check out the links @CptnCrnch provided to get started. ... View more

This partly makes sense, but I would expect 16.16 to also tell us that an upgrade is available, to either the stable release candidate, or to 16.16.2. ... View more

This behaviour does seem a bit buggy.   On 16.16 I see firmware up to date. When I upgrade to 16.16.2, I see 'upgrade available'. When opening the upgrade prompt, it gives me the target version of '16.16(latest stable)'.   I'd say it's likely due to the fact that both 16.16 and 16.16.2 are listed as latest releases in the stable firmware channel. ... View more

That's a good point. By the sound of it, the dishy stats interface doesn't have a default gateway, so you won't be able to reach it from other subnets. This is where an outbound NAT rule would resolve this, however Meraki MX's do not support outbound NAT on a LAN interface. ... View more

Speaking from gleaned knowledge rather than experience. You can't have two tunnels to the same destination on the Meraki side. The way to implement redundancy for a non Meraki S2S connection is to have a second WAN link on the MX with a separate public IP. On the ASA, you then configure the backup IP for the tunnel to point to the MX's second WAN link.   In this way, is there is an issue with the primary link, the tunnel will be re-established on the backup link with a very minor impact to network traffic. ... View more

If all of your AP's are wired into the network, then yes you don't need meshing. Disabling it will stop it from broadcasting the mesh SSID thereby freeing up some airtime.   Meshing isn't required for AP to AP communication in terms of client balancing etc. This information is sent as encrypted broadcasts over the LAN connection.   https://documentation.meraki.com/MR/Other_Topics/Client_Balancing#Information_Exchange ... View more

Quick check of the Microsoft doco shows you've covered most of the ports. Can you run a packet capture (on whichever Meraki device is most applicable in your network) to see which other ports the PC is attempting to communicate to the DC? ... View more

If you configure the VMware side as a LAG, you will need to configure the Meraki side as a LAG too. Load balancing mechanism of SRC/day IP hash.   If you simply have the uplinks in the vswitch, the ports need to be regular ports of the Meraki side. Load balancing must be either route by virtual port ID or source mac hash. ... View more

Not much to go on but initial guess is your vSwitch isn't failing over properly. What is your teaming policy and settings? A few things to try: - Try manually pinning vmk0 to vminc1, and verify whether the server is still reachable. That will rule out the Meraki side switchport config etc. - With the vmk0 pinned to vmnic0, try removing the cable on vmnic1 and verify whether the UI shows the link as down. If you have VM's, you can also verify that any that were connected to vmnic1 have successfully failed over to vmnic0 - Ensure that your NIC drivers on the server are up to date. ... View more

As @Ryan_Miles said, you're looking under "wireless" which is configuration for standalone AP's.   Configuration for the wireless functionality built into the MX device is under Security & SD-WAN/Teleworker Gateway > Configure > Wireless settings   https://documentation.meraki.com/MX/Wireless/MX_and_Z-Series_Wireless_Settings ... View more

Meraki client vpn doesn't natively support MFA.   You will need to use a 3rd party solution for auth, most if not all of which would be a paid solution in some way.    https://documentation.meraki.com/General_Administration/Other_Topics/Two-Factor_Authentication#Using_Two-Factor_Auth_with_Client_VPN   If your users have m365 licensees, you could look at RADIUS auth to AD/AAD and using MFA built into AAD. ... View more

It looks like HA is constantly kicking in and  failing over the MX VRRP IP. Are you seeing this on the dashboard? What mode are the MX's in and what does the topology look like? Are you seeing any issues with the uplinks? ... View more

As @KarstenI mentioned, SSID's can be enabled and disabled without disruption.   You're correct, using tags would allow you to test on a single AP. When you're done testing, turn off per AP availability and all AP's will broadcast the SSID.   https://documentation.meraki.com/MR/Other_Topics/Using_Tags_to_Broadcast_SSIDs_from_Specific_APs#Specify_Which_APs_Should_Broadcast_a_Specific_SSID ... View more

How exactly does the casting via url and pin work? What is the communication between house and Chromecast? Typically for Chromecast discovery across subnets you need to enable bonjour forwarding. https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Bonjour_Forwarding   ... View more

Meraki switches run RSTP. https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS)#Configuring_STP_Globally   They are interoperable with (but do not run) MST and PVST. The Vlan 1 requirement is if you connect a Meraki switch to a device that does PVST. The connecting device must have a PVST instance on vlan 1 in order for the Meraki switch to receive BPDU's. https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide#PVST.2FPVST.2B ... View more

169.x IP address indicates that the PC hasn't received a DHCP response. Do you see a response received on the client  Wireshark capture?  ... View more

This was my initial assumption but reading a few non authoritative comments (Meraki community linked above and some Reddit posts), it seems to indicate that any NAT or port forwarding rule will bypass the layer 7 rules.   I did a quick and dirty test this morning by geoblocking my own country and testing my VPN (which is a port forward) from my phone. Even with the rule in place, the vpn connected without an issue.   I might try to do another test tomorrow. ... View more

Right, that makes sense. 1:1 NAT and port forwarding are not inspected by layer 7 firewall rules.   https://community.meraki.com/t5/Security-SD-WAN/MX-GEO-IP-filtering-on-Port-Forward-rules/m-p/60930/highlight/true#M15576 ... View more

RADIUS testing polls the RADIUS server once every 24 hours to verify that it's online and serving requests. Disabling it means that you lose the alerting to indicate that the Meraki device cannot reach the RADIUS server.   https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alert_-_Recent_802.1X_Failure#RADIUS_Testing ... View more