What is Android Enterprise?
For information regarding Android Enterprise, including what it is, the deployment scenarios stated below and how it can benefit organisations, have a read of What is Android Enterprise and why is it used?
Android Enterprise vs device administrator (legacy) enrolment
Unsure of the differences between Android Enterprise and device administrator enrolment? Check out Android Enterprise vs device administrator (legacy) enrolment.
A majority of organisations looking at Android Enterprise today will very likely already have a mature Android management process in place centred around the legacy device administrator enrolment model. With this model being deprecated partially with Android P and fully in Android Q, now is the time to start thinking about planning a migration.
It is important, therefore, to understand the implications of a migration from a device administrator deployment to one (or more) of the deployment scenarios available with Android Enterprise; depending on the deployment scenario chosen it could be very disruptive, but steps can be taken to reduce this.
The key to undertaking any migration is communication, planning and as much testing as is necessary to understand every possible challenge an organisation may face when making a fundamental change to how devices are managed. With those in mind, the following must also be taken into consideration for Android Enterprise.
Organisations leveraging G Suite may find it easier to integrate directly with their EMM platform in order to make use of G Suite accounts and authentication when enrolling corporate Android devices. G Suite enrolment is like that of the DPC identifier; when putting in the account of a G Suite address, the device will become a work-managed device, controlled either by the native G Suite EMM or a connected 3rd party. The process for connecting a 3rd party EMM can be somewhat cumbersome, however the benefits of far greater management capabilities outweigh the work required.
Managed Google Play accounts are better suited for all other circumstances, as those without a G Suite tenant would otherwise have to go through domain verification and other hoops in order to do what managed Google Play accounts can with only a generic Google account required and a few minutes spare. The process of linking an EMM platform is quick and painless, and offers the ability to provision, manage and deploy applications all without requiring a Google account is added manually to each device.
Unless G Suite is in use and account synchronisation is required, managed Google Play accounts are without doubt the better option.
Android Enterprise became mandatory with 6.0, Marshmallow. Although 5.0 should support Android Enterprise (work profile, at least), there’s a good chance this will not be the case and for that reason is arguably not worth including in migration plans due to foregoing features and the additional testing required to validate compatibility. Any devices running a version of Android under 5.0 are not natively supported and should not be considered for migration.
With a large enough split between supported and unsupported devices, a hybrid legacy/AE environment may be the best option whilst the unsupported devices are phased out; many EMM platforms can support a hybrid environment, though this will naturally result in a mix of enrolment guides, additional overhead for support teams and a more complex EMM deployment, though only temporarily. In future, device administrator enrolment will not be possible at all, meaning if legacy enrolment is still being utilised by 2019 a hybrid environment will be a requirement, rather than an option.
Deploying a hybrid environment incorrectly could result in all Android Enterprise-capable devices being targeted by the relevant profiles/configurations and lead to a mass work profile roll-out. Though this can be postponed by the user, it is likely to be highly disruptive.
Always ensure in a hybrid scenario Android Enterprise is configured below the top-level in a hierarchical EMM, or to a dedicated group/label for others where it cannot impact more devices than explicitly required until such time legacy devices are retired from the platform. Active Directory groups may also offer an excellent, simple way of managing this.
Like iOS and legacy Android (Samsung in particular with Knox), with each major Android version, additional functionality is often added. This is equally no different in an enterprise context. Depending on the functionality required for various areas of an organisation, it may make sense to refresh some devices sooner rather than later. The full list of supported functionality per OS version can be found here, however as a very brief example:
- Device passcode management: 5.0
- Application configuration: 5.0
- Factory reset protection management: 5.1
- App runtime permission management: 6.0
- System update control: 6.0
- Cross-profile data management: 6.0
- Work profile passcode: 7.0
- Always-on VPN: 7.0
- Reboot device: 7.0
It’s therefore pertinent to ensure for example where functionality such as a secondary passcode for a secure container is required, the devices being migrated run at least Android 7.0, and so on.
Android Enterprise launched with NFC for work-managed provisioning. With each major version launched since, a new provisioning method has launched also (though past 8.0, this is not likely to continue). The following shows which provisioning methods can be used on each major version of Android:
- Android 8.0 Oreo: G Suite, NFC, DPC identifier, QR code, zero-touch
- Android 7.0 Nougat: G Suite, NFC, DPC identifier, QR code
- Android 6.0 Marshmallow: G Suite, NFC, DPC identifier
- Android 5.0 Lollipop: NFC
QR code and zero-touch provisioning methods are considered optional and may not be supported by all OEMs. Huawei, for example, has not supported QR code enrolment prior to EMUI 5.2. Furthermore, NFC naturally requires an NFC radio is present on the devices to be migrated; 5.x devices without an NFC radio cannot therefore be supported.
More information about provisioning methods can be found here.
Similar to provisioning methods, deployment scenarios available today are also (though somewhat less) Android version dependent, with the below list intentionally excluding Android 5.x:
- Work profile: 6.0+
- Work-managed: 6.0+
- COSU (KIOSK): 6.0+
- Work profile on fully managed devices (COPE): 8.0+
Work profile on fully managed devices, which may be referred to as a COPE deployment, is currently only available on MobileIron, coming to more EMMs later in 2018. It offers the closest experience to a traditional device administrator deployment.
Just as functionality is added with Android updates, so too will management capabilities be added with EMM platform updates. A concern more for organisations running EMM platforms on-premise than SaaS/cloud, some functionality may not be available until the platform has been updated to a minimum version.
A good example is MobileIron Core, as support for Android Enterprise accounts was introduced with version 188.8.131.52, and has since seen several feature additions with each Core version up to the latest (as of 12/2017) Core 184.108.40.206. AirWatch as another example only introduced COSU support with 9.2, requiring a hybrid deployment for organisations wanting both Android Enterprise and kiosked devices.
Even so, not all EMMs will support all functionality due to time/budget constraints/demand, which is of course the same constraint all OS platforms are limited by. The organisation therefore will need to validate the functionality required is also supported by their EMM.
Simply linking an organisation’s EMM platform with Android Enterprise won’t necessarily do anything (there are of course exceptions to this, and please ensure this is checked before enabling it, see above) until further configurations/profiles/groups/etc have been created and applied.
As well as linking the EMM with Google, applications will need to be (re)imported and configured for the Android Enterprise deployment with managed configurations created where applicable. Additionally, profiles/configurations targeting the universal Android Enterprise APIs will need to be created (as those targeting KNOX, etc will no longer work). Some examples of where managed app configurations replace legacy configurations are:
Email/Exchange: A managed Gmail (or other email app) config will replace a legacy mail/Exchange configuration.
Remote access to repositories: EMM vendors publish app config-compatible public versions of traditionally in-house MCM apps
Internet blacklists: Managed Google Chrome supports traffic rules and many other options to limit non-business/risky browsing
Additionally, segregation between the legacy device configurations/profiles and the Android Enterprise-enabled devices should be undertaken. I feel this is rather important; often I see legacy policies/configs applied to an entire estate, perhaps as an “all devices” or “Android” assignment which will obviously also target Android Enterprise devices. While these configurations and profiles for the most part won’t apply, it will make it more difficult to troubleshoot issues with EMM logs full of partially applied or entirely failed attempts to push legacy configs.
A general piece of advice is not to assign apps/configs/policies/etc to such far-reaching groups/labels or at the top of a hierarchical structure and instead focus them more towards active directory/system groups that can be tweaked, changed or have devices easily excluded from them with little effort. This is not limited to Android Enterprise prep, but can also apply to VPP, DEP, differing authentication methods and more.
What is a work profile?
An overview of work profile can be found here.
The simplest, most straightforward migration route from device administrator to Android Enterprise is work profile. This is because it can be achieved with an OTA configuration change which will:
- Initiate the creation of a work profile on the device
- Remove the device administrator
- Disable the agent in the parent profile
- Resume management in the work profile
In doing so, the existing configurations pushed to the device still applied will be removed or become ineffective (with some exceptions) and all further configurations will be sent to the work profile and not the parent profile (device).
This isn’t, however, a comparable deployment. By switching from device administrator to work profile the organisation is relinquishing almost all control over the parent profile, or the rest of the device, and only controlling what happens essentially within a “container”. This therefore is likely not a popular migration, however it is the only path that doesn’t involve a factory reset and provisioning from a new state.
What is a work-managed device?
An overview of work-managed can be found here.
The migration from device administrator to a work-managed deployment scenario is a disruptive one as it requires a device is factory reset.
Whether this can be done by end-users or requires a visit back to base entirely depends on the technical abilities of the workforce. Typically it’s a bit of a mix and therefore some will be happy to follow an informative provisioning guide while others will need to book an appointment with IT. The work-effort can only really therefore be estimated by the organisation, not forgetting to add in time to back up any unsaved data as this will be lost during the transition; again some users may be able to do this, others may not.
If new devices are replacing old (arguably the easiest way of transitioning from device admin to Android Enterprise), these can also be pre-enrolled potentially to a staging user and shipped to end-users, however if provisioning only, after a period of time without enrolling the device will automatically factory reset (a protective feature that ensures a device can’t be used unless it’s managed).
Depending on the deployment scenario the organisation opts for, the experience can feel far more locked down than a device administrator enrolment as work-managed is, by default, designed without personal use in mind (that is to say, managed Google Play limiting app access, no capabilities for sharing data in the same way, and so on).
These limitations can be mitigated by permitting functionality and the addition of personal Google accounts as required but this is not necessarily recommended unless it’s a work profile on a fully managed device.
Speaking of work profiles on fully managed devices, this is the closest functionally to a device administrator deployment and will therefore feel the most familiar both to end-users and administrators since the organisation can manage the device (parent profile) and the work profile independently, but opt for a more lenient approach than that of a standard work-managed deployment.
For COSU deployments, EMMs are increasingly providing their own kiosk solutions in order to offer a seamless experience when moving from device administrator to Android Enterprise, however the COSU configurations/profiles will need to be recreated to target AE devices. Where no EMM-branded kiosk exists, Android Enterprise ships with its own.
As well as limiting application installation to those approved for use and available in managed Google Play, devices deployed as work-managed will by default have many of the included system applications removed, but these may be re-enabled either fully (as a DPC extra) or partially via an EMM profile/configuration. During testing it will also be beneficial to understand the implications of removing system applications in terms of losing the ability to view some email attachments, take photos, and more. Should this cause issues, the applications in question should be re-enabled.
If it isn’t clear already, a migration from a legacy deployment to that of Android Enterprise for anything other than work profile is not to be taken lightly, even a work profile migration requires thought and attention (and a lot of testing) to ensure it can be undertaken with the least amount of disruption.
Most importantly however, there’s no need to rush into this. For organisations with deployments comprising majoritively of Android 5.x or lower it makes far more sense to hold off until the next hardware refresh (which, on Android versions that old, should be considered sooner rather than later). When the time is right and the new hardware is ready, a switch to Android Enterprise will then be vastly simpler to undertake as well as undoubtedly benefiting from such options as zero-touch enrolment.
Either way, a migration should be on the agenda for organisations; while device administrator enrolments may still hold some benefits currently (some functionality being yet to find its way into the Android Enterprise solution set), Google is clearly investing their time and effort into Android Enterprise as the de facto long-term solution for Android management, and migrating sooner rather than later will ensure organisations today benefit from that investment.