Profile Behavior Changes in Yosemite

Forced. Often. Once. If you’ve used MCX and/or Profiles before you’re familiar with those terms and what they mean when a Profile is installed on a system.

I thought I did, too, until I stumbled upon a fundamental change of the rules in how Yosemite now behaves in the case of Often. Granted, anything besides “Forced” isn’t necessarily supported by Apple as their own Profile Manager tool only spits out Force management frequency profiles. Previously, adjustments could be made to Profiles to allow for a less heavy handed frequency of management. It appears our grace period for one type of manual change is over.  A tool to help create custom Profiles is called mcxToProfile.  Check out Tim Sutton’s documentation and tool — mcxToProfile as we’ll be using it later in this example.

See for yourself
As an easily observable example lets use a simple preference structure.
First, create a plist file with the keys you want to manage.

 defaults write my.great.app setting1 -string foobar
 defaults write my.great.app setting2 -bool false
 defaults read my.great.app
 {
 setting1 = foobar;
 setting2 = 0;
 }
 

Use Tim’s mcxToProfile tool to create a Profile to manage the domain “often”.

mcxToProfile.py --plist ~/Library/Preferences/my.great.app.plist --identifier MyGreatApp --manage Often

Copy the profile to a test machine or VM running Yosemite and install it.

sudo profiles -IF MyGreatApp.mobileconfig

You can see the preferences have been applied by running

defaults read my.great.app

Make some preference changes after the Profile was installed:

 defaults write my.great.app setting3 -string Chickens
 defaults write my.great.app setting4 -int 42
 defaults read my.great.app
  {
  setting1 = foobar;
  setting2 = 0;
  setting3 = Chickens;
  setting4 = 42;
  }

Log out and back into OS X and read the plist again.

 defaults read my.great.app
  {
  setting1 = foobar;
  setting2 = 0;
  }

The user’s settings have been eradicated even though they aren’t the keys being managed.

For a real world example lets look at how it works when we manage the Dock with a profile.

First, create a plist file with the keys you want to manage. This example sets the Dock to anchor to the right side of the screen.

defaults write ~/Desktop/com.apple.dock orientation -string right

That will result in a plist that only has the key specified in the defaults command:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>orientation</key>
    <string>right</string>
</dict>
</plist>

Create a Profile to manage the domain “often”.

mcxToProfile.py --plist ~/Desktop/com.apple.dock.plist --identifier MyDockSettings --manage Often

The payload content in the resulting .mobileconfig is

 <key>PayloadContent</key>
 <dict>
   <key>com.apple.dock</key>
   <dict>
     <key>Set-Once</key>
     <array>
       <dict>
         <key>mcx_preference_settings</key>
         <dict>
           <key>orientation</key>
           <string>right</string>
         </dict>
       </dict>
     </array>
   </dict>
 </dict>

Copy the profile to a test machine or VM running Yosemite and install it.

sudo profiles -IF MyDockSettings.mobileconfig

When the Profile payload applies you will see the Dock quit and reappear pinned to the right of the screen. Now make a manual change to the Dock, for instance, drag and drop a couple apps to the Dock. Log out and back into OS X. The apps you added are gone. The Dock has reverted to the way it was when the Profile was installed. This will happen every time you log out and back into OS X.

So now what?
An informal survey in the IRC channel ##osx-server on Freenode showed that the Often management frequency isn’t used that..well..often. The only admins in the know of that frequency would be those that use Tim’s mcxToProfile tool or hand craft their own. But if you happen to have that frequency there are a couple options.

  • Change the frequency. Set-Once with a timestamp still appears to function correctly (for now). And Forced should work as long as the application you’re trying to manage uses the OS’s APIs for reading preferences.
  • Use a different tool. Use outset to run scripts to make the change on the frequency you need. LaunchAgents or LaunchDaemons are viable as well.

tl;dr – Don’t use Often in Yosemite. Profiles set to apply “Often” reset setting changes made after the profile was installed every “often” time it is applied. If a plist didn’t exist before the Profile was installed the resulting plist contains only the keys that are in the profile — collateral damaged keys be damned.

Advertisement
Tagged , ,

6 thoughts on “Profile Behavior Changes in Yosemite

  1. Have you filed a bug report (aka feature request) on this issue? If so, can you reply with number, so others can reference/piggy-back on?

    Liked by 1 person

    • eholtam says:

      I did submit a bug under Apple Radar #19964383 and for reference an Open Radar

      Realistically, I’m expecting a “works as expected” from Apple if I get any response at all. The bug was submitted on 2/26/15 and have yet to get any kind of reply. I haven’t tested this functionality in later builds of 10.10 or 10.11 as we’ve adjusted our workflow around this limitation and no longer have Set-Often profiles.

      -Eric

      Like

    • eholtam says:

      This issue appears fixed as of 10.11 beta 15a226f. Apple replied to my bug report asking to verify the behavior. I was pleasantly surprised to see it working as expected again. I’ve asked explicitly if the set-once/set-often frequencies are supported. We’ll see if I get a reply to that inquiry.

      Like

  2. Mario C says:

    Can you give an example for “Set-Once” with a timestamp? We currently have to inject plist files into the User Template to get this “Once” behavior. We want to use Configuration Profiles more, but this has been the main obstacle. We used to be able to do it using Workgroup Manager in the pre-Yosemite days.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: