I don't see the Forget button on my dashboard either.  This might be a region-specific feature or related to GDPR compliance.   In any case, I believe that setting the group policy to Normal is the closest you can come to removing the client setting unless you have the extra privacy settings enabled in your region.  This is just a guess and an area that Meraki support should be able to provide more detail. ... View more

I think you want to remove the policy you assigned to the client (with the wrong MAC address).  Your screenshot provides a hint with the "only clients with a policy" in the text.   For more details, take a look at the following older post.  I know it's talking about blocked clients, but you can use the same steps to remove whitelisted clients.   https://community.meraki.com/t5/Wireless-LAN/How-to-check-the-blocked-clients-list/m-p/7765 ... View more

I don’t have anything Meraki-specific to share. If possible, you should test the app upgrade path independent of any MDM solution (rebuilt from a previous version if necessary) and confirm that data is preserved correctly.  If you make changes related to how you store data, it can appear that everything got deleted, when your new version is just trying to access the information somewhere else.   with that said, I can’t think of any MDM setting that would update an app in place and remove stored user data. ... View more

I don't think anyone has mentioned the impact of the "RADIUS Proxy" setting on the Access Control Configuration page.   If you do not use RADIUS Proxy, I believe the RADIUS messages will originate from the management interface of each access point.   If you do use RADIUS Proxy, the messages will originate from Meraki cloud as indicated on the firewall info page.   In one of my networks where I use RADIUS proxy, the firewall info page shows a line for port 1812 where the source IP contains three networks (two /24 and one /20).  The destination IP shows the addresses of my two RADIUS servers.  When I did the initial setup, I added the three Meraki-provided CIDR ranges as allowed clients in my RADIUS configuration. ... View more

I'm not sure what you're trying to test, but you might be able to meet your need using a Meraki Dashboard Live Demo.  If you don't already have a demo account, try this link: https://meraki.cisco.com/form/demo   With a live demo, you can create new networks in Meraki Dashboard and add whatever hardware you want.  It's not a real network, but a fair amount of fake data will appear in dashboard and you will be able to make whatever configuration changes you need.   Of course, you can also work with your Meraki sales rep to get a reasonable amount of demo hardware. ... View more

The heat map data is not available through any public API.   You can use the Location API to receive all location information and use that data to built your own heatmap.  Showing locations on a map is relatively simple.  Producing your own heat map would take more effort. ... View more

The better approach is to have your RADIUS server correctly authenticate users based on the SSID.  The SSID is sent to the RADIUS server as the Called-Station-ID.   If you can't get your RADIUS server to support this use case, here's an alternate approach.  I will admit that this approach is a bit clunky, but you're only trying to make this work for one person.   1. Set the BOSS ssid to use a Splash page and use Meraki authentication.  I would also set the captive portal strength to block all access.   2. Create a group policy and set it to bypass the splash page.   3. Assign the new group policy to each device belonging to the boss.  I suggest using the per-SSID group policy assignment so that you only assign this policy on the special SSID.   Other devices will be able to connect to the BOSS ssid, but they will only get the splash page and they won't have a Meraki user to login.   That should be enough to make this work.  I guess some people need to be more equal than others. ... View more

You're correct that Meraki needs at least three access points to triangulate client location.   You will get more reliable location data within the area defined by your set of access points (technically, within the two-dimensional convex hull defined by your access points).  Outside of that area, Meraki tries to determine a location, but the results aren't as good as you'll see inside the area.   If you want really good location data, you should think about every possible position on your property.  At each point, consider four directional quadrants.  You want an access point in 3 out of those 4 quadrants within a range of about 3m to 25m (not the exact numbers, just from memory).  You won't get a perfect layout, but this is a way to approximate the quality of your plan from a location accuracy perspective. ... View more

