Thanks for the heads up.   However to clarify, the  /devices/ {serial} /reboot API endpoint has always been there, (since the first release of the API a couple of years ago, as I was doing this already back then) but it was undocumented and it was also not exposed in the python client bindings, which is why I had to manually construct the http request to call to that endpoint in the reboot_ap() function.   I see from your link that the API endpoint is now finally documented, however I have not checked to see if there is a new version of the meraki python client bindings which add it as a proper python function call yet. (At the time of my post a month ago, it was not in the python client bindings)   In any case the script above is still working and I use it to auto reboot our AP's once a week. ... View more

Here's my own version of a bulk AP reboot script...   Because Meraki steadfastly refuse to add any sort of bulk AP reboot facility to the dashboard (I've asked them on several occasions and they say they won't consider it, and that I "shouldn't need to reboot multiple AP's" without considering the use case where yes, you do actually want to do this and every other vendor providing a way) a couple of years ago I wrote a stand alone python script to do bulk AP reboots based on device tags, so that I can reboot either all AP's in the network, or AP's with a specific tag.   As we have building name tags on our AP's to make it easier to group AP's based on building it makes it easy to reboot AP's in a certain building for example, and it would also be easy to add tags to AP's based on collections of AP's you might want to bulk reboot.   The script originally used the v0 API but when I recently tried to use it I found it was broken due to changes in the API (such as tags going from a space separated list in a single string, to an array of tags) and python Meraki module changes so I've updated it to work with the current V1 API and current Meraki python module.               #!/usr/bin/env python3 import json import requests import time import meraki import sys import datetime def reboot_ap(apikey, networkid, serial, suppressprint=False): base_url = 'https://api.meraki.com/api/v1' calltype = 'Device' posturl = '{0}/networks/{1}/devices/{2}/reboot'.format( str(base_url), str(networkid), str(serial)) headers = { 'x-cisco-meraki-api-key': format(str(apikey)), 'Content-Type': 'application/json' } postdata = { 'serial': format(str(serial)) } dashboard = requests.post(posturl, data=json.dumps(postdata), headers=headers) print(dashboard.status_code, dashboard.text, calltype) return apikey = 'api_key_here' network_id = 'network_id_here' reboot_all = False cmdline = False if len(sys.argv) > 1: cmdline = True if sys.argv[1] == '--all': reboot_tag = None reboot_all = True else: reboot_tag = sys.argv[1] dashboard = meraki.DashboardAPI(apikey, suppress_logging=True) deviceList = dashboard.networks.getNetworkDevices(network_id) tag_list = [] for device in deviceList: new_tags = device['tags'] for tag in new_tags: if not tag in tag_list: tag_list.append(tag) now = datetime.datetime.now() print(now.strftime("%H:%M:%S %d-%m-%Y")) print('Available Tags:\n') for tag in tag_list: print(tag) if cmdline is False: reboot_tag = input("\nEnter Tag of APs to reboot or press enter for all APs: ") if not reboot_tag: reboot_all = True print('\nRebooting Devices:\n') for device in deviceList: if reboot_tag in device['tags'] or reboot_all: try: name = device['name'] except: name = 'unknown' print(name, device['serial'], device['lanIp'], device['tags'], '- ',end='') reboot_ap(apikey, network_id, device['serial']) time.sleep(0.5) print()               I'm pretty rusty with Python and this was a quick expedient script to get the job done in a hurry so I'm sure the Pythonistas in the audience will be rolling their eyes at the coding... 🙂   If you run the script without command line arguments it will scan all the devices in the wireless network gathering the tags from each device to build a list of all available network device tags, these tags are then displayed. You are then prompted to either press enter (which will reboot ALL AP's in the network, be careful.. press CTRL-C if you want to back out) or enter a tag name to reboot only those AP's with that tag.   There is a 0.5 second delay between each reboot API call as if you call more than about every 0.2 seconds the API will reject the request. The success/failed result for each device will be displayed.   If you use a single command line argument '--all' can be used to reboot all AP's without prompting (for example from a cron script) or you can use a tag name to reboot devices with that Tag without prompting.   I use this script on Python 3.8 on Linux with the Meraki pip module installed. I don't think it relies on any other non-standard modules. While this version of the script hasn't been tested on Windows it should work as my original version did.   Incidentally the Meraki Python module doesn't seem to have a reboot API call, nor does the official documentation list a reboot call, hence why the actual reboot action is hand coded as an HTML query using the requests library - I simply took one of the other example requests, changed the action to reboot and it worked! 🙂   Hope someone finds this useful. ... View more

