Tag Archives: profiles

Office 2016 Preference Management Changes

Starting with Office version 15.33 you’ll have the ability to manage some suite-wide preferences via profile management. Previously, these settings were configurable via defaults commands but weren’t CFPrefs enabled to allow for profile management of the settings. Thanks to the hard work of Paul Bowden and Erik Schwiebert at Microsoft, along with the collaboration and feedback of Mac admins in the macadmins.org slack instance, this request of preference management has been made possible. And this is just the beginning. Now with the foundation for preference management in code this will allow for more management options in future versions.

When an Office 15.33 app is launched for the first time, the existing preferences in ~/Library/Group Containers/UBF8T346G9.Office/com.microsoft.officeprefs.plist will be migrated over to the new preference domain automatically. At that time a key will be set signaling that the migration has occurred.

Paul has put together a new site (http://www.office4mac.com) that showcases a video course educating users and admins of the management changes. Look for more videos to come. This video shows examples of the preference changes, how to manage them, and implementing them through a management system. It’s definitely worth the watch.

For me, the meat and potatoes of these changes are the keys and values that are manageable in the com.microsoft.office domain. Here is an example management profile of all the keys that can be managed.

suite-wide preferences.png

OfficeActivationEmailAddress adds a “Belongs to” value in the About box to list who owns the software.

DefaultsToLocalOpenSave – by default Office offers to open and save documents to OneDrive, however due to data security policies that may not be acceptable and confuse users. This key will set the default open and save dialog boxes of all Office apps to the standard System views.

VisualBasicMacroExecutionState has 3 values that relate to the “GUI settings” in Preferences->Security & Privacty in app:

DisabledWithWarnings – “Disable all macros with notification” (Default)

DisableWithoutWarnings – “Disable all macros without notification”

EnabledWithoutWarnings – “Enable all macros (not recommended; potentially dangerous code can run)”

I don’t recommend managing the HaveMergedOldPrefs key as that is set organically. If you set it to TRUE then the old pref won’t be migrated automatically on first run. If you manage it as FALSE then it will try and migrate on every launch.

The two debug keys msoridEnableLogging and msoridDefaultMinimumSeverity should only be set when debugging an issue and I don’t see a need to manage them centrally. Leaving them enabled isn’t recommended.

Seeing these preference options move to a manageable location is a big plus for us admins, not only for the specifics of these settings, but also in the willingness of Microsoft to make these changes based on admin feedback. This can only mean more good things in the future.

Tagged , , , , ,

Not much, what’s new with you?

Update: As expected the `OUIWhatsNewLastShowLink` key is being incremented to display new features on subsequent releases. The profiles below will contain the latest values for the currently released versions.

Profiles for Office 2016 version 15.31

Office 2016 offers to show users “What’s New” on first launch.  Tim Sutton has a writeup on how to suppress the initial dialogs on his blog.  However, with version 15.14 of the Office apps there’s new “What’s New”s for Outlook and Powerpoint that sets a key not mentioned in the aforementioned post to suppress the new dialog.  This only affects Powerpoint and Outlook for this version.  Word and Excel didn’t present new prompts on launch this time around.

Along with the “What’s New” keys there are some others of interest:

kSubUIAppCompletedFirstRunSetup1507 – boolean – Controls the original “What’s New” dialog and Office 365 activation prompt on first launch

OUIWhatsNewLastShownLink – string – Controls the “What’s New” dialog on first launch for new prompts offered in subsequent version.

FirstRunExperienceCompletedO15 – boolean – Controls offer to import mailbox or setup an email account. (That’s a cap o15, not zero15)

SendAllTelemetryEnabledboolean – Control the offer to send crash reports to Microsoft

ONWhatsNewShownItemIds – array – Specific to OneNote this value is an array of integers that appears to increment haphazardly.  For just OneNote, this replaces the OUIWhatsNewLastShownLink value.

OUIWhatsNewLastShownLink values

Profiles
Below are profiles that will suppress the “What’s New” and disable crash reports prompts. These examples are set to “Force” the setting as attempts using Set-Once with a timestamp didn’t seem to be effective.

Outlook – suppress “What’s New” only (see below for suppressing Inbox migration)
Outlook – suppress “What’s New” and mailbox setup*

Powerpoint

OneNote

Word

Excel

*There is also a key for Outlook that will suppress the dialog to offer to migrate or setup an email account.  That key is a boolean FirstRunExperienceCompletedO15.  That’s a captial o, not a zero at the end of the key.

 FirstRunExperienceCompletedO15 suppresses this

To extract the values of the OUIWhatsNewLastShownLink I have a script that I run after installing and running each new application.  That script is at OUIWhatsNewLastShownLink Script

Tagged ,

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.

Tagged , ,