Be prepared for some pain when you try to keep Facebook login working in a captive portal environment.  The web resources accessed by the login pages do change from time to time and you're going to need to keep your walled garden ranges up to date.  You will find some resources online to help, but there's no substitute for testing and monitoring.   It sounds like you've selected a client-based login flow using Javascript (I'm partially guessing here).  If so, reconsider that decision if possible.  You're really setting yourself up for a world of future pain.  I have found the server-to-server flows to be more stable.  You also get a better place to monitor for user issues.   You should also be careful about your Facebook application permissions, as they control what data is shared with you.   On a related subject, make sure you do some testing with other Facebook accounts.  You may find that permissions seem pretty loose when using your own account, if you also created the Facebook application and related tokens yourself.  When using other accounts, you often need to go through Facebook's review process to be able to access the data you need.   Facebook WiFi provides for a pretty narrow use case.  I'm not surprised you've decided to create your own solution.   Not sure if that's the information you were looking for.  Feel free to ask if you have further questions.  I've been spending more time with unique captive portal promotions based on customer behavior rather than on specific social login scenarios.  My info may be a little rusty. ... View more

This article should clarify what happened when you added the new license and it was spread across all of your devices. https://documentation.meraki.com/zGeneral_Administration/Licensing/Cisco_Meraki_Licensing_Guidelines_and_Limitations/The_Science_Behind_Licensing_Co-Termination ... View more

@BretD is correct that you will need help from support to move the licenses.  Don't let that stop you from getting the network up and going.  There's a grace period to get the license issue solved.   When you unclaim devices, there's a period of time before you can claim the device in a different organization.  Meraki's documentation suggests around 5-10 minutes.   There's really no difference between your 2nd and 3rd scenarios.  The steps you follow to move the device around are the same. ... View more

I think Sign-on Splash is going to be your best solution.  You can configure Sign-on Splash to use your radius server for authentication.   This approach provides the same level of flexibility as click-through splash and you can do whatever voucher validation you want.  You then send the user to the login url with pre-filled username/password.  These values can be one-time use, if you need.   Meraki then sends an access-request to your radius server, so you can confirm that the login is valid. ... View more

You probably already know... Meraki supports both "Click-thru Splash" and "Login Splash" for captive portal.  The click-thru doesn't include mauth and doesn't use RADIUS to verify the credentials.  Login splash provides a destination URL to authorize the client.   With your mobile app and proper walled garden, you don't need to show the captive portal page at all.   Instead, have your back-end server call the appropriate Meraki Dashboard API.   PUT /networks/[id]/clients/[mac]/splashAuthorizationStatus   or   PUT /networks/[networkId]/clients/[mac]/policy   To use the second option, you would create a group policy that allows the client device to skip the captive portal page.  With the first option, the authorization automatically expires.  Group policies remain until you remove or change them. ... View more

You can use the "Walled Garden" to allow traffic between your mobile application and a back-end system that you control prior to any type of login.  Your application would authenticate the user using your back-end system, which would then use Meraki's API to either set the splash authorization for the client or apply a group policy.  Note that obtaining the client mac address may be challenging with this approach.   You could also provide a special SSID for your application-based connections, use WPA2-Enterprise with RADIUS, and code your application to programmatically connect to the SSID.  You would need a custom RADIUS server to authenticate your mobile app users correctly.   Generating a user-specific WiFi profile might be another viable option, although I haven't thought through all of the details. ... View more

The Dashboard API does not currently allow you to set different policies by SSID for a client (according to the documentation).   For a possible workaround, take a look at this thread.  I haven't tried this approach myself.  You would have to figure out what value corresponds to your group policy.   https://community.meraki.com/t5/Wireless-LAN/API-Block-a-device-from-an-SSID/m-p/37958#M5965 ... View more

Meraki does use standard ports and protocols for cloud management.  Some customers have additional communication needs for things like splash pages, RADIUS, Meraki APIs and so-on.  If you only need to support cloud management, you can probably use a single set of rules.   You might consider contacting Meraki support directly for assistance.  They may be able to provide more details. ... View more

The exact ranges vary by customer and the specific features being used.   From Meraki Dashboard, go to the Help drop-down (top-right) and select "Firewall Info".  You will see a list of source, destination, port, port, protocol, direction, and description.  This information should allow you to correctly configure your firewall rules. ... View more