SOTI Pulse Logo

URGENT: Upgrade to latest version 15.1.0 3416 led to Android devices problem

ER
Enrico Rossi Ferrari
SECH Terminal Contenitori Porto di Genova S.p.A.

Yesterday the upgrade made android terminals (Honeywell VM1A) unusable.

No issue neither with Windows CE devices nor with Windows Desktop devices.

The upgrade from the old agent HoneywellMobiControl1400NewGen_1579 to the latest available HoneywellMobiControl1417NewGen_1117 led to the following problem:

- the terminal remains locked on boot on the honeywell logo and does not arrive when the lockdown is loaded.

We tried to install the old agent in a brand new device but it doesn't get the profiles from the server, they still remain pending; just remote control works.

We have not proven the behavior of a brand new terminal with the new agent 14.1.7.

We have seen that a non-branded version 14.1.8.1111 default is also available but we haven't tried to install it yet.

Is there any issue on using the non-branded version?

Is it possible to revert the Add Device Rule to use the old agent? Maybe new rule?

Do you have any suggestions? 

Thank you really much in advance.

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

If you're using a "branded" agent that would imply that you're still using Android Classic (Device Administrator based management previously called Android+) instead of Android Enterprise?

The VM1A is likely to be running Android 8 or higher so I would expect that you'd need to migrate to Android Enterprise based management with the generic AE agent rather than continuing to use the legacy methods with the branded agents. 

D
DDMOD@SOTI
5 years ago

Hi Enrico Rossi Ferrari,

Thanks for posting your concern!

Can you please raise a support case(click here) or call SOTI Support team(click here) as further troubleshooting is required to resolve this situation?

 

Regards,

ER
Enrico Rossi Ferrari
5 years ago

Thank you all for the support.

At the moment we prefer to wait to raise a support case because after a more detailed analysis we found out that the issue didn't happen on all the devices, so we are not able to reproduce the problem here in the lab.

We discovered that the issue mentioned before happened just after the shutdown. No issue with the soft reset.

At the moment the faulty devices are back again with an enterprise reset and had come back to production.

In this situation we are able to shutdown the device both via software and via hardware without problems.

We will let you know any news as soon as possible.

Thanks and regards

Similar Discussions