Christopher Smith Christopher Smith

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.

Read More
User Experience, Provisioning Christopher Smith User Experience, Provisioning Christopher Smith

Managing modern macOS with old tricks

First, this one is a bit long. Just letting you know that up front. I actually made it shorter than originally intended because it was getting really dense in technical details and example Plists and I don’t think you came here to read a novel. If you did want the novel, I’m sorry to disappoint you. Add a comment and I’ll consider revisiting the very detailed example instructions I had in mind when I started writing. Anyway, let's get to it.

---

Fundamentally, managing macOS involves making decisions that define the user experience. Many of those decisions focus on what the user is allowed to do by defining restrictions. That's important stuff, because macOS is a consumer focused product and the choices Apple offers consumers for their user experience are often incompatible with the requirements of a school or business use.

We have MDM | DDM to bridge most of those gaps, so we can define configurations on our managed Macs that meet business requirements without degrading the user experience. Well, hopefully.

In olden times, before configuration profiles and MDM, Mac admins used Managed Client X (MCX) to define preferences for an almost ridiculous amount of settings. The best thing about MCX was its ability to set a preferred configuration without making it a required configuration. It did that using a tiered policy for setting preferences using 3 options: Once, Often, and Always.

If you set the preference Once, it would be applied one time and could be immediately changed by the user to their own preference. The user preference would then persist.

If you set it Often, the preference would be applied on user login. The user could change the setting while in an active session, but the preference would be reapplied from MCX on next login.

If you set it Always, the preference would be forced and users would be unable to make changes.

There's a lot more to MCX than that, but the concept of how settings were applied is our focus here, because Configuration Profiles apply settings Always. There is no other option. If a profile is applied to macOS that defines a setting, it will be forced and users will be unable to change it*.

*I'm speaking broadly here. Bugs happen.

That's a lot of background to say this: configuration profiles are great if you need to set it and forget it, but they suck for setting a preferred (aka optional) configuration. Defining optional settings requires something other than configuration profiles. There are lots of user experience settings a Mac admin might want to define that are meant to be helpful, but aren’t required.

Want to onboard new users who are coming from Windows, and you'd like to automatically enable Secondary Click on their Magic Mouse so their interaction with the mouse is familiar? Want to disable "Natural" scrolling on the mouse because it's an abomination that Apple insists on enabling by default?

How about setting up a custom Dock so your business apps that are installed during enrollment are easily accessible out of the box?

Even if those things could be done using configuration profiles, would you want to prevent users from changing them if their preferences differ?  Probably not. Most importantly, applying preferred settings before the user logs in for the first time is critical to providing a seamless experience. As a user, there’s almost nothing worse than getting to the Desktop in macOS for the first time only to have a post setup provisioning tool take over and start changing things in front of you before you can even start using the Mac.

So, how do you define preferred settings for your deployment in a seamless way? You use an old school method from the NetBoot days paired with some MDM methodology to get an out of box experience that configures your settings without forcing a user to keep them.

macOS creates user home folders from a template defined by the content in /System/Library/User Template and its localization subdirectories. The various localization folders — and the very handy Non_localized folder that applies to all localizations — each have a /Library/Preferences subdirectory that contains predefined preferences applied automagically™ to every new user created on the Mac. With a bit of packaging and Automated Device Enrollment, we can affect the out of box experience and ensure that a brand new, first user account gets our preferred settings without forcing them.

First, you need to get your Plist(s) assembled. Creating or Modifying Plists is a post unto itself (and I may even write one), so I won't get into that here. Let's just pretend you've already figured out which Plist(s) control the settings you want to define. How do you get them into the User Template so they will be applied for your new users?

  • You need to package them into an Installer package. Packaging is also a topic unto itself, but MacAdmins 2024 had a pretty good primer you can watch here.

  • Your package needs to install your Plist file(s) into /System/Library/User Template/{localization folder}/Library/Preferences.

    • I strongly encourage you to use the Non_localized directory as your {localization folder} choice (e.g. /System/Library/User Template/Non_localized/Library/Preferences) since it will apply to all localizations.

    • Permissions should be rw-r--r-- root wheel for all files you install.

Once you have your package created (and you test it to ensure it puts files where you expect, and you confirm a new user account has the expected settings on creation), you'll add it to your MDM so it can be installed during Automated Device Enrollment. If your MDM is Jamf Pro, you add your package as an Enrollment Package in a PreStage Enrollment. For Workspace One, you create a Bootstrap package. Other MDMs may offer similar options; I'm not linking to them because I don't know their terminology and I don't feel like tracking down their documentation links. I use Jamf, and I am familiar enough with WS One to quickly find their documentation link, so that's what you get as examples. If your MDM doesn't have this capability, ask your vendor why not.

When you’ve added your package and configured your MDM to install it during Automated Device Enrollment, it will install before the first user account is created, ensuring the user gets your preferred settings when their home folder is created from the template. If there's a setting defined in a Plist file, anywhere in the User's Library, you can predefine it with this method and control the initial experience. Using this approach, you can get a consistent out of box user experience that a user can modify to match their own preferences.

In other words, you can set preferences Once using MDM.

Read More
Christopher Smith Christopher Smith

Welcome to the internet, Mr. Smith

For most of my career, I was actively discouraged from posting information on the internet. I’m no longer bound by those constraints, so I’m finally putting my domain name to use. I intend to post here about Apple technology, generally focusing on managing Macs at scale. I’ll try to post things I think are useful for admins and other IT staff who wrangle Macs in institutional deployments. There are lots of other resources doing that already, so I may find myself shouting into the void. That’s ok. This is something I’ll be doing in my copious spare time, so updates may be infrequent.

While I have many skills, website design isn’t one of them. I’m doing my best just to keep it simple here. Making it pretty is probably beyond my limits. You’ve been warned.

Read More