Zebra Android OS Update Options
- 16 January 2018
- SOTI MobiControl - Android
6 Answers- 1 Upvote
- 2 Followers
6 Answers
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.
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.
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.
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?
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.
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