SOTI Pulse Logo

OEMConfig Profiles vs Managed App Configs

RG
Ryan Grimm
weismarkets

As of MobiControl 2024.0, I saw that SOTI added OEMConfig management through Profiles. Can anyone clearly explain the pros & cons to this over an application policy using managed app configurations? One reason might be due to some specific network or Google Play restrictions (outlined here), but other than that, what practical benefits do I have as someone that doesn't have those restrictions?

I also noticed that SOTI is pushing the legacy Zebra OEMConfig app when deploying the profile, so I've got more questions that documentation doesn't appear to discuss. They do "recommend" profiles over policies, but don't explain why. (This seems to be a common theme in their documentation, a lack of detailed reasoning and impact).

  1. How does SOTI determine which app generation (new vs legacy, Zebra) and which app version to deploy?
  2. Does SOTI ever update the OEMConfig app or not? How often and under what conditions? Do we have any controls over it?
  3. Do the same rules of managing OEMConfig still apply (i.e. tattooing settings to a device) or is there some other functionality to be had?

Thanks!

android oemconfig
a year ago
Android
ANSWERS
RS
Rafael Schäfer
a year ago

Hi Ryan,

it's always a combination if you use the integrated ones, as those provide only the configuration. Let me try to explain.

In the profile you do (seperated from the app itself) the managed app config, so you can deploy several different profiles with this configuration.
The oem config app has still to be deployed itself to the device (there you shouldn't add managed config then).

So, you can use one app policy providing the oem config app to all devices you want but deploy several different (OEM) configuration profiles to the devices (only one per device).
Finally they split the app deployment and the configuration part with this setup.

I mean for sure you still can deploy several app policys including the managed app config as well but i like the clear split of app deployment nd configuration deployment.

To 1.: I would not use the legacy one as its outdated (if i need to build a new rule now) but still available if companies still use it and dont need/want to switch to the new one.
To 2.: They do as far as i know when the oem config of the vendor gets an update but will be always take time i think after it has been released. So i assume there is a delay but it could also be that they read out somehow the possible manage app config dynamically. This needs to be answered by Soti i think as i don'T remember the answer from the when we talked about the new KSP version with them.
To3.: They only transfer the available managed app config from the oem app to the profiles, nothing in addition.

RS
Rafael Schäfer
a year ago

To add one big additional plus to this:

If you need to update the app (provided as an enterprise apk) with this split of configuration and app deployment, you don't need to "reconfigure" the apk when it's exchanged as it now is.

RG
Ryan Grimm
a year ago

From what I've gathered, enterprise app deployments seem to be going out of favor so I'm trying to move away from that deployment method. We only use it for one developer app that decided to use a Managed App Config (which I like), but they won't let us add the app to the MGP store (or even deliver it to us as a private app). It's a weird situation.

RS
Rafael Schäfer
a year ago

I have a different view on it because of my last comment (updating it to a newer version in app policys always needs to enter the managed app config again if enterprise app policy is used).

No, because the bundleId does not be allowed to be exist in Google already, that'S the reason to use the official playstore, enterprise app policy or packages.

MK
Martin K.
a year ago

If you delete an App from an App Policy and readd a new version, MobiContl asks you if oyu want to import the former configuration, the big issue is that most times it does not import the configuration of this exact App policy but the configuration from the same App which is used in a different App Policy.

I think it is not so uncommon to use one App with different configurations ?

RS
Rafael Schäfer
a year ago

It's not uncommon (especially when we talk about device configuration) and especially because of that in case of different configurations you can just clone a profile. (Currently not possible for app policys)

RG
Ryan Grimm
a year ago

I'm familiar with bundle ID restrictions in the Play Store, but I'm not going to publicly speculate on why they mixed and matched functionality the way they did.

In any event, we don't use enterprise deployments except for that one, specific app. I don't see any big gains unless you need to support a Managed App Configuration and can't get the application from the Google Play Store.

Every org is different though and I'm glad SOTI does offer the flexibility. The enterprise deployment method actually saved our bacon when another developer failed to act on warnings from Google in a timely manner and got their app yanked.

MD
Matt Dermody Diamond Contributor
a year ago

If you're talking about our app which matches this description as we offer Managed Configurations OR external configuration file options while not being available on public or private play, I can explain. We added Managed Configurations since SOTI supports offline Managed Configuration through Enterprise App Policies. There was never any intention of adding this capability for configuration through Managed Play. Our recommendation is still to use external configuration files instead however as the installation is more consistently controllable. We purposefully avoid Play Store distribution to protect our end customers from falling into the trap of thinking that is a good idea. For mission critical apps we need finite version control with the ability upgrade specific devices at specific times, with rollback as an available option as well. Managed Play does not offer anywhere near the version control needed to effectively support a line of business device environment so we don't offer that app distribution option to our end customers. We're ultimately protecting them from themselves. You wouldn't know you've painted yourself into a corner with Managed Play until its the middle of a go live and you need to push an emergency new app build to a subset of devices within the next 15 minutes during a shift change. Good luck doing that with Google Play. So if you think the design decisions I've made are weird that's fine, I'm doing what's best for you whether you realize it or not. 

RG
Ryan Grimm
a year ago

I'm not, unless you're the secret owner of another business.

There are others out there that do what you do, but in this case the vendor went from supporting individual config files to Managed App Configurations only as a way to support Android 11 scoped storage restrictions. So, that said, we cannot package up any supporting configurations as they no longer support that functionality.

Again, I do not understand the logic behind what they did, nor will I speculate in public.

MD
Matt Dermody Diamond Contributor
a year ago

I understand. We did see some examples of that early on with A11. For example StayLinked originally added Managed Configuration only as an option to handle configuration in A11 but then later were able to re-add the ability to use an external configuration file once you grant their app with the MANAGE_EXTERNAL_STORAGE permission. There are some tight restrictions on MANAGE_EXTERNAL_USAGE that may prevent a company from being able to leverage that permission. For example if the app is to be hosted in Play at all then that permission can't be declared in the manifest. Ivanti's Velocity for example is in the Play Store so they were unable to use MANAGE_EXTERNAL_STORAGE with their app to support external config files on A11+. In your case you're saying that the app in question is not in the Play Store at all so I would agree that is unusual that they don't also offer the alternative method of an external file for configuration as they should be able to declare the MANAGE_EXTERNAL_STORAGE permission.

RG
Ryan Grimm
a year ago

Maybe I'm missing something, but it feels like the only good reason to use a profile over a policy is to address customers in restricted countries like China or to use AOSP deployments (as the blog article seems to imply).

I see no substantial benefit to using profiles over policies when they behave exactly the same. Both deployment types install the app and deploy the configuration. Both methods can also deploy multiple OEMConfig policies too.

If anything, at least for newer Zebra devices, the benefits lean more towards a policy deployment method with the newer version of the OEMConfig app.

MD
Matt Dermody Diamond Contributor
a year ago

Outside of the OEMConfig specific question I generally prefer Profiles to Policies for app installation as they are more reliably installed in my experience and also carry the added ability to Force Reinstall packages contained within the Profile which can be helpful in troubleshooting scenarios. You can also currently clone Profiles fairly easily and there are Import/Export options for Profiles in recent MC versions. Cloning App Policies is not yet released. Package dependencies are also an option with Profiles if you want things installed in a specific order. The only advantage of App Policies is the ability to use offline Managed configuration through Enterprise Apps but I don't like that I can't force re-install the app or reapply the Managed Configuration from the Policy.

MK
Martin K.
a year ago

I think the issue is that Zebra has changed the configuration scheme from the old to the new OEMConfig, so doing Zebra OEMConfig with a profile (which is using the old schema) and install 11.9+ OEMConfig with an App Policy (without managed config) will probably not work, 

A
AMMOD@SOTI
a year ago

Hi Ryan Grimm

Thanks for posting on SOTI Pulse, Thanks Rafael, and Matt for responding to the post, your expertise and willingness to help are greatly appreciated!

Have you had an opportunity to test the suggested solutions by Raymond and Rafael, and has it successfully addressed your query?

If not, or If you have any additional questions or concerns, please don't hesitate to reach out. We're dedicated to providing assistance and support.

Similar Discussions