I've always been of the opinion that HTTPS inspection sounds great in theory but is still too processor intensive to be truly effective on a security appliance, unless you hugely overspe the appliance. ... View more

because apparent the edit button does not appear to work in Safari: Apple has met the task with their MDM framework, see:  https://support.apple.com/guide/deployment/use-mdm-to-deploy-software-updates-depafd2fad80/1/web/1.0   Why has @PaulF Meraki not yet managed this? ... View more

I don't think the Meraki agent can be "managed" because it's not uninstalled when you remove the device from systems manager. My understanding is managed app's are app's that are provided via VPP only.    You can only push software packages to MacOS devices if the agent is installed, the profile alone does not allow you to install packages from my understanding. The exception to this is the SM agent I believe.   Are your devices enrolled via ABM / ASM or are you enrolling them manually?    Try re-enrolling an affected device to see if it fixes the problem.  ... View more

I guess they went ahead and released 17.10.2 anyway and I'm having the same issue at two of my client sites. Sigh. MX64W: LAN is fine, wifi is trash. ... View more

I never came back to update this post so doing this now. We did end up figuring out the best way for us to implement implicit deny which I wrote up a guide to hopefully save others the headaches we went through. Implicit deny is possible and the link below shares what we learned and how we do it.   Cisco Meraki firewall with implicit deny? Yes, its possible. ... View more

Glad to hear you got it working. It's hard to say what specifically allowed the .msi to run without digging far into this. But, it sounds like the install switches weren't recognized so the .msi failed to run until Meraki recognized a valid switch (/l for logging). Whether this is Meraki's or the .msi file's doing is difficult to say.   I'll be sure to try this out if I run into this same problem though. ... View more

Received this update from Meraki support. At least they know the issue but that leaves us dead in the water.   "The Meraki Engineering team finished investigating the behaviors with Windows 10 & 11 devices and Sentry VPN. The Windows 10 & 11operating system introduced a change in what type of logins and credentials can be used in an MDM environment. Sentry Client VPN was original designed using a method that Windows no longer allows by default and leads to the user being prompted to enter their credentials.  As this is directly related to a change in Windows 10 & 11 behavior and the Sentry Client VPN integration we are currently investigating and tracking improvement on this issue moving forward, however I do not have any further updates on the improvement at this time." ... View more

You are 100% correct. We are trying to do two basic things with Windows MDM: 1. Push out a MSI 2. Have MDM provision a Sentry VPN   For the MSI, Meraki only downloads 16kb of the 41MB file so the MSI does not install. For Sentry VPN, it asks a handful of Windows users for a username and password. Blows my mind this doesn't work as advertised. ... View more

According to the documentation, it seems to be "seen on LAN" when the client has a wired connection and SSID broadcasting together. Share your progress on how you are solving it ... View more

Updateing to MS14.33 on all my networks didn´t cause this issue. We are not working with Meraki MX but with Dell Sonicwall firewalls. ... View more

Does this happen before you created the IGMP querier on the switch or after? If you have not yet created the querier all your multicast traffic will be flooded to all ports on your MS225 including where the MX'es are at.  Or maybe not in some strange Meraki type behavior unless the MX'es start doing some multicast of their own and then those ports receive all video traffic too. Also could you verify you don't have the same multicast mac addresses in your NVX video traffic that collides with the MAC addresses used for VRRP? ... View more

Same here. IDS blocking log4j attempts ... View more

That sounds like the *very* old days before NAT and CIDR..  I don't think it poses any particular issue for Meraki as long as those public addresses are really owned by the ISP and not just served up for reasons unknown, but I don't say that with any particular experience.  It seems easy enough to replicate with some lab gear though.   ... View more

I connected the MR´s with trunk (to get different WLAN´s into different VLAN´s). But I did an allowed VLAN at the trunk ports to avoid spanning-tree issues. I allowed only the necessary VLANs on the ports with MR´s and I switched on "BPDU-guard" because in fact it´s an edge port.   We have different networks with MR42, MR44, MR45, MR46, MR52, MR84 and so on. Switches are MS120, MS220 and MS225. Running firmware is MR28.4 for the accesspoints and MS14.24  up to MS14.29 for the switches.     ... View more

Yes we did, based on documentation Meraki should be sending over IDS/AMP events. We have some, but the security team is saying they are getting everything except that. I am going to explore with them if the issue is on their side and report back. ... View more

Has anyone taken a look at the Meraki.com page today?   https://meraki.cisco.com/product-category/security-sd-wan/ ... View more

Did you  try with ax disabled  in the rf profile ... View more

We are using Cake POS. They are saying it could be a "phantom" network, which sounds like something they have experienced and that is what they call it internally. All other devices on the POS network is printers. None of them are having these issues. ... View more

Not really.  The table "Agent vs Profile Features" lists some of the things that are available on some of the platforms.   https://documentation.meraki.com/SM/Device_Enrollment/Systems_Manager_Agent_and_MDM_Profile_Enrollment#Agent_vs_Profile_Features  ... View more

Hey Todd,   We have not, just that one time. It makes things much easier to manage we enjoy using them. ... View more

Interesting, do you think if we don't use a shared HA mode and instead just do basic failover the MX's have less chance to have a bug or not come online?   The TP Link switch is unmanaged and no spanning tree. The upstream device from that is your typical ISP WAN modem. If we didn't have the second Ubiquiti network I would have had no idea if this was MX or ISP issue. But because the Ubiquiti router came right up the information points to the MX's. ... View more

@IT_Magician As well as being on hold maybe trying opening a support case using the dashboard and select the case as being high priority.    Maybe try a different version of Firmware onthe MX as well? ... View more

We use TP-Link switches on the edge.. non managed of course. This was after days of troubleshooting with Cisco Meraki support they finally said it wasn't supported. I suppose there are ways to do it, but at that point we found non-managed switches on the edge worked best for us. ... View more

Check out my video on building high quality VoIP rules in the MX. Also in each MX, go to SD WAN & traffic shaping and add the public facing IP of your call manager server to check if packet loss is happening on the ISP WAN side.   https://www.youtube.com/watch?v=G57e4oQsHaw ... View more