Tag Archives: microsoft

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 , , , , ,

Microsoft Supported Office 2016 Volume Licensing Method

Below is information provided by @pbowden, who is a software engineer for Office for Mac/iOS at Microsoft, in the MacAdmins Slack instance (@mrexchange on Twitter) regarding the supported way to license Office 2016 with a volume license.  While I recommend joining the macadmin Slack instance to participate in these conversations, it may not be feasible for everyone  Therefore I’m posting this information externally for everyone’s benefit.

It’s completely supportable to download and install the latest SKU-less build from those FWLinks like http://go.microsoft.com/fwlink/?linkid=525133, and simply run the Office15_all_volume_licensing.pkg to license the build for VL. [ Run `pkgutil –expand ~/Downloads/Microsoft_Office_2016_Installer.pkg ~/Desktop/Office2016VL` to expand the flat package and gain access to Office15_all_volume_licensing.pkg in ~/Desktop/Office2016VL ]

Technically, you can just run the Microsoft Office Setup Assistant.app that’s inside the .pkg, but I’d prefer that you install using the .pkg just in case there are things we need to do in the postinstall script. There are code dependencies between Office15_all_volume_licensing.pkg and Office15_all_licensing.pkg, which is why I’d prefer you to deploy the SKU-less build first as it contains Office15_all_licensing.pkg. It’s that same reason why I typically don’t like folks shoe-horning the updater package on a new machine – as the licensing package is not in the updater, and you could end up in a mess with licensing. The licensing code is fairly complex and uses various internal triggers to ‘wake up’ at various times to check that all is well. i.e. just because it might work if you hacked some packages together and tried it once or twice on your machine, it doesn’t mean to say that it’ll ​*stay*​ working after you deploy.

The role of the Microsoft Office Setup Assistant app is to collect various machine identifiers (including hardware serial number and boot disk hashes) and encodes them into /Library/Preferences/com.office.microsoft.office.licensingv2.plist …this is how we tether the license to the machine. Manually copying one of those generated plists and copying it to other machines is absolutely not supported and akin to playing with fire.
However, we ​*do*​ support you moving that plist around volumes on the ​*same*​ machine (e.g. imaging scenario).
In other words, in those times our license code wakes up to check that all is well, we’ll verify that the hashed boot disk that we retrieved when the license was created is still mounted ​*somewhere*​ on your machine, even if it’s not currently the boot disk.

Bottom line is that if you’re copying com.microsoft.office.licensingv2.plist between machines then you are not in a supportable state. The only supportable solution is to have that plist file generated on the machine you intend to use by the Microsoft Office Setup Assistant (MOSA). Up to you how you package this, but MOSA needs to be run and the plist is tethered to the current boot drive of the machine. It’s okay to change boot drives as long as that original drive stays mounted as a volume (it doesn’t have to be the boot drive)

The VL build on the VLSC is old at 15.13.4. While internally we produce full VL installers every month (in fact, it’s every day, but I digress), the VLSC folks haven’t been in a position to take our monthly updates. I’ve been working with that team this week to get their engineering processes to be more agile. The good news is that they will be taking our 15.17 December release build, so what should be a welcome refresh. I’ve also been working hard on fixing your top requests and am confident that 15.17 will be a great release for you. The VLSC folks might need to skip one or two releases after 15.17, but after that they will be in a position to take all our monthly releases.

A follow up question was asked about un-licensing to allow for the Office 365 subscription method again.

Is there a proper way to revert from a VL install backwards to a 365-license?

Yeah, just nuke that one plist we’ve been talking about and the copy of Office goes back to a sku-less state

Tagged , , , , ,