Skip to main content
Solved

Remove the profile before installing this profile

W
Forum|alt.badge.img+7

Getting this message when trying to apply a second configuration profile to an ipad. Tried on a few devices, all have the same message. 

 

Could it be because both profiles work on different aspects in the "notifications" category? in one case, i allow a notification from JAMF app, and push that out to all ipads. In the second case, i want to limit an application (in this case CLOCK notifications). because they act on the same "group" i cant do it? well that sucks, because i dont want to limit clock notifications on every device in the company, and i want to have jamf notifications showing up how i want them....

 

can someone confirm? thanks

 

 

 

Best answer by bethjohnson

Yes, that's correct: you should not try to divide settings for the same "group" between two different Profiles. 

Find a way to divide your devices, then apply two different Configuration Profiles for Notifications, each with all the settings in Notifications that the particular group of devices needs.

You can put settings for more than one "group" in the same CP, as in your first screen shot, but you may want to consider the good practice of also only setting one group per CP. This would mean having one CP to manage the Lock Screen settings for all your devices, then two more to handle the two different Notifications configurations. The advantages are: easier to see which settings are being applied to which devices, and if you need to make changes to the Notifications only, then you only need to update that CP and its scoped devices, not all devices.

Apple has guidelines around organizing configuration profiles that might provide some useful background:

https://support.apple.com/guide/deployment/plan-your-configuration-profiles-dep9a318a393/web

Note that they (sort of) warn against applying different settings for payloads in the same group:

  • If you have multiple configuration profiles containing similar payloads with different settings, the resulting behavior is undefined. On an iPhone, iPad, or iPod touch, if there are conflicting restrictions, the more restrictive one wins.
View original
    Did this topic help you find an answer to your question?

    2 replies

    bethjohnson
    Forum|alt.badge.img+10
    • bethjohnson
    • Jamf Heroes
    • 27 replies
    • Answer
    • December 11, 2021

    Yes, that's correct: you should not try to divide settings for the same "group" between two different Profiles. 

    Find a way to divide your devices, then apply two different Configuration Profiles for Notifications, each with all the settings in Notifications that the particular group of devices needs.

    You can put settings for more than one "group" in the same CP, as in your first screen shot, but you may want to consider the good practice of also only setting one group per CP. This would mean having one CP to manage the Lock Screen settings for all your devices, then two more to handle the two different Notifications configurations. The advantages are: easier to see which settings are being applied to which devices, and if you need to make changes to the Notifications only, then you only need to update that CP and its scoped devices, not all devices.

    Apple has guidelines around organizing configuration profiles that might provide some useful background:

    https://support.apple.com/guide/deployment/plan-your-configuration-profiles-dep9a318a393/web

    Note that they (sort of) warn against applying different settings for payloads in the same group:

    • If you have multiple configuration profiles containing similar payloads with different settings, the resulting behavior is undefined. On an iPhone, iPad, or iPod touch, if there are conflicting restrictions, the more restrictive one wins.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"You do not rise to the level of your goals; you fall to the level of your systems." James Clear
    W
    Forum|alt.badge.img+7
    • wifichallenges
    • Author
    • Valued Contributor
    • 87 replies
    • December 13, 2021
    bethjohnson wrote:

    Yes, that's correct: you should not try to divide settings for the same "group" between two different Profiles. 

    Find a way to divide your devices, then apply two different Configuration Profiles for Notifications, each with all the settings in Notifications that the particular group of devices needs.

    You can put settings for more than one "group" in the same CP, as in your first screen shot, but you may want to consider the good practice of also only setting one group per CP. This would mean having one CP to manage the Lock Screen settings for all your devices, then two more to handle the two different Notifications configurations. The advantages are: easier to see which settings are being applied to which devices, and if you need to make changes to the Notifications only, then you only need to update that CP and its scoped devices, not all devices.

    Apple has guidelines around organizing configuration profiles that might provide some useful background:

    https://support.apple.com/guide/deployment/plan-your-configuration-profiles-dep9a318a393/web

    Note that they (sort of) warn against applying different settings for payloads in the same group:

    • If you have multiple configuration profiles containing similar payloads with different settings, the resulting behavior is undefined. On an iPhone, iPad, or iPod touch, if there are conflicting restrictions, the more restrictive one wins.

    Well wish it worked like group policy where its all additive on additional settings but of course macs have to "think different" sigh... just means i have to duplicate settings. I like having overarching policies that span for instance, all devices, rather than like 10 policies all with mostly duplicated settings. Anyways ill survive. thanks for confirmation.

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings