Zen and the art of configuration profile management

On the surface, managing a Mac (or Windows) deployment at scale doesn't seem like a philosophical pursuit.  You create some settings, you apply them to computers, then lather, rinse, and repeat.  Nothing complicated in that, right? Right?

If only.

When you need to manage settings for thousands of devices, there's very little chance that you'll only need one group of settings for every endpoint.  You'll need two, or five, or a dozen, or some number that you could determine with probability theory if you are a mathematician.  I'm not a mathematician.  But, knowing that I need to manage a large number of devices that will have multiple variations in their configurations means I have to spend time deeply considering where those variances are likely to occur and build my processes accordingly.

For macOS, managed settings are primarily delivered via MDM configuration profiles.  Apple is slowly phasing in new Declarative Management capabilities with plans to fully replace configuration profiles in the not too distant future®, but managing Macs in the present still relies on configuration profiles for more than 90%* of the heavy lifting.  A big part of the pain and suffering that comes with configuration profiles is that they aren't logically grouped by their effect. What do I mean by that?  Let me give you an example.

Virtually every Mac admin needs to manage macOS Software Update settings in some capacity. I know, I know, Software Update was practically the first thing Apple added to Declarative Management, but bear with me because it's a good example anyway.

Software Update settings managed with configuration profiles are split into multiple payload types.  First, there's the com.apple.SoftwareUpdate payload that defines a group of settings primarily focused on whether macOS automatically checks for and installs updates.  Then, there's the com.apple.applicationaccess (more commonly known as Restrictions) payload where settings related to update deferrals are configured.  Logically, these are all Software Update settings and they should all be delivered in the same payload.  But they're not.  Sure, MDM vendors could take it upon themselves to logically group all of the relevant key-value pairs into a single "Software Update" section so a Mac admin can easily configure all the Software Update things in the same place at the same time.  Most don't.  Most MDM vendors group key-value pairs exactly how Apple groups them: by payload type.  So, to configure all the available Software Update settings for macOS using configuration profiles, the Mac admin needs to know that some of the settings are in one payload and some are in another, and now it's complicated when it shouldn't be.  The good news, of course, is that Apple has corrected this particular pain point in how they implemented Declarative Management for Software Update. All of the Software Update settings are logically grouped in DDM.  It's a great start, and I hope they keep doing it as they continue migrating MDM management to DDM.

Of course, I could also write an entire post about how the com.apple.applicationaccess payload is basically a dumping ground, but that should be apparent to anyone who actually looks at the key-value pairs it contains. iCloud settings that should be their own payload, a Passcode setting that should be in the Passcode payload, some actual application access restrictions, a Time Machine restriction that should be in the Time Machine payload...it's just a goddam mess at this point. But I digress.

If Software Update settings are a good representation of how fragmented managing settings with configuration profiles can be—and that's for something built into macOS—what does that mean for managing application settings, especially 3rd party applications that need to interact with various macOS security measures that limit access to the filesystem, devices, etc? How many payloads might I need to configure for a single app in order to get it deployed and configured with a "desired state" on my macOS fleet? Here's a few possibilities:

com.apple.servicemanagement — needed if the application has a LaunchAgent|LaunchDaemon that I want to  automatically enable|allow

com.apple.system-extension-policy — needed if the application relies on a System Extension for some functionality

com.apple.TCC.configuration-profile-policy — needed if the  application requires access to any  TCC services

com.apple.webcontent-filter — needed if the application monitors network traffic

com.apple.vpn.managed — needed to configure a VPN app

com.apple.extensiblesso — needed to configure an extension that performs SSO|PlatformSSO

com.apple.notificationsettings — might be needed if the application delivers notifications in Notification Center

In addition to those, applications that follow Apple best practices configure their settings via key-value pairs in a  Plist, which in turn can be deployed via a custom payload definition if the MDM and app support that.

So, configuring an app will almost certainly need several payloads to get it deployed and pre-configured on Macs in a way that just works™ as far as users are concerned.  Not complicated at all, no ma'am. Now extrapolate those possibilities to multiple apps, each with its own configuration requirement. Then, consider what happens when Apple adds some new key-value pair or introduces an entirely new payload that needs to be applied to multiple apps.  Got all that in your head?  Good. Now for the fun part.

As an admin, do you create a new configuration profile for the new payload and include settings for every app that needs to be configured?  Or, do you add the payload and its key-value pairs to the "App Settings" profile for each app that needs it and redeploy the updated profile(s)?  You do have an "App Settings" profile for each app, right?  You didn't get sucked into having one Managed Login items profile that has every security agent, content filter, and compliance tool in it, right? Or one System Extensions payload that's just a list of all your allowed system extension Team Identifiers because that's what made sense at the time?

Alright, what point am I trying to make? I think it's this:  managing Macs with configuration profiles is complicated enough when the only consideration is the inevitable variation in your business requirements.  The general lack of logically grouped management settings in configuration profiles makes it even harder to build a consistent, scalable management framework an admin can easily implement and maintain.  And I haven't even mentioned how much worse it gets when your MDM provider includes every possible key-value pair in a payload instead of only including the ones being changed from the macOS default values...sigh. Whatever your MDM, however many Macs are in your deployment, you need to have a plan for how you manage them.

You can manage your Macs from a payload-centric view where you build a profile with a single payload type containing a bunch of settings for different apps, or you can manage your Macs from an application|process|function-centric view where you build profiles comprehensively to provide all the payloads and settings needed to achieve the desired state of the application|process|function itself.  But before building or deploying anything, ask yourself:

• Which of those approaches makes sense today?

•  Which is more likely to scale as the deployment grows and business requirements change?

I may not know the answers, but asking those questions and deeply considering the impact of my decisions before I make them seems pretty philosophical to me.

* I'm not a statistician either; I pulled that number out of thin air.  I feel confident  about it, but I didn't sit and count all the ways and means for managing every configurable setting in macOS.