Forum Discussion
Share your deployment experiences with Android zero-touch enrollment
I deal exclusively with corporate owned line of business devices and as a result I generally try to avoid ZTE as often as possible. I have many reasons for this.
The “ZTE” name is meant to imply that the IT staff has Zero Touches to perform on the device because it is self guided and led by the end user. There is actually a ton of tapping and touching to perform. This idea was built for COPE style devices so that central IT staff could drop ship WWAN, scannerless devices directly to knowledge workers who then go through the enrollment process manually themselves. ZTE on ruggedized AEDO devices just pushes the manual configuration process to end users at a site and opens many opportunities for mis-taps and troubleshooting to be required by central staff.
ZTE is designed for devices that DONT have an integrated scanner and DO have a constantly-connected network (LTE, WWAN, cell phones). A device with a scanner should leverage that scanner for quick enrollment without the overhead of an external portal. A device without a WWAN connection will still need WiFi connected before it can access the ZTE portal.
ZTE:
Zebra StageNow:
Since WLAN devices are not connected, distributing ZTE devices to end-users or knowledge workers means you must provide them with the wireless security information since they would have to manually key it in themselves. This exposes a security vulnerability by having your wireless credentials exposed and shared to sites.
Devices in warehouses and retail stores are damaged and sent in for repair frequently under repair contracts. In a warehouse with 500+ devices 5 or so of them might be shipped out every single day to a repair facility. These devices get factory reset and tested at the repair facility before shipping them out. These facilities require that the devices are deregistered from ZTE before sending them in so they can execute the repair process and their tests. This therefore introduces a huge bottleneck to repair processes because the warehouse supervisor shipping out repair devices is not generally going to be a ZTE admin and therefore a step has to be introduced in the process that slows everything down.
https://supportcommunity.zebra.com/s/article/Deregister-a-Device-from-Android-Zero-Touch-Enrollment
I also really do not like the idea of being dependent on a separate, Google service like a ZTE console and server just to get devices configured. There have been many documented cases of ZTE having issues which could derail device deployments for many days. I do not want to put myself into a position where I have to tell a CIO they can't go live in their warehouse today because Google's having ZTE issues. It's a dependency I don't want for mission critical device deployments.
https://www.androidenterprise.community/t5/general-discussions/zero-touch-registration-is-not-available/td-p/1256/page/2
https://www.androidenterprise.community/t5/service-announcements/fix-available-toserror-responses-accessing-zero-touch-customer/ta-p/4041
Cross pollination is also a hilarious problem that only this sort of system would introduce.
Device enrolled in different company | Android Enterprise and ChromeOS Customer Communities - 2303
It's easier to just avoid ZTE because the benefits do not outweigh these pain points. For mission critical Android Enterprise device deployments it is better to leverage the OEM specific staging tools or something more predictable and reliable like the QR enrollment method.
