Config Profile with settings not uploading correctly

[Hosler]

So I am download this profile from https://fsassessments.org/

The profile does the following
• disable Hot keys for enabling Dictation, Mission Control, and Spaces
• disabke Trackpad gestures for accessing Lookup, Space Switching, Expose, and Notification Center

However, when I upload the profile into Jamf Config Profile, the settings are empty, but the right number of settings is added. See attached image

Any suggestions? Is this a formatting issue? JAMF bug?

When I install the profile directly onto the computer it works.

[mm2270]

@Hosler I'm glad you posted about this. I have seen similar behavior and was planning on getting in touch with Jamf on it, or posting here about it. This seems to be a side effect of the new Application & Custom Settings payload being reworked as happened a few versions back now. Prior to it changing, if I uploaded an existing .mobileconfig file to Jamf Pro it would read it in as Custom Settings item and show the values assigned statically in the profile. But now, it sees it as something to import into the Application & Custom Settings payload, but won't show any of the settings. What should happen is it should import the .mobileconfig as having the "Upload File" option selected and read the values from the profile itself, just as it used to, but it instead flips to the Configure Settings option and then doesn't really read in the values.

In my tests what I found is if you simply click Save after importing the profile and don't touch anything, and then download the .mobileconfig profile from Jamf and read it back into another app like BBEdit (after stripping out the security from the file), NO settings are being applied, so basically Jamf Pro is messing up the custom configuration profile by stripping out the values. IOW, what you see in the GUI is what you end up with in the actual profile - a wrapper profile with no actual settings in it.

When I first encountered this, it was with one of @pbowden's custom .mobileconfig profiles that he hosts on his GitHub for Office applications. It was something that wasn't included in the Jamf repo for Office. I at first thought Jamf Pro wasn't reading it properly because the domain it was using was one that Jamf was already managing, but I later tested it out with a custom profile I made for some entirely unrelated application domain and saw the same behavior.

I would say this is a bug and not intended behavior, since I can't imagine Jamf actually intends for this to happen, but I can't be 100% sure about that. Maybe someone at Jamf can chime in and look into this.

For now at least, the only way I've found around this is to replicate all the settings in the profile into a local .plist file using defaults with the correct domain and then uploading it to Jamf using the "Upload File" option. While I was able to do this for one of the profiles that I saw this issue with, because it only contained a couple of settings. I can't imagine doing this for a more complicated profile that contains dozens of keys and values and nested settings. It gets messy and ends up being an unnecessary duplication of effort that is error prone, since you already have a perfectly good working profile to use that has everything you already need in it.

[sdagley]

@mm2270 Is this happening with signed .mobileconfigs that are uploaded as well?

[Hosler]

@mm2270 Thanks for the response. I planned on making my own plist to create the settings I was just hoping I was missing something.

@sdagley The profile I have is unsigned. So im not sure about signed profiles

[sdagley]

@Hosler Thanks for the update on the signing state. Jamf Pro has a long history of munging uploaded profiles that aren't signed, and this looks like a new way to do the wrong thing.

You would hopefully have better luck signing the .mobileconfig before uploading it. Here's a useful article on doing that if you don't already have a workflow for signing: Signing Configuration Profiles - see the section titled "Signing Profiles for Trust Only by Jamf-enrolled Clients" since you're using Jamf Pro

[Hosler]

Thanks @sdagley , I signed it, tried to upload and got the same result. Only this time it says it is ready only because it it a signed profile.

[mm2270]

@Hosler are you sure you signed your profile correctly? Because I also went through this exercise and my results were different. After signing the same profile you referenced above in your first post, and uploading it again, it does seem to retain the settings. You can't really modify them of course, but that's actually no different than how it used to be if you uploaded a plist file with settings in it.

Here's a screenshot of one of the items in it after being uploaded.

So it does seem like Jamf Pro is messing up the uploaded profile unless you protect it from mangling it. Like @sdagley mentioned, this is just another version of it doing messed up things to profiles that it should not be doing. I wish it wasn't necessary to sign custom .mobileconfig profiles. It wasn't a strict requirement before unless you made a profile that excluded settings that Jamf had in one of the built in payloads, like with Security & Privacy > Firewall for example, and you didn't want Jamf messing with it. But now it seems to be required even for profiles that don't use any of the existing built in payloads.

[Hosler]

It won't let me attach the compressed zip file, so here is a link to it in my dropbox. https://www.dropbox.com/s/kf5yqfmcw23lifk/JAMFSoftwareServer.log.zip?dl=0