Moving from User template to outset

The impression I have is that Apple expect configuration to be delivered primarily via Configuration Profiles from the Mobile Device Management system of your choice. From a recent chat the push was that the application should be in a package (if possible the vendor package) or delivered via volume purchase (now just apps and books), configuration could be delivered by a LaunchAgent and associated script or via a profile.

We stopped using the user template folder when we moved to Jamf / Apple introduced SIP, it really hasn't been much of an issue. I think the leap you need to consider making is separating the application from the configuration...

If everything in your deployment is set on the User Template I would start by making a list of all the settings/items you would like to enforce and curate for your users. Then, based off that determine what can be accomplished with a configuration profile or a Jamf policy. What's left over can go into the "outset bucket."

I don't know of any specific concerns Apple has with outset, but my guess is that they can't officially recommend a product that doesn't have an official support channel. Aside from configuration profiles and Jamf policies, some of the functionality that outset gives you can be provided by Munki. A brief glance at the outset Github repo shows it hasn't been updated in a bit, that might also be their concern.

Thank you @sshort and @dsavageED for your replies.

My guess is the same, Apple can't officially say something is supported if they don't have the pieces in place to actually support it. My packages tend to be the bare minimum to get things installed and functional. With that being said, I want to configure things like auto update being disabled and registration items. Many of these however don't have the prototypical .plist file that can be converted over to a configuration profile.

As it is, about a third of my packages have user templates in place. A third of those have been moved to outset. All of my testing is being done in Mojave to verify compatibility for our summer deployments. I will continue to explore the configuration profile piece. The only draw back to the configuration profile is a user can't over ride the profile. For instance, if we disable the auto update function, it might also disable another setting that a user may want to change.

Again, thank you for your replies.

On a Mac the Configuration Profiles can have Custom Settings, this is just an uploaded plist, so you can only set the settings you care about and let the user change those which you don't.

Hey @dsavageED this is an interesting take. I wasn't considering the option of modifying the .plist with ONLY the settings I needed adjusted, like disabling auto updating while leaving the other features not touched, thus allowing the users the ability to modify. Does this work? If the .plist was modified/created using a configuration profile, can a user modify other items that are written to that .plist?

@mconners You're right that a downside of most config profiles is they don't allow the user to make changes after the fact. The dock payload is a good exception, b/c you can allow the users to make changes down the road.

As @dsavageED suggests, the custom plist route can be helpful. If the specific key is not set in your plist when it's uploaded, it won't be locked down. So users can freely adjust any of the settings not contained in the plist you upload to make the custom profile.