I can't believe it's finally here. Has anybody started using it with SOTI yet?
No Matches Found!
Try with a different search term
No Matches Found!
Try with a different search term
I can't believe it's finally here. Has anybody started using it with SOTI yet?
Yep! Got my hands on a 14.4 instance yesterday and was able to confirm that I can pull and render the schema. Still trying to work through the comparisons with the standard mxconfig XML. At this point, while I have been excited about OEMConfig in the past, I'm now relatively skeptical. I worry that I'm going to have to have multiple variations of OEMConfig assigned to different groups of devices, manually configuration each setting within each permutation. With the XML however, its a lot easier to break things up into separate XML files so that you can have more control in applying them to different groups of devices. We also have instituted a fair amount of version control over our MX configuration settings and it doesn't look like that is going to be much of an option with OEMConfig. I also worry about the Play Store dependence and how that results an invariable amount of time for the settings to be configured. So far, I'm not impressed and I'm really hoping Zebra or SOTI doesn't deprecate support for the EMMTK based MX approach that works with mxconfig. In short, it feels like OEMConfig was built for the use case of an individual IT team managing one fleet of devices. It's going to be a lot more challenging for managed service providers who manage 50+ different environments to institute version control and standardization. I see a lot of manual check box clicking in my future.
That's exactly what I thought when I looked at it. How the heck are you supposed to exercise any level of granular control? Maybe I'm missing something here but this model seems entirely unworkable. "Settings" shouldn't be tied with a specific apk unless there is a separate "config" instance similar to how the SOTI Settings Manager works. If mxconfig is TRULY deprecated after O we DEFINITELY won't go to P until something more workable is in place...
Hi Matt,
Where did you find the graphic above? This does cause some real concern. Particularly with Pie being released for all the new Zebra gear and customers desire to be on the latest OS. After initial testing this seems very cumbersome way to manage device settings that often change, need to be tested individually and applied on the fly. Like you said previously, after using MX XML for years. It becomes so modular and easy to apply via MDM. Here's hoping this will evolve more before depreciation of tried and true methods of management.
That was pulled directly from Zebra's EMMTK documentation.
That site also includes the following graphic indicating that the XML MX delivery method would no longer be supported by Zebra starting with Android P.
The term supported is an important distinction here. I have reached out to Zebra on the matter and have confirmed that the functionality is not being discontinued or removed in their Android P builds, but they will no longer be supporting any issues related to XML based MX delivery. Zebra Managed Configurations (ZMC) delivered via OEMConfig is all they will be supporting for Android P and beyond. I have already confirmed on an early P build for the Helios class devices that the XML delivery mechanism is at least still working, so that is a good sign. We should be able to continue to leverage the XML option for the Android P builds from Zebra, unless they decide to discontinue that functionality later.
I guess we also will rely on SOTI to not discontinue support either. We know that the current Zebra plugin for AE supports MX and removing support would have to come in the form of a new plugin in the future. Therefore, if they do remove support in a future plugin we could probably continue to leverage the older plugin.
Hi hope the OEMConfig plugin will be included in mobicontrol directly in the future....
Let's think to all those customer who don't want GMS enabled on their devices, without GMS and a managed google account it will not be possible to install OEMConfig plugin and configure the device...
Let's cross fingers
OEMConfig relies on Managed Configs which as far as I'm aware, only work through the Play Store architecture right now. It would be great to remove the reliance on Google Play so that we can administer Managed Configs directly from EMM but I don't think Google is going to be too keen on that. I hope EMM providers figure out a way to do it anyway!
Had a good discussion with Zebra development and they confirmed for me that submitting MX XML will not be going away as was previously intimated, at least for the foreseeable future. They recognize that OEMConfig has a looong way to go.
What WILL be going away is public documentation and "external support" of newer CSP changes in deference to Managed Configs. As long as MobiControl continues to provide the mxconfig command we should be able to export from stagenow and submit via mx xml though with no issues.
Whew!!
Also, they said that using/managing/applying OEMConfig outside of the google playstore would very likely become a reality at some point. It's just not top priority for them right now.
Feeling much better now...
Has anyone within this forum introduced OEMConfig in a big scale for sites that requires a need for great granularity for different sites, regions, countries or are we still sticking to the old fashioned way of deploying an XML to a device and running MXCONFIG command?
This is interesting to understand since I hear more and more about the removal of this type of functionality and that all need to adapt to OEMConfig since this is the "Android Enterprise" way of working.
Would be interesting to get a comment on this particular topic from SOTI and if they or someone else here has any type of insight if these type of functionalities to actually deploy files to devices will be removed. I cannot see that this is an "Android Enterprise" way of working.
OEMConfig sucks.
We are still using mxconfig & xml files and are very happy with that option given the granularity of configuration options and the amount of control you have over application with Profiles. Relying on the Managed Play store for distributing configuration settings via OEMConfig is very cumbersome and not portable. It is easy for us to create a package one time and use it across multiple device types or even SOTI environments. With OEMConfig you have to manually configure everything every single time and you can't modularize it. It is also inconsistently and slowly applied out to the devices after making changes.
SOTI might add support for distributing Managed Configurations to devices outside of Managed Play in the future which may help with the current dependence on the black box that is Managed Play. Even then I am not particularly excited about a full Android Enterprise future where options like mxconfig go away.
OEMConfig is not a viable alternative. Similarly, LifeGuard OTA still has a ways to go before it matches the amount of control we have with update zips today.
Hi Matt,
I absolutely agreed with you. The problem is especially serious when the number of configurable parameters exceed 50-100, which is often the case for OEMConfig apps.
Maybe one simple way to improve OEMConfig/AppConfig support in Soti MobiControl solution is to at least add some kind of export and import function of configured parameters (in XML, JSON, or even some encrypted format) in the web-console. Administrators can then at least perform some cloning or back-up operations easily. If the format is XML or JSON, it will then be possible to use various utility/script to cut-and-paste, reorder, or modularize configurations in groups systematically.
I hope some so-called forum moderator(s) from Soti can proactively alert relevant product managers within Soti to take this issue and suggested solutions seriously. If any product manager wants more inputs from me, they can contact me by my email or via public post or private message supported in this forum.
Hi Matt / Raymond,
You're always welcome to raise Feature Requests via support@soti.net / support.eu@soti.net. Ideally, you need to outline the existing problem, use cases, and the proposed solution/s. Along with any other information that can be useful for our Product Management Team.
Technical Support can also provide you a reference # for the Feature Request, which allows you to also chase it up at a future date. I also believe if a Feature is being introduced you will be notified.
Let me know if you need any clarification or have any questions.
Regards,
I am speechless!! Words just failed me!
Please look up the meaning of the word "proactive".
@Matt & Raymond
Valid points/input you're raising. And this was exactly what I was worried about. The reply back from SOTI Support. I've raised multiple Feature Requests. In terms of transparency there is no real overview or transparency or possibility for customers/partners to share their views on raised requests. Similar to what other companies offers e.g. Microsoft - A global portal for us to comment/raise the need of ideas to be implemented and prioritized or at least to see what is in the pipe-line.
There seems to be a big disconnect somewhere in the chain and the question is how we in the long-term can proactively be involved and understand what can be done in the future with a tool such as MobiControl when it comes to how Google determines our way of working within Android Enterprise devices...
Has Google or the manufacturers e.g. Honeywell / Zebra shaken hands with SOTI to allow their control over Android Enterprise Devices with their plugin that allows us to leverage components Android+ technology in Android Enterprise - Which in fact is "Device Admin" capabilities inside of Android Enterprise or will these features go away in 1-3 years from now?
