For the last 7 months, MobileIron has been the only UEM vendor to support the newest of all Android Enterprise deployment scenarios: work profiles on fully managed devices. Also known to some as fully managed work profile, managed device with work profile, corporate owned managed profile (COMP), work-managed work profile and honestly probably more, it is essentially COPE (Corporate Owned, Personally Enabled), offering personal use on an otherwise fully managed device.
VMware have had an awful lot of time to refine their offering, and release it in tandem with the replacement of their iconic AirWatch Agent in favour of the new Workspace ONE Intelligent Hub, seemingly completing full VMware-ification of the AirWatch platform.
Was it worth the wait?
For testing I created a new organisation group and headed to Groups & Settings > All Settings > Devices & Users > Android > Android EMM Registration > Enrollment Settings:
Overriding the settings, I then toggled Fully Managed Device Enrollments over to Corporate Owned Personally Enabled.
Job done! Really, that’s it. This is naturally an organisation group-level change and so for environments with fully managed devices in use already, it makes sense to separate these into different organisation groups, something not necessarily required when mixing the other deployment scenarios.
As COPE makes use of both the fully managed device and work profile restrictions, attention was next turned to the Restrictions profile.
Something I dislike about MobileIron’s Core implementation of COPE is just how cluttered the lockdown policy has become with all of the new options. By comparison, VMware have clearly put a lot of thought into how best to display work-managed and work profile restrictions generally, and it has really paid off in terms of being clear and easy to understand:
An earlier version of this UI showed non-configurable options as greyed out which I personally preferred, but this still looks great
What’s abundantly clear whilst scrolling through is just how granularly the device can be locked down. The restrictions shown above are applicable to both work-managed and COPE devices, meaning the parent (personal) profile on the device can be just as restricted as an equivalent fully managed device, if the admin so desired.
As an administrator I much prefer this; while I appreciate what MobileIron are doing by artificially limiting the restrictions available on the parent profile of the device, I’d personally rather make my own decisions on how much personal use is permitted on what is still a fully managed device.
With the new Restrictions profile distributed, I enrolled a device.
I provisioned an Android One device with a QR Code generated by heading to Devices > Staging & Provisioning > Staging > Configure Enrollment > Android > QR. The wizard is a nice touch, if you’re able to remember where to find it:
Enrolment, generally, is notably smoother with fewer taps required than I’m used to when enrolling a COPE device, this is primarily due to VMware opting to take Google’s suggestion of removing the work profile user interaction during setup, and for good reason.
On a work profile device intended for BYOD or similar, it entirely makes sense for the user to be prompted with the work profile setup wizard; it’s a device with no other management and thus in creating the work profile users are then guided through the various steps, T&Cs and so on.
With a fully managed device however, the user has already granted permission during provisioning for the device to be managed, and due to this, the work profile setup prompts can optionally be skipped.
This is best demonstrated with a video:
As can be seen, after authentication Workspace ONE UEM mostly handles everything automatically, give or take a few taps for privacy, whilst MobileIron runs through the whole work profile setup flow.
It’s a nice feature that once more shows VMware have put some thought into the user experience during enrolment.
Following enrolment, the experience is pretty much as expected with applications automatically downloading into the work profile.
The obvious differences lie primarily in the restrictions imposed on the parent profile, given so much more can be locked down in Workspace ONE UEM.
There is one thing that bothers me though.
When opening **non-**managed Google Play in the parent profile, I’m greeted with the managed Google Play Store.
This isn’t something you’d expect to see in the parent profile as it’s intended for personal use, however this actually happens because Workspace ONE UEM, for reasons yet to be discovered, adds a managed Google Play account to both the work profile and the parent profile.
Heading into Settings > Accounts on the device demonstrates this:
Managed Google Play accounts are primarily used for app management, so you can draw your own conclusions on why that may be there, but there’s nothing I’m seemingly able to do with it within the parent profile right now.
In any case, as an end-user I’m used to being prompted to sign in when opening the Google Play store on a personal parent profile, so to be greeted with a managed Google Play UI offers poor UX and will be confusing for many, no doubt resulting in questions back to IT as to why users can’t get to the “proper” Play Store (or users will eventually figure out it’s possible to switch accounts within Play after adding their own account).
Still, this change may be worth it in the end so I’ll reserve judgement for now and see what comes next.
One other recent feature I was made aware of is the introduction of app collections in managed Google Play.
Administrators now have the capability within the Google Play iFrame not only to approve applications, but to customise the layout of the applications also!
This feature is backwards compatible to any version of Workspace ONE UEM or AirWatch that supports the iFrame, which means most organisations can make use of this new feature already:
The usability of this is greatly improved over manually categorising every app imported, making it much faster and easier to approve, organise and deploy applications whenever required.
I’m extremely pleased to see wider adoption of COPE for Android Enterprise, even if it has taken well over a year since its introduction with Android 8.0 Oreo.
Being the best of both worlds between management and freedom for many organisations, this should be welcomed with open arms and I look forward to seeing this further aid in the increased adoption of Android Enterprise going into 2019!
VMware have done a great job with this implementation and have even added a little suspense over what’s to come with the addition of a managed Google Play account within the parent profile, so I’ll be keeping my tabs on what they’re up to over there!
1810 and the new agent are currently rolling out now, if your organisation is waiting on COPE it should only be a matter of weeks, however get in touch with your VMware representatives for more information if required.
The question now is, which will be the next UEM to support COPE?
Have you been waiting for COPE? Are you happy with how VMware have implemented it? What, if anything, do you feel could be improved? Let me know in the comments, Twitter or LinkedIn!