Earlier this month, VMware announced version 9.4 of their popular UEM solution and with it, both a stronger focus on Android enterprise and a rebranding exercise to bring the platform closer in line with VMware’s range of other products:
This update therefore bids farewell to the AirWatch name, brand and colour scheme of old, other than the odd references here and there, and completes the brand unification that I imagined would be somewhat inevitable following the AirWatch acquisition some years ago:
The rebrand has certainly raised a few eyebrows across the industry, however in reality the name change doesn’t mean a significant amount on its own; rather it’s far more important to understand the recently published licensing changes. The way VMware explained the change to me at the recent Android enterprise Partner Summit, many customers should end up better off as the numerous colours are dropped in favour of fewer WS1 options, I’d encourage organisations to take a look sooner rather than later in any case.
On to Android enterprise, 9.4 introduces a first-look at VMware’s shift to Android enterprise-first with a few new features and requirements:
If you’ve been paying attention to the VMware blog, the previously-announced deprecation of app search functionality for legacy Android enrolments (the Play Store Integration Service) isn’t listed in the changes above, this is because the rather disruptive change is not being implemented until the end of 2018, offering plenty of time for organisations to migrate to Android enterprise ahead of time.
For existing AirWatch customers you may be wondering how you’ll be affected..
Well, at least in so much as preventing legacy Android enrolments. If your organisation has previously deployed Android devices without taking advantage of the newer, more secure, simpler and more flexible way of managing Android devices, that explicit opt-in will have already been completed during the upgrade process without any manual intervention.
This change is only targeting new deployments in order to ensure Android enterprise is very much front-and-centre when getting the tenant set up for Android management. Here’s what that new wizard looks like:
And clicking on configure Android EMM Registration:
If an organisation wants to permit the enrolment of legacy devices, the admin can find the relevant setting in Groups & Settings > All Settings > Devices & Users > Android > Android EMM Registration. On checking the box Deploy Android without registering with Google, WS1UEM will present a warning as follows:
If this option remains disabled, end-users attempting to enrol a non-Android enterprise device will see the following error after authenticating with the WS1UEM server:
Beyond that, there will be more subtle changes, as mentioned above, in the terminology used and the way profiles are created going forward. VMware explain the terminology changes as follows:
Android for Work has been renamed to Android and is the default deployment method for new enrollments. The legacy Android platform will now be referred to as Android (Legacy).
In practice, with devices enrolled via both device administrator and Android enterprise methods, I saw no obvious “face value” indication which is which outside of the organisation group they were enrolled into:
It does become clearer on the profile side however. This is what admins will be greeted with when creating a profile going forward:
Notice the two Android options? Here’s how the profiles will look when configured, note the “(Legacy)” added at the bottom there:
One thing I did expect to see was a bit of logic. The screenshot of profile creation above for example is from within an organisation group in which Android enterprise is not configured, yet I can still try to create “Android” profiles. It fails of course:
But It’d be much better, I think, to hide those profiles that’d essentially do nothing when configured as I’m sure this will lead to support calls regardless. On the other side, within an Android enterprise-configured organisation group, it’s possible to create legacy Android profiles and no warnings are presented. Again, hiding this would both look cleaner and avoid any confusion whatsoever.
A feature I’m rather excited to see is full COSU support. The new update brings with it more granular control over the Launcher (Kiosk) experience:
I’m excited to do some proper work around this, as preventing access to the underlying OS is a frequent request in kiosk deployments. The Single App capability already gives it a leg up over the likes of MobileIron today and an answer to iOS native single app mode, so with more control this should be quite a powerful solution.
I’ve done a little experimentation on a Huawei MediaPad M5 and the experience is OK, though on that device at least I still see everything even if things like swiping down to get to notifications is possible, but prevented about mid-way through sliding the shade down the screen. More testing required. Launcher is making full use of app pinning to make this work, a solution that’ll become far more flexible with Android P later this year!
9.4 will begin rolling out to customers over the coming weeks to shared SaaS and dedicated SaaS customers. On-prem customers, feel free to get in touch with your VMware contact or partner in order to discuss how you can upgrade. Looking for a partner to help you through the upgrade or transition from legacy Android to Android enterprise? Get in touch.
Are you an AirWa.. err, VMware Workspace ONE UEM customer? What do you think of the changes? Will you be making use of the new features? Are you going Android enterprise first in your organisation? Let me know in the comments (login via your preferred social network!), via Twitter @jasonbayton or on Linkedin via /in/jasonbayton.