One of the issues Mac admins have with OS X’s Configuration Profiles system is that using OS X Server to build a Profile allows only subset of the management “scope” that is provided using MCX / Managed Preferences. Specifically, any configuration profiles made with Profile Manager are the equivalent of using the “Always” setting in Workgroup Manager.
Workgroup Manager also provided a useful interface (the “Details” view) for modifying exactly which keys are managed, and at the “Once/Often/Always” levels. This meant that one could take an existing set of preferences for system management and pare those down to a subset that can be assigned to a distinct “settings group”, which can then be included by other groups/computers, either using Open Directory or a custom Local MCX deployment. For example, the loginwindow could be configured with a setting that’s standard for every machine deployed, and then another group configured with some additional settings that are more specific (perhaps different user listing settings, text instructions for lab machines, etc.). The ManagedClient subsystem on the client would then “composite” these settings on the client and apply them all, with some precedence based on the type of record and/or group inheritance.
Anyone that has opened up an unsigned .mobileconfig file in a text editor has seen that it’s a plain XML plist, which contains at some level a layout of familiar plist MCX keys, in a slightly less familiar arrangement. And, it would seem that much of the underlying mechanisms are the same as well. Server’s Profile Manager contains a “Custom Settings” payload type that is similar to the “Details” view of Workgroup Manager, where individual keys can be edited for a given domain. Only thing missing here is the Once/Often/Always management level. That is one mechanism that still remains usable on the client, which is possible to take advantage of if you build these payload profiles using mcxToProfile, a utility I wrote to ease the process of generating Custom Settings Profiles. Using mcxToProfile, you can create a profile for managing preference domains that were previously only manageable using the Once or Often levels. All pre-Lion MCX caveats, such as the clobbering of user preferences when pushing updated “Once” settings (wherein timestamps are compared and stored in
com.apple.MCX), still apply.
Profile Manager, besides not having a way to define anything as Once/Often, also doesn’t have an interface to tweak/add/remove individual plist keys for the profile you’re editing (except for the aforementioned Custom Settings type). So, if you’re editing preferences for a login window payload type, save, download and open it in a text editor, you’ll notice that you’re left with a profile that pushes all settings configurable in this payload type. Without going any further, you might see this as demonstrative of Apple’s overall approach with their reboot of OS X Server: simplicity at the cost of large-scale manageability and sophistication. Nice for a small firm of 10 employees, perhaps less so for 1000 employees. You might assume that the ability to download, distribute and install profiles using methods that don’t involve device “enrollment” may come at a price of reduced flexibilty. That is, not being able to apply profiles as atomic groups of settings that can be mixed and matched, like many people did (and do) using MCX and Workgroup Manager and deploying them with OD or other means. If so, I think you might be on the right track. We’ll look at an example further below that may test this theory.
While mcxToProfile only builds Custom Settings payloads, because this type seems to directly wrap existing MCX mechanisms, it stills seems possible to use the Custom Settings type to manage most, if not all, preferences that have their own “types” in Profile Manager (ie. Login Window, Mobility, etc – mostly all from the old ‘Preferences’ section of Workgroup Manager). That said, it’s clearly not the way Apple intends these preferences to be managed, because they have their own types. So, here’s an attempt to explain how payload types are represented in a profile, without much of a deeper understanding of the profiles subsystem.
Below is the
PayloadContent key from a .mobileconfig file with a “Software Update” payload configured. The
Payload key names are specific to the profiles subsystem. Of interest here is the
PayloadType value of
com.apple.SoftwareUpdate, and the key Profile Manager lets us configure, the
And here’s the same key from one with a Custom Settings payload configured, with the same preference domain and key. If you’ve ever looked at the plist contents of MCX computer records the data within the nested
PayloadContent should look familiar:
We can see that “Custom Settings” is just its own dedicated type of com.apple.ManagedClient.preferences, that contains a nested dict of MCX plist data. Both seem to work when installed using the command:
profiles -I -F /path/to/profile.mobileconfig.
So, how do these preferences work if we’d like to install multiple profiles that manage the same domain? And how would it work if the client machine were enrolled via Profile Manager as an MDM service? We can prepare a couple test cases. Let’s use a couple simple Finder preferences for one case: two profiles, each with a “Forced” boolean value of ‘true’, one for the
ShowHardDisksOnDesktop preference and one for the
ShowMountedServersOnDesktop preference. You could substitute these examples for something more applicable to your environment.
To test using Profile Manager, I’ve got a test system running Server and Profile Manager configured for Device Management, and have also enrolled it to the service as an MDM client. I’ve made one Device Group for each Finder setting, so that I can include a device in one or the other, or both. Here, I’ve included my test device in both device groups and these groups’ profiles are each configured to push settings automatically to clients. Note: whether a profile is configured as “push” or “manual download” doesn’t actually modify the contents of the .mobileconfig that’s downloaded, and so this seems to be purely a server-side configuration for the profile.
In this case, I want to test that I can apply each setting and that they will be combined on the client. This doesn’t even get into priority of “scope”, which MCX supports for user/computer/group/computergroup-type records. Let’s assume that we can ensure that we don’t ever combine these in a hierarchy more than a single level deep, but we do at least want to be able to combine them.
We can use the ‘profiles’ tool to dump all currently installed profiles:
profiles -P -o stdout
This command is useful as it can also output in plist format (that, unfortunately, is not the equivalent of a .mobileconfig, but that contains much of the same information in a different structure and namespace). I won’t use it in this example, however, because there seems to be a bug with all versions of 10.8 for outputting the contents of the
PayloadContent dict values of a
com.apple.ManagedClient.preferences type, in which it only prints an empty dict. Luckily, System Profiler is also capable of outputting both MCX data (“Managed Client”), and Configuration Profile data (“Profiles”). We can also call system_profiler on the command line and ask for only these data types (and optionally use ‘-xml’ for a machine-parseable version). Let’s look at the output for the stored profile data:
Two of the above profiles (Trust and Remote Management) are used for the MDM subsystem, we’re interested in the other two, showing the MCX data for com.apple.finder. Looks good. Now let’s look at the Managed Client data. In my testing, the ‘mcxquery’ tool won’t return any Managed Client data installed via profiles.
Both are there. And sure enough, a user logging in seems to get its settings applied:
(Note: these options aren’t grayed out, presumably because Workgroup Manager’s method of applying “Always” settings also seems to involve setting additional keys such as
ShowHardDrivesOnDesktop-immutable, which seems to be MCX’s strategy for many special “forced” items like behavior of the dock. I’m not bothering with these here.)
Now let’s remove these profiles and try the same two manually. We can purge the system of all profiles in one command (sudo is used in these examples, as these operations require root privileges):
sudo profiles -D
At this point, we’ll restart to ensure that these preferences are really no longer cached.
We can download these two profiles via Profile Manager’s web interface, and install them manually with the profiles tool. Downloading them via Safari will trigger an installation via the Profiles preference pane, which also achieves the same thing.
And restart again. These changes should usually apply after logout/login, but we’re restarting here to be absolutely sure.
I won’t paste the output of
system_profiler SPConfigurationProfileDataType because it’s identical. The output of
system_profiler SPManagedClientDataType, however:
Only a single preference key is applied and taking effect.
I’ve not found any repeatable pattern to which one persists based on installation order, just that it does not seem to honor managing the same domain by more than a single installed profile.
I don’t (yet) have a confirmation whether this a bug. Whether it is or not, it may reflect what I believe is Apple’s ideal use scenario for downloadable/installable profiles: self-service for end users to configure a handful of certificates or defaults for their new device (for which they have admin rights), or single monolithic “blobs” of configuration to be added to a deployed machine via a variety of mechanisms. Flat, complete configurations rather than nested hierarchies of atomic pieces that can be re-used in different combinations. Remember, it’s not possible to configure via Profile Manager’s web interface any of the “stock” payload types with any degree of granularity – it’s all or nothing, one meta-payload will all known preferences. A configured login window payload type is a good example of how many different legacy preference domains are managed and with what plist keys. Unsigned .mobileconfig files can be hand-edited after the fact but that’s obviously not intended.
If you intend to use profiles, this current behavior is definitely something to be aware of. If you believe it to be a bug (I do), file a bug report! Bug reports are Apple’s way of prioritizing issues for its engineering teams, and profiles are certainly here to stay. Admins have been slowly discovering that they do not fully replace the functionality available with MCX, and with Configuration Profiles having now been available to experiment with for over two years, it’s time to start investigating seriously whether they’ll meet your needs as a management solution, and to put pressure on Apple to resolve the issues or figure out an alternative.