How to work with configuration profiles

For a lot of people, this might be common sense. But it might be new and useful when you take over a Jamf Pro instance in a company where the main admin on this instance left before he was able to pass along all the info. Sounds weird? Well, it happens more often than not.

2 months ago   •   3 min read

By macstuff
Table of contents

Organizing profiles

There are a few organizational tricks that I want to share with you. For example, the use of categories and separating every payload into its own little configuration profile. These are all things to make your life and the life of your users much easier. See below a great starting point for categories:

  • Applications
  • Security
  • PPPC
  • System Extensions
  • Preferences
  • Notifications
  • Network
  • Scripts
  • Jamf Connect
  • Jamf Protect
  • Testing

The fun part about that is that if you categorised everything you can collapse or expand with one click of a button. If you're working on a configuration profile for Jamf Connect it's easier to keep track of that profile without the entire list of unrelated configuration profiles.

In my experience, sorting categories makes life so much easier! Even better, when you decide you need one of these configuration profiles in Self Service it will show up there under the right category. Can't recommend it enough!  

Working with payloads

Now, what if you say, but I only have 1 or 2 configuration profiles! Maybe you have one of these profiles in your organization:

Sounds pretty vague and the person who created it knows exactly what is going on. However, there are a few complaints about this, for one - if we open it and we see something like below, that can make your life a real hell!

There are a few reasons why you should not do this.

  1. Changing anything in this profile is a nightmare, you need to push all the payloads again and it's impossible to put this profile in Self Service if you may need to do so.
  2. Identifying issues with one specific payload is much harder than it's supposed to be.
  3. There is a higher chance of the configuration profile failing to install due to one small mistake resulting in all payloads failing to install.
  4. Some profiles require OS-specific changes
  5. Creating small differences in the restrictions payload needs a full clone of the entire profile if you do not want to change it for the bigger part of the organisation

The last point I see a lot as of late, users complain about certain functionalities not being present and the configuration profile gets cloned for a very specific user. Because of this, if you want to update a certificate or make changes to the network payload you have about 10 places where you need to change everything.

My advice and rule for keeping everything healthy and easy to work with are to have 1 payload per configuration profile. There are certainly some exceptions to this like having a SCEP payload or a certificate payload together with your WiFi payload, this is required to trust the deployed certificate.

One other reason to combine multiple payloads into one is if one application needs PPPC, System Extensions, Content Filter, Notifications. But do it per application, try to refrain from adding different applications into those profiles. You can call it just by the name of the application.

Also, the last point, this makes it much easier for support if you ever have a question about configuration profiles. ;)


Naming profiles

Continuing on the thing I explained above there are a few things that I personally always do. Because most of the profiles you create are either one for the entire organization, (Like Restrictions, Security and Privacy) or are for multiple apps.

To talk about PPPC for example. You have the ability to make multiple payloads in one configuration profile. You have a single profile that tells you "PPPC" or "Privacy Preferences Policy Control". In my experience, making a single configuration profile per app is the best way to get good visual control over your profiles. For example; I always create my profiles like so:

  • "PPPC - Sophos Endpoint"
  • "PPPC - Cisco AMP"
  • "PPPC - TeamViewer"

And I basically do this for Notifications, System Extensions, Kernel Extensions, anything that might come more often than once. This makes it so that if you have to make any changes to the profile you don't redeploy the entire profile with all the payloads to everyone twice. Pair that with the categories and you have a beautiful Jamf Pro instance!


Something you want to see? Something you want to know? Email me at [email protected] and I’ll consider it!

Feedback about my site or content? Contact me at [email protected]

Spread the word

Keep reading