This week is all about the device management jungle of Android Enterprise. I should have discussed this subject a long time ago, but better late than never. Especially when I’m still seeing many question marks when discussing Android Enterprise. With the release of Android 10.0 coming to the different existing Android devices now, the purpose of this post is to create an overview of the different enterprise deployment scenarios of Android Enterprise, including the Microsoft Intune specific additions, and the different related enrollment methods. Everything focussed on providing a good starting point for managing Android devices. The main trigger is the nearing end of Android device administrator with the release of Android 10.0. Earlier I provided the steps for simplifying the migration of Android device administrator to Android Enterprise work profile management with Microsoft Intune, but that was a specific scenario for migrating away of Android device administrator. That doesn’t answer the question if Android Enterprise work profile management is the best deployment solution for your organization.
With this post I hope to provide a better overview of the different deployment scenarios, the requirements and the enrollment methods. All to make a good start with Android Enterprise. Before I’ll dive into Android Enterprise, I’ll start with a little bit of history about Android device administrator. After going through the Android Enterprise deployment scenarios and enrollment methods, I’ll end with a short note about the (crazy) future. I won’t compare or discuss the different configuration options for the different deployment scenarios, as I think that a deployment scenario should be chosen based on the use case first and not directly based on the available configuration options.
A little bit of history
Let’s start with a little trip down memory lane. A long time ago, with Android 2.2, Google introduced the Device Administration API. That API provided device administration features at a device level and allowed organizations to create security-aware apps with elevated administrative permissions on the device. It would enable organizations to perform some basic actions on the device to manage basic components, like email configurations (including remote wipe) and password policies. However, it also introduced many big challenges. One of those challenges was the limited number of configuration options, without a third-party solution like Samsung Knox, and another one of those challenges was the inconsistent level of control across different manufacturers. The more Android device administrator was used, the bigger the scream became for something new.
And something new came. Starting with Android 5.0 and later, Google started with the introduction of Android Enterprise by introducing the managed device (device owner) and work profile (profile owner) modes to provide enhanced privacy, security, and management capabilities. These modes support the different Android Enterprise deployment scenarios (more about those scenarios later) and can be managed by using the Android Management API. That API can be used to configure different enhanced policy settings for the managed devices and the companion app (Android Device Policy) automatically enforces those policy settings on the device. Microsoft Intune has chosen to rely on the API for managing most of the deployment scenarios.
Now only turning off the old management method is left. Starting with Android 9.0, Google has started with decreasing device administrator support in new Android releases, by starting with deprecating specific settings. These settings are mainly related to the camera and password configurations, and these settings are completely removed starting with Android 10.0. That will prevent organizations from being able to adequately manage Android devices by using Android device administrator. A big trigger to move away from Android device administrator. The advise – when using only Microsoft Intune – is to move to Android Enterprise modes and deployment scenarios with the introduction of Android 10.0. Even better, don’t wait until the introduction of Android 10.0 (but that advise might be a bit late now).
Android Enterprise deployment scenarios
The biggest challenge of the Android Enterprise device management jungle is the number of deployment scenarios. When looking specifically at the combination with Microsoft Intune, there is even an additional deployment scenario on top of the standard Android Enterprise deployment scenarios. Below in Figure 1 is an overview of the currently available Android Enterprise deployment scenarios with Microsoft Intune (picture is taken from the slide deck of session BRK3082 at Microsoft Ignite 2019).
Now let’s have a closer look at these different deployment scenarios and the supportability of Microsoft Intune. I’ll do that by zooming in on the different deployment scenarios as shown in Figure 1.
Android APP managed – Android app protection policies (APP) managed app is the least intrusive method for allowing access to company data on personal devices and still making sure that the data remains safe. Also, this method is not Android Enterprise specific. In this scenario, the app is managed with protection policies that will make sure that the company data remains within the app and these protection policies are only applied once the user signs in with a work account. Also, the protection policies are only applied to the work account and the user is still able to use the same app with a personal account. If needed, the IT administrator can remove company data from within the managed app.
AE Work Profile – Android Enterprise work profile is supported with Android 5.0 and later in Microsoft Intune and is focused on providing access to company data on personal devices by using a profile owner mode. In this scenario, the user enrolls the device and after enrollment a separate work profile is created on the device. This separate profile creates the separation between company data and personal data and can be easily identified by the user. The apps that are part of the work profile are marked with a briefcase icon and the company data is protected and contained within the work profile. If needed, the IT administrator can remove the work profile from the device.
AE Dedicated – Android Enterprise dedicated devices – previously known as corporate-owned, single-use (COSU) devices – are supported with Android 6.0 and later in Microsoft Intune and is focused on providing single purpose company-owned devices by using a device owner mode. This is often used for kiosk-style devices (example: devices used for inventory management in a supermarket). In this scenario, these devices are enrolled and locked down to a limited set of apps and web links, all related to the single purpose of the device. These devices are not associated with any specific user and are also not intended for user specific applications (example: email app). If needed, the IT administrator can remove any (company) data of the device.
AE Fully managed – Android Enterprise fully managed devices – previously known as corporate-owned, business-only devices (COBO) devices – are supported with Android 6.0 and later in Microsoft Intune and is focussed on providing company-owned devices, used by a single user exclusively for work, by using a device owner mode. In this scenario, these devices are enrolled and fully managed by the IT organization. To give the user a personal touch, the IT administrator can allow the user to add a personal account for the installation of apps from the Google Play store. However, the device will remain fully managed and there will be no differentiation between company data and personal data. If needed, the IT administrator can remove all (company) data of the device.
AE Fully managed with work profile – Android Enterprise fully managed devices with work profile – previously known as corporate-owned, personally-enabled (COPE) devices – are not yet available with Microsoft Intune, but are eventually focussed on providing company-owned devices used for work and personal purposes, by using a combination of device owner mode and profile owner mode. In this scenario, the IT organization still manages the entire device, but can differentiate between the strength of the configuration depending on the type of profile (example: a stronger configuration set to the work profile and a lightweight configuration set to the personal profile). That should provide the user with a personal space on the device and that should provide the IT administrator with enough capabilities to protect the company data.
For the management of the company-owned devices, Microsoft Intune relies on the Android Management API and Android Device Policy. That enables Microsoft to be able to quickly introduce new features, when introduced in the API. However, that also creates a dependency on Google to introduce new features via the API. A negative example of that dependency is the time it took before the Android Enterprise fully managed devices with work profile deployment scenario became available via the API. At this moment the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune.
Android Enterprise enrollment methods
Once familiar with the Android Enterprise deployment scenarios, it’s good to get familiar with the Android Enterprise enrollment methods. That will enable the IT administrator to get an Android device in the correct mode (device owner, or profile owner) and the correct deployment scenario. The table below provides and overview of the available enrollment methods for the different deployment scenarios. It also provides some details about a few important properties of the deployment scenarios (based on the information about the deployment scenarios). Those properties are: is a reset required to get started with a deployment scenario and is a user affinity applicable with a deployment scenario.
As the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune, the information regarding that deployment scenario is an educated guess, based on the other deployment scenarios. That’s why the information is in grey, as it’s still work in progress. The only thing that I’m sure of is that it would require a new enrollment. There will be no migration path from an Android Enterprise fully managed device to an Android Enterprise fully managed device with work profile. That will require a new enrollment. Keep that in mind with determining an eventual deployment and management strategy.
|Deployment scenario||Enrollment methods||Reset required||User affinity|
|Android app protection policies managed app||Managed app||No||Not applicable|
|Android Enterprise work profile device||Company Portal app||No||Yes|
|Android Enterprise dedicated device||Near Field Communication, Token entry, QR code scanning, or Zero touch||Yes||No|
|Android Enterprise fully managed device||Near Field Communication, Token entry, QR code scanning, or Zero touch||Yes||Yes|
|Android Enterprise fully managed device with work profile||Near Field Communication, Token entry, QR code scanning, or Zero touch||Yes||Yes|
Now let’s have a closer look at the different enrollment methods and the supportability within Microsoft Intune. I’ll do that by zooming in on the different enrollment methods as mentioned in the table above.
Managed app – Managed app enrollment is not specific to Android Enterprise and is supported with any platform version that is supported by the specific managed app. With this enrollment method, the user downloads and installs an app that is protected with app protection policies – when using a work account – and adds a work account to that app. After signing in it triggers the app protection policies for the work account. Also, keep in mind that the user would need to have the Company Portal app installed as a broker app.
Company Portal app – Company Portal app enrollment is supported with Android 5.0 and later in Microsoft Intune for Android Enterprise deployment scenarios. With this enrollment method, the user downloads and installs the Company Portal app and signs in with a work account. After signing in the user triggers the enrollment process in the Company Portal app.
Near Field Communication – Near Field Communication (NFC) enrollment is supported with Android 6.0 and later in Microsoft Intune and can make the enrollment of a device as simple as tapping the device on a specially formatted NFC tag. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can simply tap the device on the NFC tag. That tap will automatically start the enrollment process.
Token entry – Token entry enrollment is supported with Android 6.0 and later In Microsoft Intune and enables the enrollment of a device by specifying a specific (enrollment) token. With this enrollment method, once the device is reset, or just out-of-the-box, the administrator, or user, walks through the standard setup wizard and once arrived at the Google sign-in screen provides the afw#setup code to trigger the Android Device Policy. That will enable the token entry to actually start the enrollment process.
QR code scanning – QR code scanning enrollment is supported with Android 7.0 and later in Microsoft Intune and enables the enrollment of a device by simply scanning a QR code. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can multi-tap the screen to enable scanning of a QR code (on Android 7 and 8 that will first prompt for the installation of a QR code reader app). That QR code will automatically start the enrollment process.
Zero touch – Zero touch enrollment is supported with Android 8.0 and later In Microsoft Intune – only with participating manufacturers – and enables the enrollment of a device automatically. Similar to Apple Business Manager and Windows Autopilot. With this enrollment method, on first boot of the device, it will automatically check to see if an enterprise configuration is assigned. If so, the device initiates the provisioning method and downloads Android Device Policy. That download and installation will automatically start the enrollment process.
Note: Besides these standard Android Enterprise enrollment methods, there are also third-party additions (like Samsung Knox enrollment) that can benefit the enrollment process.
What the future brings
Let’s end with a look at the future and some advise. By now it should be obvious that platforms change. However, when looking at the first early signs of Android 11.0 – and specifically at what Android 11.0 brings to the Android Enterprise fully managed devices with work profile deployment scenario – organizations might wonder if change is always for the better. Just when the deployment scenarios of Android Enterprise get more and more traction, new changes are coming. Google recently announced that it will no longer support a work profile on fully managed devices with Android 11.0. Instead enhancements are made to the work profile, to provide a new enhanced work profile deployment scenario. And Android 11.0 will be a hard cut. Existing work profiles on fully managed devices will need to be migrated (to either a fully managed devices or to this new enhanced work profile) when upgrading to Android 11.0. The main driver for Google is the privacy of the user. Jayson Bayton wrote a great article around this subject. Also, when interested in anything around Android and Android Enterprise, I strongly advise to read more of his articles. It’s a great resource!
This change with Android 11.0 makes the future around the Android Enterprise fully managed devices with work profile deployment scenario, especially from a Microsoft Intune perspective, even more challenging. Even before that deployment scenario is available is available within Microsoft Intune. However, this shouldn’t be a reason for waiting even longer with the migration to Android Enterprise. Make sure to be familiar with the Android management requirements within your organization and built the solution and roadmap around those requirements. Often the lifecycle of the device is a good moment to look at a new method for managing the devices. Especially when looking at the supportability of new Android releases on existing devices. Don’t wait until the last moment and make a plan.
I would like to end by mentioning one last time that my advise is not to manage Android 10.0 with Android device administrator and only Microsoft Intune, as those devices will no longer be able to receive password requirements. To add-on to that, and to make my advise even stronger, make sure to be familiar with the upcoming restrictions to the Company Portal app on Android 10.0 devices managed via Android device administrator (see: Decreasing support for Android device administrator). Determine your own migration while you still can!
For more information regarding Android device administrator and Android Enterprise, refer to the following articles:
- Device administration overview – https://developer.android.com/guide/topics/admin/device-admin
- Device admin deprecation – https://developers.google.com/android/work/device-admin-deprecation
- Android Enterprise terminology – https://developers.google.com/android/work/terminology
- Android enrollment methods – https://docs.microsoft.com/en-us/mem/intune/enrollment/device-enrollment#android-enrollment-methods
- Android device management with Microsoft Intune – https://myignite.techcommunity.microsoft.com/sessions/BRK3082?source=TechCommunity
- Enhancing work profile privacy on company-owned devices – https://blog.google/products/android-enterprise/work-profile-privacy/