Fantastic question!!! Looking forward to what dialog this turns up. 

From my perspective you can largely get away with it for now, but down the road you may have issues that could force you to completely factory reset and re-enroll in order for the service accounts to be assigned. It is my understanding that this can only happen at the point of enrollment but I might be wrong about that or that might evolve in the future. 

You will lose out on the ability to use OEMConfig (an extension of AppConfig) which some manufacturers have indicated will be the only way to manage OEM specific settings at some point in the future. Updates of system components like the Chrome and system WebViews will also not happen automatically (might be a good thing TBH) but we have already seen issues where old system WebViews become incompatible with a SSO portal or a new Microsoft update of some kind. 

We are enrolling with MGPA service accounts for the time being as purely a future proofing mechanism in order to prevent re-enrollments in the future. With that said, we aren't really taking advantage of them at all as we try to distribute everything directly as a Profile via SOTI instead of relying on the very unreliable Google Play distribution of applications. 

Thanks Matt. Nice to see you don't sleep.

Yes, OEMConfig has been that outstanding potential issue. Zebra reps tell me they will have another delivery method for OEMConfig settings for these closed networks. But until I see it working it remains a concern.

When working with customers that currently have closed networks and encouraging them to open their network for MGPA. What is the minimum list of ports you provide them to allow communication to Google servers for managed google play to work? The documentation list is extensive. 

Shawn

My understanding is that OEMConfig could technically be administered directly from the EMM to a device bypassing the Play infrastructure but none of the EMMs have done that yet because the Play mechanism is already there and there is also so much strategic alignment happening behind Google to promote AE as the way of the future. Would honestly love an option to administer OEMConfig settings directly to a device rather than having to push that out to Play and then sit around and wait for them to apply it on the devices. It's simply not practical compared to MX so we're sticking with MX XML for as long as possible.  

It's kind of a cat and mouse game with the port access since the actual IP addresses seem to jump all over the place depending on what region you're in and what time of day it is. Only half joking there. We usually say play.google.com/work should suffice and then inspect what traffic is actually on the network during enrollment to see what we should allow through. In most cases it has been 443 but I've also seen 5228. One option you also have is to stage the devices on a public network that has more wide open access so that it can at least register with Google and get provisioned with a service account. You can then transition them to a more locked down production network.