A large component of UEM that often goes unaddressed is the need to manage devices that are on closed or restrictive networks. Many times this comes in the form of nation-state restrictions (China, for example) or organizational restrictions (government and secure facilities).
Many times, as is the case with iOS, device management "is what it is," meaning that there has to be access to the App Store in order to download and install a majority of apps. Android management is a little bit different, and while it is in a state of flux, there are still options to manage the devices with a few extra configurations.
It is important to note that the MaaS360 recommended enrollment method for Android devices on 8.0+ is Android Enterprise, however that requires a lot of integration with the Play store, which in the scenario discussed here may not be feasible. We are working instead with Device Admin (DA) enrollments.
DA is considered deprecated with Android 10+, however, the enrollments and a majority of security features still function. This may not always be the case down the road, which could lead to some frustrating times ahead. IBM and Google work together frequently to address these concerns in any way we can, but admins need to be aware that there may come a time when provisioning devices directly in some of these restrictive environments may not be possible, especially in nation-states where country wide firewall rules can change on a whim.
Getting Set Up with Android Configurator
In the portal, navigate to Devices-->Enrollments-->Other Enrollment Options and there will be a selection titled Android Configurator. If you do not see this option in your portal, please contact our support team.
A pop-up window containing download links will be presented. The core agent is the primary app for enrollment. The helper agents do assist in scenarios where OEMs are supported in DA enrollments, but the core agent is always used for enrollment and initial provisioning.
There is also the option to configure the device enrollment with a config file or QR code. These are not required, but they certainly expedite the process in some scenarios. For example, a company may be provisioning devices for an area with a restricted network. All of the devices may be enrolled as the same "user" (which, in actuality, could be a location, a building, or a vehicle).
An admin simply needs to side load the app by tethering the device to a computer via USB, copy the config file to the same download or root folder, and then simply launch the app and tap a few options to get up and running.
Fill out the fields with the proper info
A configuration XML or QR Code will be generated and dowloaded (sensitive content will be encrypted, so it is safe for transport)
Side load the app and XML file on to the device - keep both in the same location. Windows admins can use file explorer, and if you're using a Mac, Android File Transfer can be downloaded for free here: https://www.android.com/filetransfer/
Connect the device to a network (there is some connectivity required. This, or any other, enrollment is not possible in air gapped environments), navigate to the file location, and tap the APK filename to install. Please Note: Applications available for file navigation on the device vary from manufacturer-to-manufacturer. A 3rd party app may be required (these can often be obtained for free from the Play store). In this scenario all screenshots are from a Google Pixel.
Now that device is enrolled, there may come a need to use MaaS360 to install a variety of other services to aid in management.
VPN - often used to circumvent location based rules that prevent certain features. MaaS360 has a VPN service that we can provide to address this (client will only need a Windows server to install it). I've certainly dealt with a fair share of clients who deploy MaaS360 VPN just for these devices.
App Catalog - To address restrictions to Google Play access, admins may need to reach out to app developers to gain access to APK files for distribution. This way MaaS360 can make them available directly, outside of Google services. Please note that there are ways to "fetch" APK files from the public Play store, but these violate Googles terms and conditions, and MaaS360 does not support these scenarios.
General policy can address restrictions on the device locally (for example - removing camera capabilities on devices in sensitive locations) and configurations should be able to populate on the device, provided all the required ports, IPs, and URLs are whitelisted.
Google Play IDs are not required for the workflows outlined here, but will be necessary for Play apps.
As always, if an open and fairly free-flowing network is available, that will provide the best possible experience, at least for getting started. Don't forget to whitelist MaaS360 in your firewalls while we're here:
more specifically dl.maas360.com
services.maas360.com if your account number starts with a 1
services.m#.maas360.com for every other account - just replace # with whatever number yours starts with (2-6).
Google URLS/Ports for device services:
google-analytics.com googleusercontent.com *gstatic.com
|TCP/443 TCP,UDP/5228-5 230
||Google Play and updates
gstatic.com, googleusercontent.com - contains User Generated Content (e.g. app icons in the store)
*gvt1.com, *.ggpht, dl.google.com, dl-ssl.google.com, android.clients.google.com -
Download apps and updates, Play Store APIs gvt2.com and gvt3.com are used for Play connectivity monitoring for diagnostics.
||EMM/Google APIs/PlayStore APIs
||Authentication For accounts.google.[country], use your local top-level domain for [country]. For example, for Australia use accounts.google.com.au, and for United Kingdom use accounts.google.co.uk.
|gcm-http.googleapis.com gcm-xmpp.googleapis.com android.googleapis.com
||Google Cloud Messaging (e.g. EMM Console <-> DPC communication, like pushing configs)
||Firebase Cloud Messaging (e.g. Find My Device, EMM Console <-> DPC communication, like pushing configs)
||Certificate Revocation list checks for Google-issued certificates
|clients2.google.com clients3.google.com clients4.google.com clients5.google.com clients6.google.com
||Domains shared by various Google backend services such as crash reporting, Chrome Bookmark Sync, time sync (tlsdate), and many others
||CloudDPC download URL used
|connectivitycheck.android.c om www.google.com
||Connectivity check prior to CloudDPC v470 Android connectivity check starting with N MR1 requires https://www.google.com/gener ate_204 to be reachable, or for the given WiFi network to