FYI - A good method for testing whether configuration issues you are seeing on Apple devices are caused by SM or Apple's OS, is to isolate the MDM factor.     Step 1: Unenroll your device and try installing the exact same profile configurations via Apple Configurator.  If the issue remains then you know that there is either a problem with your configuration, or an issue with iOS/macOS/tvOS.   Step 2: If the issue does not persist, export the configuration from Apple Configurator.  Re-enroll your device into SM and deliver the configuration profile as a custom Apple payload. If the issue remains, then you are likely looking at an issue with SM - Call Meraki Support.   Step 3: If the issue does not persist, double-check that the settings in your original SM profile(s) match the settings you created in Apple Configurator.  If you have confirmed a match, then the issue is likely in SM - Call Meraki Support.   ... View more

@hd_IT  Please reach out to Meraki Support.  They can assist you with recovering VPP licenses.   ... View more

@MRCUR @Baustinceltic  It seems you are referencing the System Policy All Files permission, which you can enable today in the "Privacy Preferences" settings payload.  According to Apple's documentation, enabling this permission will "allow the application access to all protected files, including system administration files."       ... View more

A new version of the macOS agent (v 3.0.1), with fixes for Catalina, is now ready for general testing. For access to the agent, please contact your support representative through your case thread.   ... View more

Hi @T1 ,   Previously, if an admin left the "Mandatory" option unchecked in their DEP settings, end users could skip enrollment into Systems Manager on a device after activation.   Beginning with iOS 13, Apple is deprecating this setting, and devices will be forced to enroll after activation if they are associated with an MDM server in Apple Business Manager (ABM). To prevent automated device enrollment into Systems Manager, you will need to disassociate the devices from your SM server by unassigning them in ABM. ... View more

@Richard_W This is on our radar, and we are working on a resolution. We hope to have it fixed on Mojave and Catalina soon. Stay tuned! ... View more

@vassallon A change was pushed last week that should resolve the API rate limiting issue.  Can you try out the bulk action again and verify? ... View more

That is correct. Check out the note at the bottom of the Activation Lock KB article: https://documentation.meraki.com/SM/Monitoring_and_Reporting/Activation_Lock_for_iOS_Devices ... View more

@alexis_cazalaa Thank you for pointing out the column sorting issue. A fix was deployed to address this, can you confirm? With regards to the command failing, is it also failing when selecting only one device (vs. multiples)? In any event, I would suggest opening a support case so that we can triage this effectively. That is correct, the Activation Lock bypass command attempts to clear the Activation Lock status using all known codes, whether that be user-initiated iCloud or ABM/ASM-enabled.  But the lock status is type-agnostic.  You cannot "clear" Activation Lock for one type while leaving the other enabled.  We are considering allowing admins to configure supervised DEP devices to allow user-initiated iCloud activation lock without necessarily enabling ABM activation lock, but this is not a recommended configuration. The ABM/ASM activation lock is far more reliably managed than the personal iCloud activation lock.  There is not a reliable way to ensure that the activation lock bypass code received for a user-initiated iCloud activation lock is 100% accurate.  Also with ABM/ASM activation lock, in the unlikely event that the bypass code does not work, the ABM/ASM account is a known admin account, providing administrators with a reliable bypass alternative if the device is wiped.  ... View more

@vassallon a fix was pushed so that the device counts are accurately displayed ("devices 1-100, 101-200, etc" instead of devices 1-1, 101-101"). Can you verify? If you are having issues with the API rate limit when the command is sent in bulk, please open a support ticket so that we can track, diagnose, and address this appropriately. ... View more

@vassallon  - A couple of new changes to support Activation Lock Bypass   There is a new Activation Lock Bypass API suite, which will allow you to initiate bypass commands in bulk to your device fleet.  As of today, this is still behind NFO and requires a support case for access.  When necessary, Support can also help provide a script which will attempt to unlock all devices. There is also a new Bypass Activation Lock command in the Command menu on the device list page which allows you to send Bypass Activation Lock commands in bulk directly from Dashboard. Admins can now view the current Activation Lock status of all devices using the new Activation Lock column in the device list.  Click the + sign in the upper right of the device list grid to add this column to your view.  Activation Lock status can also be viewed on the device details page under the "Management" section.   For more information about Activation Lock including the updates detailed above, check out the Activation Lock KB article. ... View more

Hi @BenMusgrove @brianb    We have been working on a new version of the Android app which may resolve this issue.  Might you be interested in beta testing this version? If so, please send me a DM with a link to your environment.  I will enable the beta and provide you with further instruction.     -Kevin ... View more

Hi @stevenwhiting @DN  @kYutobi  @Richard_W  @Cmiller    SM was experiencing an issue where device locations were being cached, resulting in the device map initially zooming in on previous device locations, or defaulting to a zoomed out map. We released an update yesterday which appears to have corrected this behavior.  Can you please confirm? Device location tracking via GPS has the following requirements: a) Location Service privileges are enabled for the SM app b) SM app is open and running in the background If both of these conditions are met, and you are continuing to have issues, please open a support case so that a representative can track this issue for you and supply the SM engineering team with the correct device/log information.    ... View more

We're evaluating the best way(s) to share future feature enhancements. Stay tuned! ... View more

@beks88 The default settings are applied immediately after the devices are synced into SM, and they take effect the next time the device is wiped.   ... View more

Hi @RoboTech,   This option is now available in SM.  Go to Systems Manager > DEP and select "Manage Profiles".  You now have the option to nominate a visible profile as default.      ... View more

The default behavior is to automatically enable ABM/ASM Activation Lock ... View more

@vassallon  Unchecking the box will make the Activation Lock prompt go away only if the device was already scoped to the profile at the time of initial activation/enrollment.     For currently enrolled devices (which are presumably currently Activation Locked), you will need to either:   Send a wipe command from the SM Dashboard using the "Attempt to disable activation lock..." flag   Disable activation lock using the available command under MDM Commands > Mobile Security on the Device Details page before wiping the device   After devices are re-enrolled, SM will not try to activation lock again if the device is scoped to a profile where "Allow Activation Lock" is unchecked. ... View more

@jm_peterson @Newt   Also, strategically speaking, if you are managing Windows devices exclusively, you may consider deploying the new Agent to clients en masse using AD GPO rules.  If Mac OS, consider sending new installation commands from the Agent App screen in Dashboard (see image below).         ... View more