iPad Config Profile: Best Practice?

steve_summers
Contributor III

Hello all.  We recently had some transition on our team and iPad management within Jamf has fallen to me. In looking some things over, we have 1 iPad configuration profile with 101 settings.  To me, this doesn't seem desirable.  In the Mac space, you want to spread out your configuration settings via multiple profiles instead of one.  

Anyway, can anyone confirm before I go making changes to it if that is or is not best practice with iPad management?  If it is, great, I'll move on to other things.  If it's not best practice, well...I have some work to do.

 

Thanks. 

4 REPLIES 4

jpeters21
Contributor II

having 101 settings in a single profile is not best practice. If you have done it on the computer/mac side you already know what you have to do 

evaldes
New Contributor III

@steve_summers You're fine with 101 settings... the JSS can handle that... I have config profiles for iPads that have 145 different settings... The goal is to break the settings apart... one for base configuration, and then you add on top on other configurations.  I use Jamf Setup & Jamf Reset, and use the role feature to assign the configuration to the iPad.  You empower the user to choose their "department/clinic/configuration".  I believe Jamf has updated this to leverage Azure now.  Just a little bit of configuration on the app configuration and you're good to go!  I have deployed about 1200 mobile devices on my own... as long as you are organized and describe each configuration profile.. you should be good to go.

timbyler1890
New Contributor III

There is a lot that I don't know about your use case and that makes it harder for me to give you a real good answer. There is no doubt that Jamf and iPad OS can handle a profile with 101 settings, to me the bigger question is should you do it that way. 

You know that you have a good IT team and well crafted policies, when you need to work on a device and the user doesn't experience any disruption. This is still a goal that I'm striving to reach but it has been a good guiding principal when I'm trying to setup policies.

I don't think any one questions if it can handle 101 settings, it definitely can.

Every time you change a setting in a config the whole config redeploys, so even though xml files are not exactly huge, if you are interested minimizing the amount of traffic over the wire this helps. 

Second reason is just flexibility on the assignments, breaking  down into security, energy saver, restrictions, ect.  allow more freedom in assignments and easily changing a given setting for any specific group if needed. Obviously if your environment doesn't have groups with different requirements that one wont matter to you. 

That said, I know people that try to make the console look "clean" with as little as possible in the console .. but I have no problem telling them they are wrong 😋