So why would I be writing about this? I’ve recently come across a customer who needs to change their Google EMM registration as they’ve lost the ability to sign into their Google account.
First things first….
I would never suggest an organisation change their Android EMM registration account as you’re basically binding your Workspace ONE UEM environment to a new Google Organisation. This will mean that all devices will need to be re-enrolled!!!!
I’ve done some testing but it’s worth noting a couple of things before I run over this – The device I’m testing is Work Managed Device, not Work Profile. When Workspace ONE UEM is bound to Android Enterprise, it creates a completely unique ‘Managed Account’ on every Android device that is used to download apps and essentially use Google play services. This is hugely beneficial because the user doesn’t need to have a gmail account to download and install apps BUT this is also important because when a change happens to the Android Enterprise Organisation, the managed account on the device will no longer be able to communicate with Workspace ONE as it effectively is looking for a different Google organisation.
That being said, I’ve tested this within my own lab environment and recorded the outcomes for anyone considering this. When the Android EMM organisation is changed:
- Profiles can still be installed on the device as they’re being installed directly from Workspace ONE
- Communication is maintained between the device and Workspace ONE UEM
- Unable to leverage any Play store services
- No new apps added to Workspace ONE will be visible on the device managed play store
- Previously added applications in Workspace ONE will no longer be deployable from the console
Here’s a video of my testing (apologies, it’s a bit rushed due to time scales!):
To my knowledge, there is no way of changing the Google EMM account without re-enrolling the entire fleet of devices. This is due to the managed account dependencies and play store integration that’s essentially being severed as soon as you change the EMM settings within Workspace ONE.
This is 100% something that should be completely avoided!!!
Sales Engineer specialising in Unified Endpoint Management (UEM) and Identity Management.
Technical Expertise:
o Okta – Identity Management – Providing single sign on services to applications
o VMware Workspace ONE – Configuring and managing AirWatch components across all device types.
o Digital Transformation – Helping organisations implement and deploy a modern strategy for UEM
o Networking – VPN, DNS, DHCP
o Device Management – macOS, iOS, Android, Windows and Rugged Devices
o Cloud Solutions – Azure, Office 365, Identity Providers, VMware AirWatch
o Server – Windows Server, Active Directory, Exchange
DC
June 30, 2020100% avoid, I have had to run through this in the past, it’s not one the customer is in a hurry to repeat!
Charlie Hodge
July 1, 2020It’s a headache waiting to happen, that’s for sure!
Dhanushka
June 30, 2020“I’ve done some testing but it’s worth noting a couple of things before I run over this – The device I’m testing is Work Managed Device, not Work Profile. ”
Does this means these issues are only for Work managed not work profile enrolments ? I suspect this change is going to apply all types of enrolments but thought of checking in case.
-Dhanushka
Charlie Hodge
July 1, 2020Hi Dhanushka,
This would effect all types of enrollments, Work Managed devices and Work Profile devices. Try to avoid!
Charlie.
techiecheng
July 1, 2020We have an unique use case that may warrant this exercise. From the beginning, we chose managed Google account for Android EMM. We just learned that we need to deploy G Suite which requires Android EMM be changed to leverage G Suite as well. In this particular case, we already know users will need to unenroll and reenroll to take advantage of the new offering. However, we do not want to deploy and have to manage another Workspace ONE UEM/AirWatch tenant. So we ended up with creating another top customer OG within the same tenant for this project. While it does allow us to set G Suite for Android EMM in the new top customer OG, we are not sure if we can connect this new OG to the same VIDM tenant. If anyone has any suggestion please do share!
Charlie Hodge
July 1, 2020Hi Techiecheng!
That’s a really good point and use case that I had never considered. Creating a child OG with ‘override’ enabled and editing these settings sounds like it would be the best way of re-configuring this so you’re definitely on the right tack! Within Workspace ONE UEM you can only add one instance of Workspace ONE Access (VIDM) at the customer level (top OG) so you should be able to leverage everything you’ve already got configured from that stand point.
Hope that makes sense!
Charlie.
techiecheng
July 6, 2020Thanks, Charlie. Maybe it’s different for on-premises customers. We as a SaaS customer do not see any ‘override’ option for the Android EMM registration under top customer OG #1. So the only way I could think of is by having VMware ops team create top customer OG #2. The remaining challenge is that VIDM integration with UEM was already configured under top customer OG #1. So I’m uncertain how to proceed with the same integration under top customer OG #2 without breaking the existing configuration for top customer OG #1.
Angel
February 25, 2021Hey Charlie, we are limiting our licenses to GSuite but still would like to allow the users without a corporate GSuite account to enroll their BYOD. What would be the best approach for this?
Daivd
November 17, 2021I am working on a new install of WS1. I have had to recreate the DB recently. Prior to this I had registered with Google Android EMM and was using it successfully. Now that the database has been recreated and I am reconfiguring the settings, when I go to Google Emm to register, I sign in with the previous account, but get told that I am already registered?
how do you tell WS1 to use this account? Last time I had a similar issue I ended up registering under a new account.