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

Take a look at this previous topic.   https://community.meraki.com/t5/Wireless-LAN/How-to-check-the-blocked-clients-list/m-p/7765 ... 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

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

@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

The log entries actually show that the splash page frequency is configured to one hour (3600 seconds).  Look at each line that shows a Splash Authentication.   As suggested by @kYutobi , you should modify the Splash Page Frequency setting. ... View more

Have you considered VLAN tagging?   You can set your guest SSID to tag with a different VLAN and use the "different gateway" to provide DHCP.  That approach would provide you with the level of control you're looking for over the traffic routing. ... 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 devnet sandbox is a good place to start.  When you open the sandbox, you should see a username and password that you can use to login to Meraki Dashboard at meraki.cisco.com.  You will also see an API key that you can use with the dashboard APIs.   Once you login to Meraki Dashboard (using the credentials from the Sandbox page), go to Help > API docs.   https://create.meraki.io/ is also a great resource for getting started. ... 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

The API does not appear to support setting different group policies for a client by SSID.  I'm not aware of any workaround. ... View more

Your idea that Meraki keeps the OS information when a device previously connected to the network sounds reasonable.   I doubt that Meraki would make that information available across organizations, but there's no way to know for sure without either testing yourself or getting Meraki to tell you. ... View more

I did a quick scan of some data from the Scanning API in a couple of environments.  I only see a value for OS when the device is connected to the network.   I've never seen details from Meraki on how they identify the OS.  I would guess that they are using fingerprints of certain network traffic, similar to remote OS detection in nmap.  Meraki appears to keep its own database when people flag the device type as inaccurate in Meraki Dashboard.   If this guess is accurate, a device would have to associate to the network prior to OS detection.  The results of OS detection may be inaccurate, especially when new devices, drivers, and OS versions are released.   There's a decent chance that similar technology is used for detecting rouge access points on the LAN. ... View more

You can create a group policy that bypasses the splash page and then apply that group policy to any user you want to be connected for more than 3 months.   If you want to automate the solution, you have a couple of options.  You can host your own splash page and make an API call into Meraki to apply the group policy after the user clicks through your splash page.  You can also use MAC-based access control with a RADIUS server and set the group policy in the RADIUS reply.   You might also want to open a case with Meraki to see if they have any other configuration options available to you. ... View more

You probably already considered this, but I wanted to make sure.   In most environments I set up that require some type of sign-in through a splash page, we configure a walled garden.  This allows the device to navigate around the splash page, view T&Cs, and sometimes access promotional content prior to completing the sign-in/splash process.   You then set up the splash interval to something that you would expect.  Sometimes hours, sometimes days, sometimes longer.  Depends on the goals and the customer. ... View more

A quick and dirty approach is to create a Group Policy that does not require a splash page.  After the user signs in, you can use the Dashboard API to apply that group policy to their device.  At some future point, you can remove the group policy from their device, which will cause the splash page to appear again.   As Philip suggests, you can get more control using Sign-On splash with RADIUS, interim updates, and CoA disconnects.  See https://documentation.meraki.com/MR/Splash_Page/Interim_Updates_for_Splash_Sign-on   Hosting your own RADIUS server gives you a lot more control. ... View more