If I am understanding you correctly, this is a feature I'd like to see as well. It looks like most of the profile settings work this way. For us, we require PIN codes on all devices, so that is set in the parent group. One child group of that is for working on devices here in the office, where it would be nice to not require the PIN. We can't simply set a new profile that does not require the PIN to the child group. Instead we have to unselect this specific group when assigning the overall profile, then make a whole new profile without the PIN requirement.

It would be nice to see some sort of precedent given to the child profiles over profiles inherited from the parent.

Yep.  Same is true of "Device Settings" and "Lockdown".  I've tried various combinations.  "Device Settings" at a lower fails to apply (shows failure on the client).   I guess for now you have to do alot of "keeping mirrors aligned" be selectively applying (and not applying) profiles to different groups.

It would be nice to have a priority level for profiles, so if there is a profile with higher  priority it would prevail over parent profiles. That's the approach in other EMMs.

The issue is much more complicated than you think.  Different payload settings/parameters in a payload may need different treatment (e.g. logical OR, logical AND, union, use first, use last, etc.) if they are simultaneously defined in multiple profile instances.  Thus, except for some payload that make sense to have multiple instances (e.g. Wifi, bookmark, etc ), it can be chaotic to have the same payload defined by more than one profiles to be assigned to a single device as there can be conflicts between the payload settings.  

Even worse, each device platform owner (Google, Apple and Microsoft for Android, iOS and Windows respectively) has different ways/logics to handle MDM policy conflicts. 

Hence, for payloads such as feature control or lockdown menu, it is best to have ALL settings of a payload defined in only one profile for any device.  

Soti intelligently added in v12+ support for profile on top of the legacy device-group-tree hierarchy with parent-child inheritance and optional overriding of

(1) device configurations (i.e. the profile payloads from v12+)

(2) rules and

(3) advanced configurations

used in v11 and earlier.  Together with additional features such as virtual group, profile filter (by LDAP/dev-property/custom-attribute/custom-data,etc.), it is the most flexible to allow reuse among all top EMM solutions in the market.  

If you really have multiple profile instances containing the same payload inherited from node(s) higher up  in the device tree, you can either

1. manually go to the device profile tab for each device, and "revoke" all but one profile withe the payload  that you want to use.  (similar to overriding inherited configurations in v11 and earlier)

OR

2. use custom attribute(s) to implement some kind of priority system, and add profile filter based on such custom attribute(s) when assigning the profile you define.  (This can potentially be maintained very quickly because custom attributes are also automatically inherited if not explicitly over-ridden by web-console administrator.)

The issue is much more complicated than I think?  I hope you give me the benefit of the doubt that I've at least thought about it but perhaps you're right and it is more complicated than I think.  However, Soti isn't the first company to ever attempt this.  (Microsoft seems to have this pretty much figured out)  Yes, it can be chaotic if the platform does not have a uniform mechanism to resolve conflicts and a better mechanism to specify settings.  Soti obviously realizes the need for, and the benefit of inheritance as they do implement it.  I can create a setting at the top level and change it at a lower level.  The problem isn't with the inheritance.  It's the limitation in how the setting is specified.

Even worse, each device platform owner (Google, Apple and Microsoft for Android, iOS and Windows respectively) has different ways/logics to handle MDM policy conflicts.
IMO it is not up to the device platform owner to handle MDM policy conflicts.  That is the job of the MDM server and/or client.  The MDM platform should resolve any conflicts before attempting to translate those into commands for the device platform.

"Hence, for payloads such as feature control or lockdown menu, it is best to have ALL settings of a payload defined in only one profile for any device."
IMO that is trading managing chaos by the MDM provider for managing chaos by the customer/administrator.

"If you really have multiple profile instances containing the same payload inherited from node(s) higher up  in the device tree, you can either..."
Yes, as I mentioned in my earlier post, I can do my part to manage chaos by selectively applying/not applying profiles with variously implemented custom data.  OR...

Soti could simply implement settings like Microsoft does in Group Policy.  By default rather than just "Disable", provide a choice of "Enabled", "Disabled" or "Not Set" and then go from most general to most specific in terms of application of settings.  The need for adhoc changes and custom attributes or data would then be greatly reduced.

Then, to be really crazy, they could provide something like gpresult on a device that could produce a report of the resultant set of applied policies and settings for troubleshooting purposes.

Hi Scott,

