Policies vs. Config Profiles vs. Manifests - any clear lines/practices to follow?

@Taylor.Armstrong Don't use Managed Preferences.

They had a place pre-pofiles, but you'll find their application to be hit & miss.

You can create your own profiles outside of the JSS, upload to it & deploy.

You can also create profiles from plists, via custom settings.

Basically, policies for "installing stuff". Profiles for managing settings.

Policies to deploy apps. Config Profiles for settings!

Managed preferences were used by Apple in OS X 10.8 and earlier. Config Profiles are now used to manage settings on a Mac.

The only problem with Configuration Profiles is the teeny tiny window in System Preferences, where techs end up calling us because they can't see the whole name of the item. Apple needs to provide a more usable interface to the list of Configuration Profiles on a Mac. App_Security?_Level convention, for example, Safari_MSB_Computer naming convention helps. MSB = minimum security baseline.

Hey @donmontalvo

Get the techs to open up System Information.app from the utilities folder. Go to "Software" > "Profiles" and it lists the installed profiles' full name and what it manages : )

Darren

I've tried to manage settings for the mouse natural scroll and hiding the Wifi menu when a user logs in via a profile and can't see how to do it. I ended up using the managed preferences but I have to say, sometimes it works, sometimes it doesn't.

Thanks all. Basically backs up the advice from the JumpStart (especially that last comment about managed prefs being flaky, which is what I'm trying to avoid).

Any conventional wisdom on structure? AKA - if I have a couple of dozen settings, from all different areas... is it better to try to combine these into one "Master" profile, or split them up? Any reason to avoid having multiple profiles? Again, I'm configuring everything from screen saver policies to some 3rd party software (MS Office), just trying to sort out where the boundaries lie in terms of logical organization.

Best practice is always to split them up, not have one huge profile with everything in it. That way you can selectively change individual items in your overall management policies without needing to re-push an entire profile with all settings in it at once.

Also, the OS can handle multiple profiles in the same way its able to handle many individual MCX settings in the past. Its not an issue to have many of them. But come up with a sensible naming convention for them so they are easy to recognize.

@daz_wallace awesome! I still think Apple can do a better job of providing a usable way to manage things when the list of Configuration Profiles grows.

Apple can also do a better job providing information/guidance on how to manage things when there is a need to split things up, composite profiles, etc.

Scrolling down this URL, there's some information out there but you've got to really dig to find it. :(

Don

This is "key" when building profiles.. .too

https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html

I feel just like donmontalvo, Apple has to stop screwing around with how profiles are nested and how they are grouped all over the place...

I would settle with just a big straight list of single settings, one setting per profile...

Right now I build all my profiles in macOS server, one setting per profile then I sign it with Configurator so the JSS won't change it... the downside is the you can't see what the profile setting are in the JSS...

C

Thinking about @mm2270's comment about splitting up your profiles - I totally agree. That is until OS X (or was it actually JAMF?) seemed to break if you had certain payloads split (login window and screen saver comes to mind recently). Basically do your own homework and test before turning anything to prod... YMMV

So the title of the question refers to "Policies vs. Config Profiles vs. Manifests" but the text of the replies refer to "Policies, Config Profiles, and Managed Preferences (MCX)". Are package manifests and managed preferences the same thing? I know that managed preferences have been deprecated. I opened up a package manifest and it's written in XML, same as a managed preferences. I looked at JAMFs online directory of Package Manifests and haven't much activity in the last couple of years. In Composer, when I try to update manifests I get a 404 error. On the other hand, JAMF's latest documentation still mentions package manifests.

Seth

@SVM-IT, the word "manifest" as it relates to Apple has had a couple of meanings.

Today, Apple and Jamf both use it to mean "a list of contents". For Jamf, a package manifest is a list of package contents and you can export this list to a .composer file for use with Composer n a different Mac.

Full disclosure, the rest is fuzzy memory...

"Preference manifests" are legacy and I don't see any on my Mac anymore. But if someone had taken the time (Apple did this for a handful of its own items) you could peer into the contents of an app bundle and find a .manifest file. It looked very much like a .plist preference file that we're use to dealing with for configuration profiles. However, it contained only a list of useful keys/values for managing the app and an extra line for each one describing in plain English sentences what it managed.

In the days of Workgroup Manager, which was the tool for managing Managed Preferences (MCX) before Profile Manager, an administrator could drag an application onto the tool and it would find and import the manifest file. The administrator could pick and choose which preferences to manage and set their values. This was much easier than what we have to do today, which is rely on our own search of .plist keys/value and Google.

Jamf endorsed an open source project back then started by AFP548.com called Manifest Destiny, which was suppose to be a shared repository of .manifest files for administrators to reference and download for Apple and third-party applications. The only problem with the project was that it was ahead of its time. Only the geekiest of Mac admins understood the purpose of manifests and were even using Workgroup Manager for managing preferences. And creating the manifest files with the descriptions of each key/value was something done by hand. No tool existed (that I knew) for making this easy.

If I need to deploy or add the mac os latest version into the jamf pro, how can I add it? Is there by adding under the policies or configuration profiles? Can you please explain me about this?