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-from-Google-s-Android-Zero-touch-before-sending-to-Repair-depot

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. 

Here the complete opposite to what @mattdermody answered! 

In fully agree with the points highlighted as to why you dont want to use zte for decided such as kiosk or barcode scanners. But as someone working with smartphones and tablets with customers in a daily basis, in implement zte as much as possible. Just a handful of customers are not a good fit when it comes to smartphones and tablets and zero touch enrollment. 

Zte does not only offer ease of enrollment for it, it also offers some peace of mind for security. Resetting a device can be a risk when zte is not implemented. When a stolen device is wiped for example, the thief is able to start using the phone without consequences. Same for an employee that leaves the company on bad terms and decides to take home that expensive smartphone. 

It also saves a lot of time for most customers. And as a reseller we are able to perform uploads, making it even easier for customers. Order a phone, we upload the device and assign a profile and the device can be shipped directly to the end users location. 

I love it, especially with the upcoming improvements!!

Thank you for sharing your experiences @mattdermody and @Michel - they are very different but both well presented. 

It goes to show that multiple deployment options fit very different needs; handling a fleet of rugged devices will be very different than handling a fleet of mobile phones.

I like that you considered your experience but also the experience of the managers/end users on the field, which is something essential when choosing a deployment method! 

@mattdermody  you were mentioning QR enrollment - how has been your experience with this method? 

@Michel have you used the QR enrollment yourself? 

So, back from my vacation will put on my 2 cents here as well:

First of all, we use ZTE for all our devices used in stores (fully managed only) for several reasons like, easy wipe and re-enroll without guide or other things needed and so on.

Also making them useless if someone steals the device and trying to enroll it (it will get stuck at some point by sure ;) making it useless except you use it 100% offline which is also something which would make it 99% useless).

But i also agree to points mentioned here but in my opinion could be solveable somehow:

1. Add options in the config to skip screens getting closer to ZT for cutomers as well
   • For all known "default" Android screens, seperate options
   • For all "unknown" OEM developer screens, one option to skip those
   • Requirement: The relevant screens are somehow "tagged" by the system so it knows what to skip
2. (Please) add the possibility to flag devices as "lost" in ZTE to get them moved to a seperate menu (so you could revert back, if needed) and when enrolled always only show the support information and the only option to factory reset (and if nothing was changed end up there again). Or something similar.
   • Also would like to keep devices here even we maybe cleaned up those models because of a model renewal so those devices stay useless.
3. Improve the functions more into a direction like Knox already have (possibility to add tags, see device model etc. directly in the table without the need of export,...).

I don't see problems related to WLAN devices as all modern devices can just scan a Wifi QR to establish such a connection fast and easy BUT StageNow is better on it to crypt this data instead of having it in clear text as Android Wifi QR codes do yet, this needs to be improved on my opinion (same for if you share the Wifi settings via QR, it's shown in clear text under the QR, WHY? Security wise a mess...). So, stopping here on that off topic a bit.