SOTI Pulse Logo

Android Device Agent Upgrade Strategy - By Device Instead of By Group

CR
Chris R.
SkyBitz - End User

Hi,

I have been testing the latest agent on multiple devices as we haven't upgraded our agents in a couple of years and there are some Javascript functions we'd like to have available in later agents. 

I have noticed in the past that when an agent upgrade is initiated through the console, the agent on the device will close and then re-launch when the new agent is installed.  This causes the lockdown kiosk to go away and then re-enable which moves our custom application to the background and could cause someone to have to login again.  If a user is in a certain event a transaction could be interrupted, etc... and we could have data loss. 

I am looking to see if anyone has best strategy for managing agent upgrades.  We have around 3800 devices in around 70-80 groups based on customer.  I know can control upgrade per group, but is there a way to initiate the upgrade per device?  This way I could at least determine if a user is using a specific device before starting the agent upgrade.  Not ideal since there are 3800 devices but this is where we are at.

Adding that since I haven't changed the compatibility for agent upgrade in a couple of years, I'm unsure if the upgrades still work in this manner.  I wish I could test the upgrade process through the console itself instead of sideloading.  Maybe that's possible by briefly changing the compatibility and then making some DB changes to change it back?  I'm also a little handcuffed on setting the compatibility to the latest agent as well as that will put all 3800 devices as non-compatible immediately which I have noticed halts the ability for devices to receive Profile changes.


Thanks

3 years ago
Android
ANSWERS
MD
Matt Dermody Diamond Contributor
3 years ago

I typically use File Sync rules for performing Agent Upgrades. The File Sync can deliver the APK as a file and then the post-sync script can be used to install the Agent. Installing via the built in service is otherwise painful and installing via Package is dangerous as you could trigger the agent to uninstall itself if an Agent based Package is ever unassigned. File Sync Rules have the advantage of being able to be applied to Virtual Groups. I create a Virtual Group that is empty of filters and then manually drag devices into that group to update them in batches. You can alternatively string together a lot of different criteria in your VG (eg. isCharging = true) if you want to try to automate it a little more than a manual batch upgrade. 

CR
Chris R.
3 years ago

Matt, do you know if the scripts area of the FileSync rule supports Javascript?

L
LCRMOD@SOTI
2 years ago

Hi Chris,

Thank you for contacting SOTI Central.

Yes, Java Script is supported within the File Sync rule.

Some script editors (largely those accessed from the legacy console, such as within File Sync rules) do not include the switch that specifies the script type. Start your script with the following shebang line #!/usr/bin/env js to ensure the Android device agent recognizes the script as a JavaScript script.

Example:

#!/usr/bin/env js

// Enter administrator mode if the device name starts with ‘Headquarters’

if (mobicontrol.device.name.startsWith('Headquarters')) {

 mobicontrol.agent.enterAdminMode();

}

You can use scripts to add automatic processes to the file sync. These processes, or actions, can be performed on the server (before file synchronization) or on the device (before or after file synchronization).

Server-side scripts are only supported on on-premises instances of SOTI MobiControl and require the assistance of SOTI Support to implement. Contact SOTI Support for more information. If you have active server side scripts from a previous version of SOTI MobiControl, they will continue to work but you cannot edit them without SOTI assistance.

You can find more information on File Sync Rules here: https://www.soti.net/mc/help/v15.4/en/console/data/filesyncrules/using.html.

See JavaScript Samples for some sample scripts that you can adapt for your organization here: https://www.soti.net/mc/help/v15.5/en/console/other/JavaScript_Samples.html.

Training on the Android Scripting Engine is available at SOTI Learning Academy which is accessible to customers with an active Premium or Enterprise Support entitlement. If you do not have access or would like to gain access, contact your Account Representative.

Regards, 
Technical Support | SOTI Inc. |1.905.624.9828 | Log a Case Webform | SOTI.net | Facebook | LinkedIn | Twitter | 

RS
Rafael Schäfer
3 years ago

Maybe take a look into the api:

In the /devices/{deviceId}/actions part, theres a UpgradeAgentNow action which could maybe do what you want but never used it for now.

CR
Chris R.
3 years ago

I don't mind the idea of using the Virtual Groups and FileSync method to selectively deploy agent upgrades instead of using the built-in method.  I use VGs for other similar tasks so this may make the best sense.

For the APIs, that may be worth exploring but I assume I'd still have to update the compatibility in order of it to get the new version.  That then makes the devices incompatible until updated which will prevent us from deploying profiles or changes until they are all upgrade.

RC
Raymond Chan Diamond Contributor
3 years ago

If your 3000+ devices are of different brands/models and running different firmware versions, extensive tests should be done to determine which device agent is the best one in terms of stability, features and seamless upgradability, etc. for each combination.   If it is found that there are two or more device agent versions to be used, using the virtual group plus file-sync rule approach can be a good systematic way to gradually upgrade devices with the right agents at the right pace.

Besides, you might also deploy alert rule on the virtual group, using  device agent version as event trigger and associated alert action of automatic relocation to a virtual child group.  This virtual-group hiearchy can help reduce your upgrade task burden by providing clear visibility on which devices have or have not been processed.

Similar Discussions