I don’t know as I am not really into Windows … But for this use case I would also consider FreeRADIUS. It could also save you some time entering all the MAC addresses. ... View more

It is not Meraki-managed, but the C9200CX-8UXG-2XH can at least be cloud-monitored and has UPOE. ... View more

Capture the problematic traffic on the MX LAN-side to see if the traffic is entering and leaving the MX. ... View more

Sounds like if the Windows firewall is blocking incoming connections. ... View more

I am running 30.7 and 802.1X is working as before. Can you post what you see on the Dashboard-Log? But I would also open a support case to let Meraki look at the problem while you try to authenticate. ... View more

Good Choice! Congratulations! ... View more

With Meraki APs, you also can tunnel WLAN traffic to a concentrator device (which is a Meraki MX): https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Tunneling_and_Layer_3_Roaming_-_VPN_Concentration_Configuration_Guide ... View more

I would add another recommendation that is not mentioned in your question: If you don't know which channel width is the best for your environment, go for 40 MHz in the 5 GHz band. ... View more

You also have to configure the Supplicant: https://aventistech.com/kb/deploy-wireless-network-with-group-policy/ ... View more

You have to tell the end device to use EAP-TLS. Otherwise, it will likely default to PEAP and continue with username/password. ... View more

What @rwiesmann said. In addition to that, make sure the native VLAN is part of your allowed VLAN List. ... View more

The native VLAN is always untagged. The AP needs to match this config. The easiest way to do it: - Put the AP onto the native VLAN - Tag the WLAN traffic into the other VLANs. ... View more

Best? Yes. Easy? Not always. I have customers, where the only available ISPs have no product for this. They only offer what you showed, a /30 transfer and a /29 or /28 routed network. ... View more

Unclear or even wrong. "Z-Series (...) licenses can be added to organizations regardless of the MX license type currently applied." is obviously not correct. ... View more

Ultimately, it will likely be a Trunk to have VLANs for your SSIDs. But for the AP itself, it requests a DHCP address untagged, and an Access-Port would be enough to show up in the dashboard. ... View more

This is the other way round than what was discussed here. But good to have it confirmed that the Z4 needs to follow the Org-Level of the MX. ... View more

Technically correct, but I would not accept something like that in my networks. It could be addressed by chance or even intentionally and bypass the firewall controls.  This is a workaround that screams, "I will make trouble when you don't think about it any more". ... View more

Do I understand you right that you want to route unicast on the MX and Multicast on the MS? That won't work, and if it did, it would open a can of worms. This is a scenario where the MX as a routing device is likely not the best fit. ... View more

Your failure description is inconsistent. But based on your post I assume that it is connected but any of the next needed steps are not working. Wireless Health in the dashboard can give you some hints. Look especially at: DHCP and DNS. ... View more

Accidentally configured a device restriction to 5GHz? My 6GHz capable clients connect happily with 6GHz.  And I miss a nice connection statistics view (as it is available in Mist) on the Meraki platform. ... View more

I would skip the "especially" as it is basically the same work for 1, 10 or 100 networks.    My best practice is typically to move these tunnels away from the MX to a different device because there are no inbound filters for these VPNs and the whole network is exposed to the peer. ... View more

The "very small config" is based on the fact that you do *not* configure one tunnel per branch office. Four your 20 sites, you configure exactly one line in the dashboard. But by referencing 20, 50, 100 networks in the availability, the tunnel is setup on all these networks.   This is needed because on Meraki we *do not* have routing between non-Meraki and AutoVPN tunnels.    The term "non-Meraki VPN-hub" is nothing official. It was meant to emphasise that the peer for these tunnels is not a Meraki Hub in the same dashboard org. Because in AutoVPN we would have full routing capabilities. ... View more

Oh, ok ... and you could cool it down even more. 🙂 ... View more