This will definitely come down to personal preference so I do recommend you experiment with different configuration combinations in order to define your own philosophy. For me personally I like to have things broken out into separate Profiles so that I have modularity and control over filters and assignment. Say for instance I have two device models in the same environment that need an app installed. My preference is to have one Profile containing a Package for that app and to update that one Profile that I have assigned to both device models rather than having a large monolithic Profile per device type which would then require an update to two Profiles in order to update the app version. There are however advantages to the large Profile approach such as a simplified visual understanding what constitutes a device "image" as well as more control over Package installation sequence.

I am also a big user of the folder structure and inheritance. You have to be thoughtful in your folder structure and determine the centricity of your folders to plan them out before getting too far down the wrong path because it can be difficult to change once devices are enrolled and Profiles are assigned. 

Hi Adam,

Best practice is often a combination of arts related to personal preferences, and science based on reasonable engineering senses.  

With many possible use cases and different angles of considerations,  I can actually write two or three chapters on this topic if I write a book on Soti MobiControl or MDM/UEM in general.  I can share in here some general principles related to what you mentioned, which I have been recommending to many of my own customers over the years

1. While one can ignore MobiControl device group hiearchy & policy inheritance as in many new MDM solutions on the market,  I strongly recommend using this feature together with "profiles" smartly to maximize policy reuse, device group visibility, division-of-labour by multiple IT teams, enhanced capability of some advanced MobiControl policies.

Although MobiControl supports a maximum of 20 levels in the hiearchy, most implemenations need 3-5 levels in practice.  The dimenions worth CONSIDERING (e.g. if it requires variation in policies) includes

- organization structure / geographical locations;

- device owner's POST/LEVEL, or device's USE (e.g. dedicated devices in training room only for shared use by course participant s)

- device owner's ROLE(S) or involvement in particular PROJECT(S)

etc.

There may be conflicting requirements for different factors above, and layering/arranging them properly to maximize policy reuse/flexibility or other criteria is definitely an art.  Besides, MobiControl also requires a device to reside in only one single physical group in the hierarchy at any time.  Please note that Mobiconflicts.Control "virtual group" and "custom attribute filter" can be used together to resolve most of the conflicts.

To maximally reuse policy and minimize assignment effort with the inheritance feature , any policy should be assigned to the HIGHEST possible node in the hiearchy.

2.  As MDM policies relevant to a particular person/role/device/project likely need to be refined gradually, it is almost always not advisable to put all payloads in one SINGLE payload, except in extremely simple implementation with very small number of devices or policy variations.   However, it is also not advisable to have one payload in a profile.  Group profiles SENSIBLY to minimize assignment/re-assignment effort and maximize re-use to different users/groups/devices.  

"Antivirus" and basic "feature-control"  for "disabling factory reset"  payloads are likely universal to every person/device in an organzation and can be be included in a BASE profile to be assigned to the root node(s) once.  Any subsequent policy refinements (especially lengthy ones such as adding false positive app whitelist) only need change/maintenance in one place.   

However, MULTIPLE Wifi payloads for networks in meeting rooms in one office may need to be  grouped in ONE location-dependent  profile and assigned to level-2 or level-3 nodes based on country/state/city etc.  in which an end-user/device is located; OR based on custom attribute(s) added to a device based on its expected work location(s).

Similarly, apps (.pcg packages or app from  managed Google Play store) can also be grouped SENSIBLY to reduce assgnement or maintenance (upgrade, appconfig parameter configurations, etc.) effort and maximize re-use, 

However, each MISSION-CRITICAL corporate app may need to be deployed in a single  independent policy (profile or app-policy/app-catalog-rule)  to ensure that it can be independently maintained when problem arises, and it is not affected by maintenance/debug of other apps deployments if such other apps have been grouped for deployment in the SAME policy.  The last point  make senses if one considers revoking and re-deploying a profile/app-policy/app-catalog-rule as a last resort to fix/debug some app deployment issues.

Maybe I should stop now.  So much for one post.

Hello Adam,

Thanks for your post!

As Raymond and Matt have explained this is really down to personal preference or it would really depend on the use case(s). Was all the information provided helpful? If not, let us know if there is anything that needs clarifying.

Regards,

Technical Support | SOTI Inc. |1.905.624.9828 | support@soti.net | www.soti.net |

@Adam: Even it was still posted that it's on personal preference, i have some things maybe to think on:

If you put all configurations in a single profile, you have enroll the entire big profile including all data even you have just a small change in it. But if you seperate profiles you send only the data of the part which have changed. (easier change handling, less data traffic)

Even if a part of the big profile fails, the entire rest of the profile could fail and on a "reinstall" you again send the entire profile to the device instead of the only failed one. If you seperate each, all single profiles will be installed and only failed ones won't and are able to be reinstalled instead of the entire one. (easier error handling, less data traffic)

But it can make sense to put profiles together. For example the Authentication profile with the kiosk mode profile if used or all Wifi profiles if you have more than one etc..

So, my recommendation is to in general use single profiles but think of ones belonging together.

Hi All,

My apologies, I had not received notification of these replies.

Your detailed answers are very much appreciated and will certainly take all of these points into consideration.

Thanks! Adam