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