User Template vs. Configuration Profile in Sierra

Cornoir
Contributor II

Just wanted to see if anyone else is having similar issues to me regarding trying to move to the recommended Configuration Profile management path vs. the old tried and true User Template folder regarding Sierra.
I am finding that Configuration Profile are not 100% effective, they are for the most part doing what I need them to do but they are not reliable enough across the board in Sierra in my tests and am thus forced to rely on what is working which is the User Template (even though JAMF and Apple are trying to steer Admins away from this practice).
As an example for the Apple Finder View Options I want to disable the Show Icon Preview. Using a plist file in the User Template works 100%, however either by making a Configuration Profile in Casper or using MCXtoProfile to make a .mobileconfig file and manually installing it neither will disable the Show Icon Preview.
Some stuff works as a .mobileconfig file and some don't, so I am left with using any and all sorts of mixes and matches to get a reliable system I can hand off to the end users, which is a major pain especially when new versions of software breaks something.
Just wondering if anyone has found a single system that works or are we basically hacking whatever we can to get reliable and manageable systems out to the users.

5 REPLIES 5

SGill
Contributor III

We are seeing near 100% reliability with Configuration Profiles as long as we only use them at the computer level and not the user level.

I don't have as much contact with user-level CP's, so I can't tell you much about their success rates.

I did see one glitch with Docks managed by CP's in that they only worked well if you intended to lock the Dock (not popular with many power-users of course). So for that pref only, I've actually stuck with the UT approach mostly (and even nixed the idea of DockUtil, although many seem to like using that app - I'm sure it works well if you want to go that route).

KoeingTony
New Contributor

I'm in the same boat. My company right now is trying to reimage our Macs up to Sierra, but to do so we need to make sure we have .mobileconfig files that cover all the .plist preferences we want to apply. The problem is that some just don't seem to work at all, like Energy Saver preferences.

gachowski
Valued Contributor II

I'll add on...

We are happy with config profiles, however the transition is a chance to stop and ask why you do what you do... your example "Show Icon Preview' why would you want to block that? Is it really a need to block, or is a left over nice to have because some previous manager requested it?

I have found that if you are compounding setting in to one profile that make troubleshooting very hard and if you are adding a custom profile that has a key in the JSS already the JSS will change it back to it's default. IMO if you custom profile you have to sign it with Apple configurator before uploading it... Is "Show Icon Preview" built in key?

So in short all my profiles are custom with one setting signed in Apple configurator before uploading to the JSS. Yes a lot of work but extra easy to track down issues.

C

Look
Valued Contributor III

For us it is mostly just the lack of ability to let users change things afterwards.
The fact configuration profiles tend to lock settings rather than set the default for them is sometimes problematic, likewise the fact that several settings are combined into one, so you can't lock one particular setting without choosing what you want to lock the other setting to as well.
Until Apple addresses these shortcomings there is probably always going to be some kind of user template / login script / alternative user management required.

KoeingTony
New Contributor

Yes, in our case this is for our public lab computers, so we're trying to lock things down for security reasons. We have managed workarounds for the desktop background (we're just copying the .db file from the computer where the BG is set and putting it on the test computer) and our custom dock (we actually have a working .mobileconfig for that). Still working on sidebar settings and sleep/energy saver preferences, but we're getting there.