How to configure granular device settings upon enrollment (beyond what Stage can do)
afw#mobicontrol is called a DPC Identifier and using that for enrollment is one of the 4 official Android Enterprise native options for Managed Device enrollment. The other options are QR, NFC, and ZTE. Samsung is kind of in a gray area since they, liked Zebra, developed a lot of management capabilities (Knox) before Google started focusing on the enterprise and catching up. As a result, Samsung does not really support ZTE as they have their own version that was out first called KME. Regardless, even if you could enroll using ZTE you would not be afforded any other configurability options than what you have with DPC based enrollment because they are both paths that take you to the same place, a Fully Managed AEDO device.
The Feature Control and Application Run Control profiles are good places to start as they at least contain the configuration options that are exposed within the MobiControl GUI. You may need to upgrade your MobiControl console to a more recent version in order to gain access to more AE specific settings. Given that AE is the future of Android management SOTI, and most other EMMs, are putting a majority of their investment into AE, which means newer versions of MobiControl often have a lot more AE specific features than older versions.
Beyond Feature Control you can explore what options are available to you as writesecuresettings. I have had mixed success with writesecuresettings on AE so far, but based on the release notes of the recent AE agents it appears that SOTI has been adding these features back in and some priority has been placed on Samsung devices.
With all that said, I find that, despite what Google wants you to believe, Android Enterprise still doesn't offer the same level of manageability for fully managed / COSU devices that we had under Device Administrator (Android+). EMMs like SOTI are trying to achieve feature parity as best they can but we're still very much in a bumpy transitionary period between the two management principles. There will be configurations that you could perform in DA that just aren't there yet in AEDO.
I don't think you're going to find that kind of feature anywhere for Android. I'm not even sure I would want that feature even if it did exist. What would happen if you later had to change one small setting contained within your device clone image? Would you redeploy or reapply the entire clone to all device that need it? There is a reason why configurations are broken out and applied via packages, scripts, and profiles so that you can have better control over how they're deployed. If you were just cloning devices with a "golden image" then you might not even need an EMM in the first place.
Hey Matt, thanks for the very complete reply. Let me work backward from your summary comment/question.
We use Mobi for more than just device setup. Out primary need is actually for remote control of the devices-- we support technically, er, "unproficient" users more comfortable with knitting needles than tablets, but if it was only Remote and setup then yes, Mobi is overkill. Something like Bomgar or LogMeIn would work better.
We have 2 apps that we need to maintain version control on, if we relied on standard Play store they would upgrade when the vendors pushed a new version. So we have been using Android Plus and application install profiles using packages from APKs for the approved versions. We need to restrict OS updates, but permit them once approved, so we impose and lift a feature control profile with the OS Block toggle when we decide to allow a new version of Android or a security update.
I have been living with our current enrollment and setup methods for 4 years and would probably have kept the train rolling on the same tracks if not for the deprecation of remote control with Android Q for non-Enterprise devices. There is a lot that I like so far with Enterprise but, as with anything SOTI, there were very unexpected and surprising differences, like how the Block OS Upgrade must now be done via a script and cannot be done via a feature control profile. This wasn't documented anywhere that I could see, and if not for this forum I would not have imagined that the functionality would have been changed.
I have been waiting for years for SOTI to augment the Settings Manager so I can finally push everything into kiosk mode and be done with all the manual configuration. We would already be using kiosk except that our users have to be able to manage their wifi settings advanced features to be able to "forget" past networks-- they perform surveys all around the country in during an assignment may accumulate dozens of remembered networks (one user had more than 90) and the devices become very gitchy with connectivity in areas of weak LTE or 4G signal as the tablet tries to connect to any of the previous networks. They have to periodically purge this list for life to be good. I would love it if there was a way to do this via script, but it couldn't be done in scorched-Earth fashion, it would have to be able to blow away networks not used in n-number of days so as to not delete a network they might connect to again while int hat same locale (like at their hotel, Starbucks, etc).
The cloned image would be just for Settings, which don't vary very often at all. We tned ot only adjust them when we get a new device or if a new OS offers radically different options.
So yes, MDM/EMM is good for us but we spend most of our time with workarounds because none are ideal for our use case, Mobi is the least bad (or most good?) LOL
PS- I have found that feature requests are where SOTI sends things to die. I have asked for this capability dozens of times, everyone I speak to at SOTI says they will write it up as a request but every time I ask about it I am told they can find no record of it, very "the check is in the mail". I know that not everyone needs this in the exact same way we do but if they could reveal a configurable settings manager-- check the things you want-- from ALL settings, not just the Top Ten, life would be far easier for us.
Almost forgot-- what is writesecuresettings? I can find no documentation on this, what does it do, how is it used?