If you want to ensure no WiFi, you're probably best to switch off the AP at the switch port:   https://developer.cisco.com/meraki/api-v1/#!update-device-switch-port   poeEnabled : false ... View more

Next time, while it's happening, run some pcaps on the Internet interface of the MXs at each end;   see what traffic is being generated and received by each.   https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview#MX_Appliances_and_Teleworker_Gateways   ... View more

This definitely won't work, in the way described;   there's no route availability between AutoVPN and non-Meraki VPN tunnels in the same MX (or vMX):   https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior#AutoVPN_and_Non-Meraki_VPN_peers   Is there a particular reason why the customer wants to route the traffic through Azure? ... View more

The settings for Meraki devices are backed up, by default;   the config resides in the Dashboard and is pushed down to the device after creation.   You can get a flavour for this by looking at how you'd deploy a replacement MX unit (e.g. for RMA) here:   https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX ... View more

There's no way to tell, given just this information, whether the MT is faulty or not.   I would try moving some of your MT11s around, if you can and see how things change (or not) between sensor and environment.  In particular, if you have another one providing the kind of values you expect, could you deploy it, for a short time, alongside the existing one, to see how their results compare?   I've found that humidity changes quite a lot, in relatively short periods of time, in some environments. ... View more

Remember also;  the MX is, by default, a firewall.  If traffic is deemed to be 'outside VPN'  (e.g. if a local VLAN is set to 'VPN off'') then it will be NAT'ed behind the IP address of the chosen WAN uplink, through which it egresses.   If that uplink is connected to the MPLS, you will need to bear this in mind, within the MPLS routing.   Moreover, if you wish some kind of server, on the LAN side of the MX, to be accessible, via an inbound request over the MPLS, you will have to set up port forwarding or an inbound NAT,  otherwise unsolicited inbound packets are, by default, dropped. https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#Forwarding_rules   Meraki has been working on a 'no-NAT' feature, but this is in beta, for the time being:   https://documentation.meraki.com/MX/Networks_and_Routing/NAT_Exceptions-No_NAT_on_MX_Security_Appliances     ... View more

Just to confirm:   at FCS it's definitely x2 active WAN uplinks, as other models, but you now have media flexibility.   I have requested that the datasheets be amended to bring clarity in this. ... View more

Licences are neither co-term, nor PDL, in themselves;   a license can be added to either type of Organization.   Typically, for rollouts into co-term Orgs, which happen over a period of time, any delays between order and usage can be accounted for within the solution pricing;  that's why it's important to plan migrations effectively and communicate these with the Cisco Meraki team, prior to placing orders.   Remember that Meraki Zero Touch Provisioning, maybe coupled with Templates or API-based automation, can also make your rollouts extremely rapid! ... View more

One other thing I noticed;   when you said WAN2 will connect to a private network and will have a private IP address and (therefore?) will not work - that isn't necessarily true.   Provided the MX on the other side of your private network can communicate with the Internet / the Meraki Dashboard across the WAN, then it probably will successfully form a VPN tunnel, and will do so between the private IP addresses assigned to the two MXs.  This is one of the key principles behind Meraki SD-WAN;  provided MXs can communicate with the VPN registry in Dashboard and with each other, using IP, the solution doesn't much care what kind of network it's running over. ... View more

I think you need to raise a case with the Meraki Support team - they'll be able to see precisely what the MX is doing and help from there.   Different choices for accessing Support are available under Help > Get help in the Dashboard.   Be aware that telephone receives priority, for rapidity of response. ... View more

The Dashboard API functionality for MT sensors is in beta and will need enabling in your Dashboard Organization.  Can I suggest you reach out to your Meraki account team to gain access?  PM me if you have trouble… ... View more

I'm not sure, off the top of my head, but I would say it's one to raise as a case with Meraki Support. ... View more

Actually, subnet translation might work on non-Meraki VPN, but it's not supported.   I had a customer try this, a few years back, despite it not being officiallly supported - and it apparently worked.   I discovered later that they'd stopped using the feature, but without any feedback, unfortunately.   As someone else asked, it would be good to understand the use case. ... View more

So - you want to split tunnel all of your Internet-bound traffic EXCEPT O365?    I'm rather surprised by that - it's the opposite of what most people ask for. The only way to achieve this is to leave the default route box unchecked, when you choose your spokes, then make your O365 traffic VPN, rather than Internet traffic - by advertising the relevant IPs and subnets for O365, from your hub site, towards your dependent spokes.    As @PhilipDAth has said previously in this thread, it's painful, but possible.   Bear in mind you would manually need to keep the advertisements in sync with any changes made at the Microsoft end.  It's this 'automatically keeping up with MS' functionality which is key to the smart exceptions feature we created. ... View more

Even better, thank you!  😁    Learn a new thing every day... ... View more

You should really create a new post for this separate enquiry...   Leaving that aside - you use the term 'aggregate';  MX does not support link aggregation (802.3ad / LACP or similar).   With MX you provide a separate WAN (Internet) uplink to each of WAN1 and WAN2 ports and the MX can make use of both links simultaneously, by allocating different sessions to different links, based upon preference and performance criteria you configure.  so;   don't configure any link aggregation on your switches, for connection to the MXs. Each of your MXs should be connected to both switches, on the LAN side, for resilience (your diagram shows only one such link per MX).  Note however that MX does not participate in spanning tree, but will forward STP BPDUs, to allow your switches to resolve the physical loops that will create.  So;  configure STP on the switches to match the desired topology (e.g. bridge priority).    Provided you do this properly and use different VLANs for WAN1, WAN2 and LAN-side VLANs, you should not get into STP-related problems. ... View more