Zebra Android OS Update Options

Zebra Android OS Update Options

What is your preferred MobiControl driven OS / Firmware update method for Zebra Android devices, and why? I am trying to validate the best deployment strategy given the regular release of Lifeguard updates, sometimes in the 30-50MB range, and the occasional release of full size updates in the 200-300MB range. I am considering multiple aspects including, but not limited to, minimizing impact to the network and minimizing impact to the end users. Do you have users self-serve the update? Do you schedule them to all occur at the same time? Do you preload the update files and then execute the installation separately?

 

Delivery Mechanism Options

- File Sync Rule

- Package

- MX Profile that points to an FTP server or other download location.

- Other?

 

Application Mechanism Options

- install_system_update as a post install script in the package

- install_system_update as a standalone script applied on demand

- install_system_update in a script in a package that is applied via a Self-Serve package

- MX profile for applying the OS update applied as a package

- Zebra custom app for applying OS Updates. 

- Other?

6 Answers

Order By:   Standard | Newest | Votes
Marcus | posted this 17 January 2018

Interesting questions.

We have tried different methods for patching Zebra devices. We are currently testing patch deployment using a profile with a post-install script that executes the OS update.

We have set up a "patch window" file sync to ensure that we only run OS updates during night.

The filesync rule downloads a file(if its newer) from our Soti server and we use custom data to fetch the information in the file and use it as profile filter,

At 11.45PM a Powershell script on the server changes the file to contain current weekday and Patch=Enabled.

At 5.30AM the script changes the file to current weekday and Patch=Disabled

File sync schedule is at 11:45PM and 5.30AM. 

We have been testing this for a while and are almost ready to run it in production.

 

  • 1
  • 0
Matt Dermody | posted this 17 January 2018

I like the novelty of this approach, but I might be missing a part of it. Are you using the File Sync rule to distribute the update zip as well as the custom file that the Custom Data rule extracts from or is the update zip distributed as part of the Profile? At first I was wondering why you wouldn't just use the schedule window for Profile application but I guess that would only be a one time window whereas your Powershell script enables this window to reopen every single night. Neat.

  • 0
  • 0
Marcus | posted this 19 January 2018

We are only using file sync for the ini file. The patch is distributed as a part of a profile. And you are right, our script enables a fully automated deplyment schedule.

  • 0
  • 0
Scott | posted this 06 April 2018

Along those lines, does anyone know of a way to limit the attempt of a device to download a package based on IP address or something similar?  Our devices are typically on cell but will be docked into ethernet chargers when not in use.  I'd like to have a filter that prevents download attempt unless on ethernet (or some IP address range)  Anyone had luck with that?

  • 0
  • 0
Matt Dermody | posted this 06 April 2018

What version of MobiControl are you running? You can restrict updates by battery level as of 13.4 and I think some late maintenance builds of 13.3.  Maybe that could provide the end result you're looking for? I haven't experimented with the setting too much yet but I imagine there is some battery level like -1 or 255 that would indicate that it is currently charging in a cradle. 

 

Be wary with this property as you only should use it on packages like OSUpdates that you only want to run once and don't care about the unassignment in SOTI. If you were to use a minimum battery level as a threshold for assignment for an APK install for instance then you could run into scenarios where that APK gets automatically unassigned and thereby uninstalled every time the battery gets below a certain level. 

 

Also, IP range is a Filter Criteria you can use for profile application if you still want to go down that route, but that might be more cumbersome to maintain. 

  • 0
  • 0
Scott | posted this 06 April 2018

Same as your original question.  I'm looking to restrict large installs like LifeGuard or full OS packages unless in an ethernet dock.  Running latest (14.1) so that isn't a problem.  I hadn't thought of battery level.  Not sure that is an option though as we will probably have some part of the population that uses the USB cable for charging and thus wouldn't be on ethernet.  Good idea though.  Thanks

  • 0
  • 0
Feedback