Could have nothing to do with it but when i experienced this issue it was because the SSL request was being decrypted by our Firewall.

Might be something to check?

Thanks, but further testing has shown it was due to the SHA-1 self-signed certificate installed on the Mobicontrol server.

I wish we had been told this would be an issue before they updated. The only solution I can find is to replace the devices.

Some of my customers encounter similar problems with a handful of new Android 10 devices in their test phase before mass scale deployment.  Renrolling such devices upon device factory reset is also problematic.  We are in the course of looking for the major cause(s) and finding possible solution(s).   Upgrading the MobiControl server and device agent are currently top on the list to "permanently" prevent the problem from happening again.  

What are the version and build numbers of your device agent?

What about those for your MobiControl server?

How many such problematic devices are currently enrolled and out-of-control in your system?

Android 10 and IOS13 devices require a SHA-2 certificate.

Behavior changes in Android 10: https://developer.android.com/about/versions/10/behavior-changes-all

If there are legacy devices that still require a SHA-1 certificate (Windows Mobile,  CE 6 and earlier) enrolled in your server, a secondary deployment server with the new SHA-2 certificate will need to be created.

Reach out to SOTI support for direction on either converting to SHA-2 certificate without losing devices or adding a secondary deployment server. 

I presumed you have only recently changed the device-management address as well as the primary agent address within MCadmin to reference the FDQN associated with the SHA2 SSL certificate, rather than using IP address in the past.   If this is the case, I believe that you likely cannot get the problematic Android 10 devices back in control.  If you have added the SSL certificate and properly re-configured various parameters with MCadmin BEFORE performing any firmware upgrade, the current problem can be avoided.  Also, you should have performed test on one upgraded Android 10 devices before allowing the other 49 to get upgraded. This approach at worst forces you to factory-reset/re-enrol one one device, rather than 50 devices.

I would recommend you to open an official support ticket with Soti Support team and see if anything can be done to get the device back under control without requiring re-enrollment.

I have looked before but cannot find the option in Mobicontrol to prevent firmware updates on Android Enterprise devices. If there is one then please let me know as we had previously disabled updates on Android+.

If Soti had told us what a big issue it was then we could have easily updated the certificate before the Android update.

We have an issue open with Soti support for over a week but they have been unable to provide a solution so far.

We have manually unenrolled the devices and then re-enrolled them to fix the issue. No easy way to fix it in Mobicontrol.

For Android-Enterprise device platform, disallowing firmware update feature-control support has been added via script or OEMconfig plug-in only for a smaller number of device brands recently.  Without that, one generic workaround that should work for any device brand is to limit the firmware upgrade time window to an extremely short 1-minute interval everyday with the "set_system_update_police" script command.