If you have the chance to look deep into the stacks of documentations defining the MDM protocols for most major platforms, you will find that what MDM functions are available in the firmware is basically defined by the platform owner(Apple, Microsoft and Google) .  Many of the conflict resolution details are also defined by them, and might evolve from time to time between versions, and all MDM vendors can just follow suit.

If Microsoft is so good in defining/implementing their group policies in previous Windows products, do you have any idea why they don't use the same approach in the latest Windows Unified (Win10) platform, and have "enabled","disabled", and "user configurable" option for only a "small proportion of the feature control items they themselves defined? Also,  how come Apple only define mostly "disallow X" options for restrictions profile in its MDM protocol specs (https://developer.apple.com/library/content/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html) for so many years?     Each feature-control item has different considerations, and it  may not make sense to implement what you suggest. 

In the past I encountered many cases when some potential customers evaluating MobiControl could not get some profile payloads properly deployed on their test devices because of improper profile settings or profile conflicts.  Mobicontrol sometimes found the conflicts unresolvable and had to report that the policy could not be deployed.  Some complained that Mobicontrol did not deliver exactly what they had configured because they didn't know about the automatic conflict resolution alreadt done in the background.  These are reasons why we often need to give guidelines and best-practices on using device hierarchy and profiles organization and related issues in our training to customers who eventually buy the product.

Finally, most leading MDM softwares on the market are multi-platform, and the UI and policy assignment mechanisms  should cater for uniformity across platforms.  So, some compromises need to be made when evolving products between versions.   I am not from Soti, but I think they have done a pretty good job to deliver a great product which is much more flexible than most competitors.  Of course, it would be even better if they have better documentations, and more flexible product pricing models (e.g lower price if some features excluded in the server binary). 

Hey Raymond,

If you have the chance to look deep into the stacks of documentations defining the MDM protocols for most major platforms,
Again, this is an implementation detail.  I fully recognize this point is the main rat's nest for Soti to tease out as best possible but after all it is what they signed up for.  I understand that different platforms support different options and not all are supported by all.  But, assuming a feature is controllable, the ultimate state of the feature on a single device is either on/enabled or off/disabled (or not changed).  How I am able to use the MobiControl administration platform to model the intersection of what that feature state should be is the issue.

If Microsoft is so good...
Believe me, I fully recognize MS has deficiencies, which is why I said "pretty good" and "pretty much".  I discount the UWP model as I don't believe most large enterprises are using it except where they have to (Windows 10 is not synonymous with UWP).  IMO UWP is Microsoft's attempt to "Appleize" Windows and seize control of the app store model.  Most large enterprises are still using the still supported domain group policy to manage machines.  The fact that ALL possible settings are not included in GPO doesn't diminish the success of the management model itself.  It just limits the ultimate effectiveness of the implementation.

I'm admittedly not intimate with Apple but translating "Allow/Disallow/Not Change" into "Not Disallow/Disallow/Not Change" on the specific device is again a function for the device specific MDM client to accomplish.  Not a trivial task, I readily admit but this is what you are attempting if you sell a multi-vendor/multi-platform MDM.

...I think they have done a pretty good job to deliver a great product which is much more flexible than most competitors...
I agree.  We purchased the product, specifically for remote control capabilities that others don't have.

It's clear what I was hoping for isn't currently in the product.  My original question was looking for how others were dealing with an enterprise default model of "deny generally, allow specifically" were implementing Feature Control.  Since we are pretty early in implementation I was looking for the best way to start so we won't have as much "enterprise model change" later on.  I won't beat this dead horse any longer.  I realize though that Soti does monitor this board and so my responses were in the hope that it will be at least taken into consideration for future development.

Cheers

Hi Scott,

Your assumption that if "a feature is always controllable" is just not true in the MDM/EMM world.  Apple and Microsoft have complete control on the MDM protocol and firmware implementation, but they still intentionally don't define it that way for ALL MDM features.  The main reason should be a balance between controllability and privacy.

Take Android  "Enforcing GPS availability" as an example.  From the device side, it's true that the device end-user can turn GPS on, off , or  leave the state unchanged.  However, from the MDM server side, the scenario is totally different.  Turning "Enforcing GPS availability" feature ON can remotely turn the GPS on if it is not already on,  but turning "Enforcing GPS availability" feature OFF cannot turn GPS off if it is already on.  Even worse, Google  add new limitations in newer Android versions to make that above even more restrictive in the response to respect end-user privacy or changing legal requirements.  Thus don't assume that you can always get more controllability on the same MDM feature as time goes by.  You might get less or even no controllability with newer MDM product/firmware version because the platform owner don't allow it.  This is the same for any major MDM vendors.

