It seems that your problematic devices do not have the device agent properly installed/configured.

Did you upgrade from an earlier server version to your current v14.2.0.2894?  If so, from what version? And did you perform any over-the-air agent upgrade after the server upgrade?

How long have the file-sync problem been persisting?  What percentage out of the total number of SM-T585 tablets have problem? 

For the problematic devices,  are the last check-in time and last status update time reported in the web-console abnormal (e.g. timestamp of many weeks/months ago)?

Previously we used version 14.1, which was installed one by one with the agent downloaded directly from the server, then we updated to server 14.2, the tablets updated all their agents by air and in some tablets the samsung rc began to fail in about 12 , so a soti member told me to send the script:

_resetfailedrcdetectionflag
__switch SAMSUNG_MDM57 SAMSUNG_RC_V1
restartagent

And there the situation worsened since of 12 tablets we passed to 120 with this problem, this began in November approximately.

For example on one of the tablets, this is the right moment when the license started to fail after sending the script, on November 14, and from here that sequence of logs is repeated

Hello Nicolas, 

Can you try to use the following script on a test device when you are experiencing the RC feature disappearing, instead of the one you are using and let me know if that fixes the remote control API not being enabled issue first?   

Perhaps then we can help with the other issues you are experiencing.  

_resetfailedrcdetectionflag
restartagent

As you have already used the previous script on the devices in question, I would suggest using a fresh device or factory reset device that wasn't "fixed" with the previous script.  

Regards, 

Hi Nicolas,

I am not sure what you mean in your post.  Did you

1. number of problematic devices goes up from 12 to 120?

2. send the script to 120 problematic devices and still have 12 of them not woring?

3. have 120 devices in total, and 12 devices are problematic since November?

Upgrading the server and using the script you showed could have solved the problem if done cautiously and properly.  Otherwise, things can get even worse.  As your devices are scattered in different provinces of Argentina, you should have tested each step thoroughly before mass scale deploying any change. 

In particular, I am puzzled about the following:

- Were you told beforehand how to verify the effectiveness of the script?  Did you send the script to each device one at a time and closely monitor the active API's reported and confirm controllability, before you move on to work on the next device?   

- Have you tested each combination of firmware version and agent version thoroughly on some test devices before mass scale deploying to other devices of the same combination?   If all your devices are Samsung SM-T585,  how come they were not unified to use the same  android version and device agent build to minimize the complication?  

- Had the devices been thoroughly tested upon initial enrollment at your office before they were deployed to other provinces in Argentina?  Did you check remote control, file-sync operation, locking device or assigning/revoking profile?  Is remote control session essential in your use case?

Since you received instruction from a Soti guy previously, I suggest you to raise an official ticket again or escalate previous support case with Soti support team.