Profile hierarchy question

Profile hierarchy question

I have a question on profile hierarchy within MC, if that even exists.   If there are 2 profiles assigned to a device with a feature control set oppositely in each profile, which setting will be the active setting?


For instance, I have a default profile that gets assigned to all devices with certain features we want across the board for our standard deployment.  One of those feature control settings is to not allow OS updates.  I have a device in the field where I need to update the firmware so I was wondering if I could push out an additional profile to allow OS updates and that would over-ride the other profile's setting of disabling it or is it just whichever one gets assigned first?

I don't really want to revoke the default profile as there are a lot of other settings, etc... that I want to remain active.

3 Answers

Order By:   Standard | Newest | Votes
Matt Dermody | posted this 20 September 2021

You will likely run into a conflict by applying two different Feature Control based Profiles to the device. To handle this situation you can clone the existing Profile and make the change that you'd like and then apply that specifically to the device in question. You may want to create a new folder/group and apply the modified version of the Profile to that group and then unassign the current Profile to that group so that you can freely move devices between the groups in order to toggle that setting on and off. 

  • 0
  • 0
Ozan Acikalin | posted this 21 September 2021

When you have one profile installed and install a second one then the second one will expand the first
profile with his settings. The first profile keeps always all his settings. So the second one wont be able
to allow OS updates or other settings from the feature control configuration.
You will see on your webconsole that the second profile will be installed partially because it wont install
the feature control configuration but other configurations like application run control or bookmarks.

Like Matt already recommended you should exclude your device from your default profile and assign
a clone of your default profile to only your device. Like that you can edit the cloned profile freely and
dont have to worry about the other devices.

  • 0
  • 0
Raymond Chan | posted this 24 September 2021

The nswer is device-platform dependent.


On the system level, Apple has very brief document on how iOS firmware resolves MDM policy conflicts, and Google do not seem to have any such documentation.  Even so, the Apple's description is not very informative. 


On the Soti MobiControl level, the situation is a bit more complicated, as some profile payload can be instantiated/deployed more than once by design and some cannot, but multiple MobiControl profiles with the same payload-type of conflicting settings may be targeted to the same device. 


If the payload types support multiple instantiation (e.g. Wifi) by design, then multiple payloads from more than one profile can all be successfully deployed, and there is actually no conflict and the extra parameters in subsequent payload(s) can be considered as simple "logical-OR or logical-AND" to the existing ones.


For some profile payload types that only make sense for single instantiation (e.g. "Authentication"),  whenever a payload has been successful deployed with a profile, another profile with the same payload type will not be able to be deployed, and have status "failed" for the correponding payload".  Thus, it is a "first-come-first serve" conflict resolution strategy


However, some other profile payload types (especially on Android device platform)  may have parameter that only make sense to be instantiated once.  If addtional profile of the same type happen to be able to be deployed successfully on a device, then it is likely that the settings from the last profile successfully deployed take effect.  Thus, it is a "most-recently-use" strategy for handling conflict in this case.  So, two devices in the same device group may have different settings if the conflicting profiles are deployed in different order.


Because of the complication and uncertainty mentioned above, when attempting to maximize reuse and reduce MDM administrative overheads, any partitioning of payloads into multiple profile for each device should be carefully and systematically planned to match factors such ascorporate workflow, organization structure/location, administrative hierarchy, etc.


  • 0
  • 0

Give us your feedback
Give us your feedback