According to your description, all your devices seem to be using lockdown menu with activity suppression mode enabled, and MobiControl device agent is one of the lockdown menu item.

What are the brand and model of your devices?  

Is there any particular reason you want to keep using AE device agent v14.5.5?

Are end-users allowed to add their PERSONAL Google Account to the device? 

Do you have any MANAGED-Google-Play app configured as SUGGESTED (i.e. installed on demand by end-user rather than always automatically pushed) ?

Is Google-Play app an item in the lockdown menu?

Hi Raymond,

Thank you for the reply.

Correct all devices have a lockdown feature enabled which uses activity supression. In fact the devices are "shared devices" so profiles active on the"logged in" and "logged out" devices groups are lockdown & activity repression.

However, mobicontrol agent is NOT a menu item. It just run in the back ground and is not seen unless in admin mode.

Devices are Panasonic FZ-A3

AE agent 14.5.5 is required because we utilise the "Platform Notification Service" (PNS) as a method of delivery of some actions. PNS does not work in v 15.0.0 and 15.0.01. I have and active Dev tickiut with SOTI to investigate this. For those interested, it appears that PNS stops working for fresh installs of 15.0.0 and 15.0.1 but continues to work following the upgrade from 14.5.5 to 15.0.1.

As part of a broader requirement, so for now we wish to specify 14.5.5 but for the future we want full control of the AE agent installed on the devices.

No users are not allowed to add their personal google accounts to the device. The devices are intended to be fully managed.

We have other managed google play apps as part of an app policy, these were previously set to auto-update so no expectation/desire for users to initiate updates. As as far as I can tell you cant set a MGP update policy for individual applications, via SOTI atleast.

The google play app is NOT a menu item.

Thanks

Adam

Hi Adam,

I can see you have a good reason to stick to v14.5.5 AE device agent. So the following the things I would do if I were you:

1.  When enrolled new or factory-reset devices  to your MobiControl server, use another Android provisioning device running "Soti MobiControl Stage Programmer" app with a proper configuration file to specify the URL to get your required AE v14.5.5 device agent.  With the configuration file, whatever is set about the source of the device agent (i.e. the default device agent from either your MobiControl server or from Managed Google Play store) in your add-devices rule will be overridden. Thus you also don't need to worry about other MobiControl server settings related to device-agent/plug-in upgrade.

2. Keep using the feature-control profile payload option to disable any device-agent upgrade.

3. Do NOT include MobiControl device agent as an app item from Managed-Google Play Store in ANY of your Android Apps-Policy/App-Catalog rule(s) targeted to your devices.   For all the other managed apps deployed from MGP store, you can  keep using your original option of "auto-upgrade", configured via  profile or wherever avaiable in the web-console UI for your MobiControl server version  Since the MobiControl device agent has not been included, NO auto-upgrade of the agent from MGP will be performed. 

(BTW, each app selected in Google's Managed-Google Play portal can be  independently configured to be updated only when MGP administrator grant the upgrade, especially when there are more app permssion(s) added in the upgraded version)

4. In the future when you can find a new AE device agent verison/build that fits your use-case,  download the new AE device agent apk and have the file deployed to your devices with MobiControl file-sync rule or other means (but not with .pcg package).  Use script of other means to run the deployed new device agent apk to complete the upgrade process.    For new or factory-reset devices, specify updated URL of the new device agent in the configuration file for  "Soti MobiControl Stage Programmer" app running on the provisioning device.

Hope the above together gives you a clear picture of a feasible solution now and for moving ahead.

Hi Raymond,

First of all, thank you very much for this reply.

Just for my complete understanding

1) Are you saying that QRCode enrollment options (for download location) override those of the add rule?

2) I am not modifying the stage programmer configuration itself, instead I have extracted the json, added "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://downloads.soti.net/apk/AEAgent/GoogleMobiControl1455_1023.apk" and generate the QRCode elsewhere. This would not result in any different behavior, correct?

3) You mentioned "feature-control profile payload option to disable any device-agent upgrade", currently there is not feature control payload (that I can see_ which is doing this. I believe this was achieved by the action "Disable Agent Upgrade". Would this be the same thing ?

4) You mentioned updating future agents but not via .pcg package, out of pure interest, why this suggestion?

Finally, if my understanding of what you have suggested is correct, then your method unfortunately for me and or this device at least, will still get updated.

I was convinced that as the agent was pulled directly from the Mobicontrol server and never touched google play/ managed google play; then there was no path upgrade for Mobicontrol. However, in between your replies I did some additional searching to find a google support post from 2020 by Matt Dormody in which it appears any application which is exists on public google play becomes managed by google play, sideloaded or not.

So at this point, I am rather confused. Surely there are GSM devices running fixed versions of Mobicontrol agents out there?

Thanks 
Adam

Hi Adam,

Please see my replies to your question below:

1) Are you saying that QRCode enrollment options (for download location) override those of the add rule?

ANS: Yes, if you are using a correctly formatted configuration file  /sdcard/Android/data/net.soti.mobicontrol.programmer/files/nfcprovisioning.txt

