At JNUC 2015, I met up with William Smith of 318 Inc and of officeformachelp.com . He has done a lot of work on dealing with the fiddlier points of Microsoft’s productivity suite. Soon our conversation touched upon the Office for Mac 2016’s deployment issues. Short version, I mentioned that I had considered pulling apart the scripts from the installer package and rewriting then.
As many are aware the volume licence package for Office 2016 has many flaws. The big one that it’s not network deployable. Install by double clicking, works fine. Install via command line and it doesn’t licence the software. Install over loginwindow as so many admins do and it freezes and stops any deployment process in it’s tracks. (At least it did with Munki, I never got the chance to try Casper.)
William mentioned that he has contacts at Microsoft.
I’m not going to be able to rewrite the scripts as I originally planned, it’s too much effort for my timescales so i’ll have to settle for a critique instead.
I am working with the original volume licence release of Office as this is the only one I have access to. Some of my findings will probably hopefully have been fixed by now.
Game On.
Let’s start by pulling the Volume Licence package I have into Pacifist and seeing what’s present. We get this.
I went through the resources section of all the packages, and found relevant scripts in the following packages:
Autoupdate
Licencing
Volume Licencing
Fonts
Frameworks
Proofing
Microsoft Word
Let’s start by discarding the Fonts, Frameworks and Proofing scripts. These basically check to see if the relevant applications are installed and then ditto copying the relevant files into each application bundle. A little extra file copying saves on final package size, which is what I assume is the thinking here.
Autoupdate Postinstall
This is basically registering the Microsoft AU Daemon app bundle with the launch services database. This database according to apple’s kb does the following: “.. maintains a central data structure, the Launch Services database, in which it records all of the pertinent information about applications and the kinds of document files and URLs they are capable of opening.”
So they’re registering the auto update daemon but running the commands as the logged in user? This is pointless as the installer package is set to ask for admin rights to run. The lsregister command itself will happily run as root, so why sudo down again? Doesn’t make any sense to me.
The big fault with this is a packaging fault: they packaged the Autoupdate application with the com.apple.quarantine still set. That causes it to prompt on first launch that the file was downloaded. Sloppy.
Licencing
Ok let’s see .. WHAAA?
This scripts entire purpose is to get launchdaemon to load the licensing plists and then if a user is logged in to use dockutil to remove Office 2011 dock icons. (Despite the fact the two will happily co-exist with each other.)
Getting the permissions right after the fact with a script then forcing it to load is bad practice and bad packaging. What’s really shocking is the manipulation of the user’s dock without permission or asking.
Volume Licensing
GULP. Black box time.
Let’s run an app as the current user and licence the software, then delete the app responsible. Doesn’t that defeat the purpose of a Volume Licence by only running for the logged in user? What is that setup assistant doing? It seems to generate a licence file called /Library/Preferences/com.microsoft.office.licensingV2.plist
If you copy that file from computer to computer, it will automatically licence that computer so what’s going on here?
The real interesting part is that if you run this from the command line, something causes this not to work correctly so you end up with totally unlicensed software.
Microsoft Word
Out of all the application packages, this one has it’s own post install script. What do we have here?
Weirdness.
So if the application exists, read a bunch of info out of the app bundles Info.plist file into some variables? Then we take a bunch of info baked into the script and write that to the autoupdate plist? Why? There’s zero point as the autoupdate plist file is different to the one from 2011? I’m confused as all hell on this.
Now the really messed up part. It’s checking to see if the installer process is still running by searching for the installer PID, which is bad practice as this assumes installer is running purely for Office. It then is testing for to see if either an Office 365 or a Volume Licence is present, logging if it is otherwise attempting to launch Word after installation has completed.
I’m not sure why any of that is necessary. I believe the Word launching was to force the autoupdate to run but why bother with that? Let the user (or let a cunning admin block this by other means) get the prompt on their first launch. This code plays utter hell with login window deployments as it will cause munki (and probably other loginwindow based deployment methods) to get stuck forever.
The real curious thing is that the Office 365 licence file lives in a totally different place to the volume licence file. The container folder listed in the script, is all part of the sandboxing requirements that Apple is slowly introducing and is per user. This is the only part of Office 2016 packaging that seems to recognise that more than one user per system may exist.
All the Office applications prompts a user for Office 365 credentials if there is no licensing present. Why the checks?
Conclusion
There’s a lot of bad practice and a lot of assumptions going on here that I believe don’t need to happen. The installer package is running as root (the package itself prompts for admin credentials) and none of the operations occurring (with the sole exception of the Dock manipulation) requires running at a user level. The dockutil stuff doesn’t need to be present at all as managing a user’s Dock for them is pretty bad manners without asking them first.
I’ve big questions over this:
- Why is it necessary in virtually every script to be checking if this is a GUI or command line based installation? Who cares? You’re running as root, do the work you need and quit!
- Since you’re running as root, why are you using sudo to lower your permissions level? root trumps all (excepting SIP folders in El Capitan onwards).
- Why has there been almost no factoring in of multiple user computers? I used to help manage Universities in both the UK and Saudi Arabia and they had individual and public access computers. If you need something computer wide, don’t set it per user basically. This is what /Library/Preferences is for.