As Google pushes administrators to use Android Enterprise, IT must use a supported enterprise mobility management...
tool, such as Microsoft Intune.
Google will deprecate certain APIs that support legacy Android OS management, such as APIs that deal with password management and security settings, and force administrators that want access to these APIs to use the Android Enterprise versions. The Android Management API enables admins to natively manage the following Android Enterprise device scenarios:
- work profile for BYOD
- corporate-owned, single-use (COSU)
- corporate-owned, business-only (COBO)
Microsoft Intune support for the BYOD and COSU scenarios is available via Android Enterprise, and Microsoft recently previewed support for the COBO scenario. In the future, the Android Management API will also support the corporate-owned, personally enabled (COPE) scenario for Android device management. Once the API adds this support, mobile admins will be able to use Intune's existing support of COPE.
Looking at the architecture and scenario support
Microsoft Intune manages enrolled devices with the native Android Management API, which enables Microsoft to be more agile when it comes to adopting new features or new device scenarios offered by Google. By using this API, Microsoft Intune doesn't need any local agents, such as Microsoft Company Portal, to completely manage enrolled devices via one of the device owner scenarios.
IT can use managed Google Play and the device policy controller to manage devices' apps and policies via Microsoft Intune. For BYOD devices, IT should create and manage a work profile and nothing else. IT can accomplish this with a device policy controller application on the mobile device; in many cases, enterprise mobility management software can perform this task.
The COSU Android device management scenario is meant for kiosk devices with one purpose, such as logging sales or tracking patient data in hospitals. Policies in Microsoft Intune enable IT to lock down all aspects of the device that aren't related to its purpose. IT professionals can only enroll a device into the COSU scenario if the device is brand-new or if it has undergone a factory reset.
IT can enroll a new device with near-field communication (NFC), a QR code or a token, which is a unique set of letters that serves as an activation code. To start this process, IT must create a corporate-owned dedicated device token in Microsoft Intune. Intune admins can share this token as a QR code or as the token's activation code; it can also be transmitted to a device with an NFC tag.
When IT uses the QR code or token method, Microsoft Intune automatically enrolls the device with Intune. The device won't have a user affinity in place, which would associate the device with one user, because it's dedicated to the role of a kiosk device.
COBO is a bit different from BYOD and COSU, and as of January 2019, its native Android device management is still in public preview for Microsoft Intune. While the COSU scenario enables Intune admins to create more than one token, COBO only supports creating one token.
In the Intune console, IT pros should navigate to Device Enrollment > Android Enrollment. Then, they should select Corporate-Owned, Fully-Managed User Devices (Preview). From there, admins can create the enrollment token.
Users will need the QR code above to authenticate with their usernames and passwords to define user affinity.
After the user and Intune admin ensure that they have successfully enrolled the device in Intune, they will see the device in the Microsoft Intune portal as an Android fully managed OS.
Intune administrators can completely wipe the device because it is fully managed. For devices in the BYOD Android device management scenario, IT doesn't have that option because it only manages the work profile where the corporate data resides. The user has ownership of the device, while the organization does not, so IT should only be able to remove the corporate data if necessary.