The information about some of the supported arguments in the config file at https://discussions.soti.net/thread/why-enrollment-by-afw-mobicontrol-and-qr-code-gives-different-results/ is not 100% accurate and complete, but should be sufficient for you to try out.

2) I am not modifying the stage programmer configuration itself, instead I have extracted the json, added "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://downloads.soti.net/apk/AEAgent/GoogleMobiControl1455_1023.apk" and generate the QRCode elsewhere. This would not result in any different behavior, correct?

ANS : I'm not sure, but I don't think the behaviour will be exactly the same.  If I have found a reasonably simple and stable solution,  I will stick to it.   If I have any spare time, I would rather use it to solve or hack other things.

3) You mentioned "feature-control profile payload option to disable any device-agent upgrade", currently there is not feature control payload (that I can see_ which is doing this. I believe this was achieved by the action "Disable Agent Upgrade". Would this be the same thing ?

ANS: Yes, You can keep using the new "Disable Agent Upgrade" action introduced in MobiControl v15.x  UI, though I am not 100% sure if it is only used to control device agent upgrade from your local MobiControl server.  Personally, I haven't fully checked  the proper functioning of the mechanism nor the proper way to make use of it for different use case, and thus I won't recommend or endorse its usage to my own customers.   In fact, from my experience on possible complexity in real production servers, I can immediately conclude that having ONE default device agent for EACH platform/OEM-brand on a single server implementation is bound to be a crippled agent-upgrade solution.   I only brought this "Disable Agent Upgrade" thing up in my previous post because you had mentioned something about it in your initial post.

4) You mentioned updating future agents but not via .pcg package, out of pure interest, why this suggestion?

ANS : About 12-18 months ago, someone from Soti explicitly told me not to put the agent .apk in a .pcg package to perform silent push of upgraded device agent.  The advice was proven to be correct in our own tests.  Some dirty tricks using .pcg were found to be OK in some special cases, but that's for real experts who know the limitations and did proper tests thoroughly for specific device and agent.   I consider the approach dangerous for the novices.  I won't rule out the possibility that the .pcg approach gets improved and well-documented in the future.

5. I don't know exactly which 2020 post from my friend Matt you're talking about.  

Any installed NON-MANAGED application which exists on public Google-Play store DOES get managed by Google Play, sideloaded or not, BUT ONLY when there is a personal Google account added  on the device.

I think you said in your earlier reply that there is no personal Google account added on your corporate device.  Also, if installed and enrolled properly, MobiControl device agent is a MANAGED app. Hence, whatever has been mentioned in Matt's post, should likely not be applicable to your case, I believe.

In a nutshell, my proposed solution is to block all agent upgrade mechanism from both Google-Play/Managed-Google-Play stores, and also from the newly introduced local agent upgrade mechanism introduced in MobiControl v15.x.  Use the most primitive manual approach to maintain full control if AE device agent upgrade is eventually needed.

If you still have problem, maybe you should recheck what you have previously configured in your Managed-Google-Play portal and in your app-policy/app-catalog rule(s), and possibly make necessary clean-up and see if the problem gets solved. 

Hi Raymond,

Thanks for your time on this!

For completeness, somehow deleted the url in the previous post for Matts Google Support question

https://support.google.com/work/android/thread/67460799/why-does-play-automatically-update-sideloaded-emm-installed-apps-that-have-matching-bundle-ids?hl=en

Best

Adam

I have definitely found that Google Play will update the MobiControl Agent automatically even if it is NOT an approved application in Managed Google Play. There have been similar issues with Zebra uploading their Enterprise Browser to the Public Play store and customer environments that had older versions installed directly by APK getting automatically upgraded to the new version in the Play Store completely unannounced. It can expose operations to considerable risk as its somewhat of an unpredictable time bomb that could go off. We have to place blind faith in the developers uploading new versions to Play that they won't break something, which is a pretty scary thought. Version control is still one of the major issues with Managed Google Play that is holding it back from being a viable tool for mission critical device deployments. 

Depending on how serious of an issue this is to you I would maybe suggest disabling Google Play completely on the device so that no updates are allowed through and then install whatever other applications you were installing via Managed Play directly via APKs if you have access to them. 

In terms of upgrading the agent via Package I believe one of the risks stems from the fact that the Agent natively will uninstall a Package after it has been assigned. Therefore if you were to unassign a Package based Agent upgrading Profile from a device after an upgrade you'd effectively be instructing the Agent to uninstall itself. Conversely, if you install something via a File Sync rule, that action isnt going to be undone if that Rule is later unapplied. Unassigning an APK installing Package based Profile will uninstall that APK by default whereas unapplying a File Sync rule that installed an APK via post-sync script will not uninstall that APK.

Hi Matt,

Apologies for the late reply.

Thank you for the suggestion of disabling google play, I will have to evaluate the implications of this for other applications installed.

Reading more and more about this subject it simply seems inevitable that google play store will take over the management and there's simply nothing else to do about it.

Oddly, we've deployed SOTI surf as via a package and this has NOT update automatically or been marked as available for update. Even though SOTI surf is listed on GPS and the deployed packageID is identical to GPS.

Thanks 

Adam