Open Radar

 
Summary:

Installation of multiple Configuration Profiles that set preferences for the same defaults domain cannot be applied "additively", either installing via the Profiles preference pane _or_ using the 'profiles' command. Only a single profile's payload will apply for that domain.

This does not occur if pushing profiles using Profile Manager with overlapping settings using device groups.

Steps to Reproduce:

(note: the two profiles I generated performing the following steps are attached for reference)

1. With OS X Server 2.2.1 and Profile Manager configured, enrol a test OS X client running the most current developer build as indicated in this rdar.

2. Create two device groups, and configure a profile for each. Each profile should be configured for Automatic Push and have a single Custom Settings payload defined.

3. In one device group, configure 'com.apple.finder' with the bool key 'ShowHardDrivesOnDesktop' set to true, and in the other configure this domain with the bool key 'ShowMountedServersOnDesktop' set to true.

4. Add the test client to both device groups, save, and ensure the profiles have both been pushed to the client.

5. Logout/login, and observe that both preferences have been applied:

system_profiler SPManagedClientDataType

6. Now delete all profiles on the system:

profiles -D

7. Logout/login to ensure the MCX settings are no longer in effect.

8. Download these two profiles from the Profile Manager web interface and install them manually:

profiles -I -F /path/to/downloaded_profile_1.mobileconfig
profiles -I -F /path/to/downloaded_profile_2.mobileconfig

9. Observe that both profiles still show as installed:

system_profiler SPConfigurationProfileDataType

10. ..but that the output of 'system_profiler SPManagedClientDataType' shows that only one of the two preferences is being applied. You can verify in Finder's preferences dialog that this one setting is applied, not both.

Expected Results:

Installing a profile manually should have the same effect of installing this profile via the MDM service.

Actual Results:

Only one of the two preference keys will show as being managed. I haven't seen a pattern based on order of installation.

Regression:

OS X 10.7 (since the beginning that profiles are available to configure OS X clients)

Notes:

Because the two test profiles in this case, when installed manually, result in a client configuration that's different than if they were installed by the MDM client service, I would consider this behavior a bug.

This behavior is troublesome for IT administrators who would like to leverage the existing Managed Client system to deploy configuration profiles in an environment where using Profile Manager is not possible. Previously, it has been possible (and documented in video format on Apple's IT Resources website) to use local MCX records such as the guest computer record to manage preferences locally to the client in the same way they were manageable using an Open Directory service.

Many preferences are simply best to manage using Managed Client settings and Profiles, because the management can be later removed or modified without modifying the user's own preferences, and with this behavior it is not possible to layer multiple levels of configuration: any given domain can only be managed by a single profile.

For example, in many environments it may be desirable to manage parameters of the login window with some being standard across all machines and specific settings for other groups. Using Local MCX, this is possible. With profiles outside of MDM, it currently is not, and every possible permutation of preference must be manually created - this approach is simply not sustainable with a large scale of clients.

With a "computer level" profile, there is no longer the notion of groups and inheritance, but would have hoped that it would still be possible to manage multiple preference keys that aren't conflicting, including those that are part of a given domain.

I've attempted the above test using the login window Payload Type as well, with the same result. It is difficult to manage settings in a granular fashion using all the non-Custom Settings types, however, because they only allow one to save a profile containing all MCX preference data. The design of MCX and Workgroup Manager has always allowed setting of individual keys and for these to be merged when applied to the client. I used Custom Settings as the example for this bug report because Profile Manager still provides a per-key and per-domain editing interface to this payload type.