how to exclude or remove unwanted payloads from configuration profiles?

[mallej]

Hello,
i want to use Configuration Profiles > Login Window > Disable Siri setup during login.

My problem is that the the profile also includes payloads that i don´t want.
i.e. i don´t want to configure the LOGIN PROMPT. Neither to "Name and password text fields" or "List of users able to use these computers". Also the user should be able edit the settings in System Preferences on their own.

Is there a way to exclude or remove unwanted payloads from configuration profiles?

[robmorton · Accepted solution]

There are ways of doing it that are are all bad. You can try to edit the text, but if you open it in any GUI editor again, it will change back. These are also not really supported by Apple and they can call that an invalid profile if they wanted to. Your best bet is to go to https://bugreport.apple.com and submit it as a bug. We have many reasons to need granular permissions in the profiles, but so far Apple has not implemented them. Hopefully if more people submit the bug, even if it is a duplicate, Apple will get the idea that what they have given is mediocre at best.

[mm2270 · Accepted solution]

As mentioned above, there aren't many good solutions to this that don't involve mucking with the profile xml, and then locking it down with a signing certificate so when it's uploaded back to Jamf Pro, it won't get modified again. It sucks that Apple doesn't allow for more fine tuned control in Config Profiles. They lump too many settings together into a single payload and this is the result. Settings being applied that we never intended to apply.

One thing I'd like to mention here though - you stated above, "the use[r] should be able edit the settings in System Preferences on their own" If that's what you're after, I would suggest NOT using a Config Profile and instead doing it with a defaults write command, if possible. This will set it once and let the user modify it on their own later. Lots of profile settings end up locking the user out, so I'm not sure you'll be able to meet that part of your requirement with Configuration Profiles. Just sayin'

[robmorton · Accepted solution]

There are ways of doing it that are are all bad. You can try to edit the text, but if you open it in any GUI editor again, it will change back. These are also not really supported by Apple and they can call that an invalid profile if they wanted to. Your best bet is to go to https://bugreport.apple.com and submit it as a bug. We have many reasons to need granular permissions in the profiles, but so far Apple has not implemented them. Hopefully if more people submit the bug, even if it is a duplicate, Apple will get the idea that what they have given is mediocre at best.

[gachowski]

While I encourage you open a issue/bug request.. Apple refused to open a feature request for me and there was more than a few emails about it...

Our best hope for this is to vote this up!!!

https://www.jamf.com/jamf-nation/feature-requests/6281/break-up-multi-mdm-payload-gui-payloads

C

[mm2270 · Accepted solution]

As mentioned above, there aren't many good solutions to this that don't involve mucking with the profile xml, and then locking it down with a signing certificate so when it's uploaded back to Jamf Pro, it won't get modified again. It sucks that Apple doesn't allow for more fine tuned control in Config Profiles. They lump too many settings together into a single payload and this is the result. Settings being applied that we never intended to apply.

One thing I'd like to mention here though - you stated above, "the use[r] should be able edit the settings in System Preferences on their own" If that's what you're after, I would suggest NOT using a Config Profile and instead doing it with a defaults write command, if possible. This will set it once and let the user modify it on their own later. Lots of profile settings end up locking the user out, so I'm not sure you'll be able to meet that part of your requirement with Configuration Profiles. Just sayin'

[robmorton]

@gachowski I would be very concerned with Jamf implementing something that Apple has refused to support. That would end up resulting in Apple making a change and refusing the Jamf profiles or something equally as bad. The fix unfortunately must come from Apple.

[gachowski · Accepted solution]

@robmorton

I strongly disagree!!! :)

Editing and creating profiles is 100% supported by Apple. See :

[https://developer.apple.com/library/content/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html](link URL)

99% of my profiles are custom and contain only one setting.

The issue is from what I can tell Apple is just lazy and using the same GUI layout that they used MCX.

Config profiles are significant different that MCX. Why would the GUI be the same? I would also think that how the Config profiles are created is different for each MDM vendor so why are they all using the same GUI?

The GUI that @milesleacy created in [https://www.jamf.com/jamf-nation/feature-requests/6281/break-up-multi-mdm-payload-gui-payloads](link URL) is the only correct way to "show" config profiles as how they should be used, one setting for one profile. One setting for one profile is the correct way to deploy config profiles, there is no overlap of settings, if your setting requirements change then you only have to change a single setting as apposed to all the settings nested in that profile and if you have to troubleshoot setting it's the fast way to do a spilt half search.

It's time for config profiles GUI to change and Jamf is our only hope. : )

C

PS end rant . : )

[robmorton]

@gachowski Awesome. The label of Optional never use to be there. Now that they are listed as Optional, MDM vendors need to start leveraging that. Thank you very much for that info as now I can start using modified profiles with some assurances.

[mallej]

thanks all for answering and ranting ;). i know now that i don´t misunderstood the gui and that it is as it is.
I will try using defaults write commands, if possible and hope for the vendors to implement better granular permissions in the profiles.

[milesleacy]

If Jamf wants to stick to duplicating Profile Manager interfaces, Profile Manager already has a great interface to support this.

See: https://www.jamf.com/jamf-nation/feature-requests/2013/enhancement-for-manual-config-profile-functio...

[milesleacy]

If you want to vote on the related feature request...

https://www.jamf.com/jamf-nation/feature-requests/6281/break-up-multi-mdm-payload-gui-payloads

[ericbenfer]

This too.
https://www.jamf.com/jamf-nation/feature-requests/6040/select-which-keys-to-enable-and-include-in-a-...