Here is the warranty coverage period for Meraki devices:  https://documentation.meraki.com/General_Administration/Other_Topics/Returns_(RMAs)%2C_Warranties_and_End-of-Life_Information#Warranty_Coverage_Period   and this is Cisco Meraki Devices purchased Second Hand policy: https://documentation.meraki.com/General_Administration/Inventory_and_Devices/Cisco_Meraki_Devices_purchased_Second_Hand   ... View more

I believe that you used the same email to create both accounts. You may ask another admin to delete your account from the Meraki dashboard. I hope that you have a backup admin 🙂  ... View more

@OVERKILL   it looks like we are getting our information from the same source loool.    I actually enabled AnyConnect in my personal MX using the default port and I noticed many hits in port 443 from random IPs. I know that Meraki has nothing to prevent this because the MX cannot differentiate between legit and malicious traffic since it is listening on port 443. It will eventually drop the malicious traffic but not before using part of the memory/CPU . Let's see what support will say about this. ... View more

Create a new profile and add Android Restrictions. Uncheck Prevent installation of apps from unknown sources and push it to your android phone and you should be able to install unknown apps. ... View more

Your WAP's uptime won't be visible on your dashboard, only support can see that. If you need to know any of your Meraki device's uptime, you will need to email or call Meraki support. ... View more

are you looking for the WAP's uptime or for how long a device was connected to a particular WAP? ... View more

You will have to work with your carrier to see if they have a solution to bypass the GC-NAT and let the MX obtain its own public IP. Or, if they can do manual port-forward, to send all the traffic for UDP port 500/4500 to the MX. ... View more

I don't see any connection between the two services. But, if really someone is sending too many requests to your MX on port 443, (based on what they are doing), your MX may run out of memory and eventually panic, which would explain AnyConnect Restarting and ports are flapping. If this is true, you shouldn't hear any complaints this week since you are using a different port. Also, you may set AnyConnect to use port 443 again but connect a switch between your ISP and the MX to mirror the uplink port of the MX and check what kind of traffic is sent to the MX on port 443. Please let us know what you find, this is really a strange problem. ... View more

Many MS390 were impacted by this bug: ""MS390 management plane can get stuck in a crash loop resulting in the switch staying disconnected from dashboard""" and it was resolved in 14.33, I don't believe that meraki included this fix yet to 15.10. However, if your switches are running 14.33 and still go down, then it would be a good idea to move them to 15.10. ... View more

If you are using an MX80, your ISP should be set to bridge mode, it shouldn't be doing DHCP of traffic inspection. Let the MX handle all the services including DHCP. Also, it would be a good idea to statically assign all your Meraki devices and exclude their IP for the DHCP pool. ... View more

Yes, sometimes cell service can be really wild. I had an MX using cell service that was double Natting + changing the public IP randomly (about 2-3 per day). You may check with the cell provider if they have something that can do port forwarding or something similar. It would be great, but I am not sure if it is possible.  ... View more

If your MX wan interface is connected behind your 2960, check if the switch port has energy-efficient ethernet enabled, if it is, try disabling that feature and see if the MX port will still go down. Good luck ... View more

I bet you that your cellular service is either double NATting your public IP or blocking/overwriting port 500/4500. To confirm this, run a pcap from the MX internet port while you are trying to connect. either you won't see anything or the device is using something different than 500/400. based on the result, you will be able to set a fix for it. OR, you can always use Anyconnect which should be easier to work with compared to L2TP. ... View more

I would stay with what the documentation is saying, if you go outside that boundary it will not be supported. The MX will send VRRP heartbeats across all configured VLANs, so there is no actual benefit to having a dictated port. It would be great if meraki can make that happen but they should have a port only used for HA. ... View more

This was the normal use for HA with Meraki but this has changed in the past couple of years. As you can see in this document, the recommended topologies are to let the VRRP heartbeat go through your switches and don't connect the MXs with each other.   https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Recommended_Topologies   You may have a dedicated HA port between the MXs but that may cause a loop in the meraki stack. In my opinion,  the best way to implement Meraki HA is to use a switch stack downstream as demonstrated in the document above.   This Document explicitly  shows that you shouldn't connect the MXs with each other and let the switch downstream  forward VRRP packets:   https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/General_MX_Best_Practices#High_Availability_and_Redundant_WAN_Connections ... View more

@Justin-F1  This is not possible. You should get in touch with the app developer to find out the best method for mass deployment of their app. (sometimes the app has this information right on their website). ... View more

There is no easy way to do it, the only thing I can think of it is to build an IPsec tunnel between your MX and Azure. Use radius for authentication or AD and point the MX to the private IP of your server which should be reachable through non-meraki VPN. ... View more

This document explains why you received that alert: https://documentation.meraki.com/MR/Radio_Settings/Dynamic_Frequency_Selection_(DFS)   As WW said, you could stop using DFS channels.   Exclude Dynamic Frequency Selection (DFS) https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics/Meraki_Auto_RF%3A__Wi-Fi_Channel_and_Power_Management#Exclude_Dynamic_Frequency_Selection_(DFS) ... View more

If you have networks that have older AP such as MR52, those channels won't even be visible.  ... View more

MR56 APs are compatible with UNII-4 channels.  APs located in the US can use those channels but UK can see the channel but should be able to select them. ... View more

Did you try blocking all remote monitoring & management?   ... View more

That's not possible. Meraki allows you to bypass all or nothing. It would be a great feature but it is not supported by Meraki for now.  ... View more

LLDP is enabled by default. Bounce the port and take another capture from the LAN. ... View more

I don't believe there is an easy way. I would personally search for all known ports used by remote access tools and block them.  ... View more