Each of my governmental/corporate customers used different criterion to from their device group hierarchy, including but not limited to the following: organization structure, geographical location, project, job nature, employee's grade, device brand/model, firmware version, etc, or a mixed combinations of all of the above.  The hierarchy you described is a bit interesting, and I have never seen any of my previous customers doing it that way.    I believe you are giving yourself maintenance troubles, because MDM feature controllability may increase or decrease with time.

I didn't say "if a feature is ALWAYS controllable".  I said "assuming a feature IS controllable".  In other words, "IF a manufacturer has chosen to make a feature controllable".

Take Android  "Enforcing GPS availability" as an example.  From the device side, it's true that the device end-user can turn GPS on, off , or  leave the state unchanged.  However, from the MDM server side, the scenario is totally different.  Turning "Enforcing GPS availability" feature ON can remotely turn the GPS on if it is not already on,  but turning "Enforcing GPS availability" feature OFF cannot turn GPS off if it is already on.
I think most people realize that removing "Enforce GPS availability" is not the same as "Disable GPS" so one wouldn't expect that removing that policy would necessarily turn off GPS.  It just would no longer require it to be available on demand.  This has nothing to do with the issue of the original post though.

Each of my governmental/corporate customers used different criterion to from their device group hierarchy, including...The hierarchy you described is a bit interesting...
I don't believe I've ever stated what criterion I was using to determine our device group hierarchy and for this discussion, it doesn't matter.  The model provides a hierarchy structure and an inheritance mechanism, assumably, to ease the burden of managing a large fleet of devices with varying requirements.  My issue is not with how any specific setting is ultimately implemented on a single device.  The issue is how the inheritance mechanism is implemented.  Ex, If I want to assign a "default" policy of "Enforce GPS availability" and then for a certain subgroup of devices "uncheck" the policy restriction, I can't.  I have to achieve that by other means such as specifically excluding a subgroup of devices from being assigned the "default" profile and supplying a different profile instead.  I can't assign a profile that allows the user to disable GPS ("Enforce GPS availability" unchecked) IF a profile at a higher level has it checked.  If instead of just a check box, it was radio buttons of 'Yes/No/Not Set' then I could assign "Enforce GPS availability - Yes" at the root and at a subgroup assign "Enforce GPS availability - No".  Since the subgroup is at a lower level it overrides the default.  I still have to create two profiles but now I don't have to carve out subgroups when assigning the "default" profile.  It also relieves me from having to remember to disable features when new device groups are created.

Again, I see this isn't available and I will use alternative methods to achieve the goals.

Your suggested three options for each feature control item, namely

  1. No change (Not Set)

  2. enable X (Yes)

  3. disable X (No)

should probably be more accurately described as

  1. Not overridden

  2a. overridden and enable X

  2b. overridden and disable X

The current inheritance mechanism does not provide a "separate" overriding option for "each" item within a payload of a profile, but only support overriding of the whole payload(s) at the profile level using "revoke profile" option for each device instance of interest as described in my previous post.  Whether you need to override one item or more,  you still do the same - clone the original profile to a new one once, make all required changes, revoke the original profile and assign the new profile to the device(s) of interest.

I think having only one overriding control at the profile level is a good design choice because

1. This approach is uniform and applicable to any item types (e.g. enable/disable, dates/date period, number range, boolean, strings, ... etc.) in any payload, and can coexist to support inheritance for rules and advanced configurations.

2. Overridden parameters are all contained in one payload and this approach thus provide a crystal clear visibility and log tracking of profile status for an administrator (Administrator do not need to go to open different payloads/profiles to check what  is the value of a particular overridden item in the right node above).

3. This approach works perfectly together with other properties associated with a profile (e.g.  assignment options such as assignment start/end time & network restrictions, profile permissions and ownership, etc.) and automatic device group relocation (e.g. from alert or device relocation rules) for best-in-class smart device management.  Administrators do not need to waste time to determine why an overridden is not effective on the targeted device because he/she has overlooked that profile some of the items in the parent or upper node with improperly set profile parameters.  

After proper training, many of my customers managing thousands of multi-platform devices in complex hierarchy of device groups for a few years without any maintenance problem or complaints on the inheritance mechanism.  It is just a matter of how much one understand the mechanisms/procedures and use the tool properly.