Hi Paul,   Thanks for the reply. I watched your video as well but as we don't push out WiFi protocols for BYO devices (users have their own username and password authenticated via radius) that doesn't help our situation. (Although I have enabled that in the WiFi profile we push to company owned and managed devices before they update to iOS 14)   One small saving grace is that Systems Manager Sentry is not able to authorize a device with MAC randomisation enabled (since it can't correlate the WiFi and MDM MAC addresses) so a user can't get past the sentry until they manually disable MAC randomisation in their WiFi settings. Not very user friendly (they need to be informed out-of-band that they need to do this) but at least it prevents devices connecting and being able to use WiFi until this is done, and at that point all MAC based functionality will be working again.   I agree that there needs to be a device wide MDM setting for this for enterprises to disable this feature on their managed devices, although even then they would still initially connect with a randomised MAC address until they had enrolled and received the profile, at which point the device would presumably reconnect with the correct MAC address, leaving behind a "ghost" device in the WiFi device list.   A bit a of a mess really but this is typical of Apple introducing far reaching changes to how fundamental technology works without providing a way for enterprises to manage it properly. ... View more

MAC address randomisation (or "Private address" as iOS settings call it) on iOS 14 breaks Systems Manager sentry enrolment which we've relied on for the last 3 years.  😐   The sequence goes like this:   1) The user connects to the SSID, attempts to browse and is redirected to the enrolment page by the Sentry. 2) The user downloads and installs the MDM profile which registers the MAC address of the device in MDM. 3) Meraki whitelists the MAC address found in the MDM profile on the SSID to allow the user to access the internet. 4) The WiFi Mac address of the device does not match the MDM Mac address so the user remains trapped in the Sentry being redirected back to reinstall the profile again and again...   So far I haven't found any fix other than telling users to manually turn off the Private Address setting in their WiFi settings, which is a huge pain in the neck when you have hundreds of users and they're all under 18 so aren't good at following instructions...   While there is an MDM profile setting to disable Private address it looks like it can only be applied to WiFi networks which are deployed by profile. We don't use WiFi profile deployment for BYO devices - users have their own individual usernames and passwords to gain access to the SSID, and the Sentry then takes care of ensuring they enrol their device before they can have internet access. (Although that is also broken at the moment due to an unrelated issue)   Once again Apple adds a "user privacy" feature which breaks enterprise use of iOS devices without providing an enterprise mechanism to turn it off! ... View more

Thanks - I tested this yesterday and it has worked for me on both VPP accounts as well.   Normally this would be a minor problem but in these days of needing to provision apps to staff working remotely at home it became a critical problem for us, so it's a relief to see it fixed. ... View more

Strangely I was able to add one user as well but only the one... every attempt since has failed including email addresses that have never been invited before. ... View more

Hi Noah,   DM sent.   ... View more

Hi,   Meraki support have now acknowledged a "known issue" regarding not being able to invite VPP users however it is still not fixed and no ETA. Like you all our staff are now working from home for the forseeable future so this is a major problem for us.   I am continuing to chase Meraki but do not feel they are taking this seriously. ... View more

Hi,   I've been on the phone to Apple Education Support for an hour this morning, the guy was very helpful and went out of his way but the end conclusion is that the problem is not on Apple's side and that it must be a problem with Meraki or the Meraki Dashboard.   So back to Meraki I go again....   ... View more

Wall of text would be if I didn't leave any paragraph breaks....  😉   So nobody else has noticed that Systems Manager Sentry doesn't actually enforce enrolment and is easily bypassed by end users ? I can't be the only one to notice this... ... View more