Office 2016 Volume Installer findings

[blackholemac]

See my reply to my own post below...I was interested in seeing the difference between the volume license build and the Office 365 build of MS Office 2016. Was referred to Rich's post. Had read it it and was insightful, but wanted to understand Microsoft's logic in creating this weird installer. I think I get it now and posted my findings below. Basically, I figured out how the com.microsoft.office.licensingV2.plist file is generated during installation in the GUI.

[tcandela]

when i run the installer using the -applyChoiceChangesXML it works and i have the licenseV2.plist in place

but if i have a policy that places the office2016VLinstaller.pkg/mychoices.plist in /private/tmp etc.... and have a script run it, the installation is NOT licensed, when users open Word, Excel or PPoint they are prompted to 'sign in to active office' and they see the popup for 'microsoft AU daemon' - even though my choices.plist has that not to install.

So I i ran the installer using the -applyChoiceChangesXML it works and i have the licenseV2.plist in place, ran excel/word/ppoint 15.16.0 updaters, and used composer to take the before/after snapshot to create my office2016.dmg. uploaded it to casper admin (indexed it), want to test uninstall also.

now i'll test this office2016.dmg via policy.

[tcandela]

so on the computer where i did the Composer before/after snapshot it has the 'check for updates' NOT available in the help menu- as specified NOT to install in the choices.plist file

but when i install the dmg via policy the 'check for updates' APPEARS in the help menu of each application (excel/word/ppoint).

I did not open any application from the computer that i used composer on. When creating the dmg i deleted the ensuing 'user' folder that was listed in the composer window.

com.microsoft.licenseV2.plist is in /Library/Preferences folder of the computer that had office 2016 installed via policy. trying to figure out why 'check for updates' is available.

not sure if i should of left the users folder in composer when making the dmg and check feu/fut in the policy? will recreate the dmg

[calumhunter]

@tcandela Don't use composer to snapshot, snapshots are bad. Also the licensing file the com.microsoft.licensev2.plist will soon not work across machines.
You will not be able to take that plist from one machine and use it on another.
In other words you can not use it in a modular image, or a composer package etc etc

It sounds like from your first post that your script to install didn't apply the choice changes.
Care to post your script?
You need to install in order
1. install the office 2016 suite, with the choice changes xml

Also you need to ensure that you are using the latest installer from the VLSC site, it should be version 15.14

again i can't stress enough, do not use composer to create a snapshot dmg

[perrycj]

Thanks for all the contributions that everyone has made so far to getting this right.

Not to throw a wrench into the gears of this thread but I'm assuming these workflows would not work if it was/is a straight O365 environment, non-volume licensed? At least that's how it seems to me.

[itupshot]

I'm revisiting this thread again after a few days break from it. I've been working on a couple of other projects that have been taking all my time.

@blackholemac The new Volume Installer is not available yet. I just checked VLSC.

@calumhunter I'll review your procedure today since my boss wants to have this ready for next Wednesday. So, the heat is on.

I want to reiterate that I appreciate the work that you both did on this topic. Thank you.

[blackholemac]

Check out the MacAdmins Slack still...a very knowledgable Microsoft employee is running a channel there and has been VERY helpful in working with what is vs. isn't supported and can offer better advice than I on building a good one. I am rethinking my approach as a result.

[georgecm12]

@perrycj O365 is much easier than volume licensing. You don't need to worry about the license file or any of that. Without the volume license file in place, the software just natively works as a copy that requires a login.

[tomr]

@tcandela for what its worth, I renamed Microsoft's Autoupdate program from Microsoft AutoUpdate to MicrosoftAutoUpdate (removed the space) and this solved the problem of the apps trying to check for updates as soon as they were launched along with the associated message indicating that Autoupdate was not registered with Launch Services (I forget the exact error message). It also removed the Check for Updates choice from the Help menus. Kind of brute force I know but it did the job. You can still run AutoUpdate manually if you want or use whichever method you normally use to patch Office.
We are using the non volume licensed version of 2016 but I would think the end result might be the same.

[itupshot]

Partial success.

@calumhunter Using your version of the "choices.xml" file I was able to exclude the Auto Updater from installing.

Now, I'm going to tackle converting the "skip first-run" plists into Config Profiles using mcxToProfile.

Last step will be to revisit the serializer.

[tcandela]

@tomRGA at what point did you do the renaming of Microsoft auto update? Are you using composer?

[talkingmoose]

@itupshot, curious to know why you're using mcxToProfile. You can upload your plists directly into a custom configuration profile in the JSS.

[itupshot]

@talkingmoose The "Set Once" key, which is not possible with regular Configuration Profiles.

mcxToProfile leverages the Custom Configuration Profile to import a Profile that has this key in it. Otherwise, the preference will always be ON and the user won't really be able to make changes.

[tomr]

@tcaldana I used a post install script to rename it and to change the keys in the autoupdate plist to manually check for updates.
I did use composer to originally pack up 2016. No issues with that so far and we have it deployed to over 500+ users and counting. I didn't include any user specific files and handled any preferences via the post install script. For the most part we left everything vanilla because we want our users to see the welcome screens, sign in and activate office, and let all the Microsoft cloud stuff we bought get appropriately mapped to the user. I did find the keys for suppressing all of the welcome screens but in the end I thought that it was just easier to leave them so the user's will click through them and see the activation screen. The one issue i had with AutoUpdate is that Microsoft released a new version a month or 2 ago (3.2) and I had to make sure that was installed first before i made any changes or wanted new updates to come down via autoupdate (which we don't use) since we had already begun deploying 2016. It wasn't a big deal to pull it down, package it up, and script the changes. The new autoupdate i think is when i noticed those Daemon messages starting to pop up and the name changed really helped with that.

[itupshot]

@tomRGA Those AutoUpdate daemon messages are part of the reason why I'm excluding the AutoUpdate app from my deployment. It's useless for our end users since we're handling updates for them.

What's more important for me is to set their first launch defaults to behavior they're already used to:
- No welcome or what's new
- No document gallery at app launch every time
- Page width zoom view in Word
- Autorecover set for 2 mins

The way we've been doing this is by injecting plists in the User Template (to apply to any new user that logs in). Or, injecting these plists to existing users' home folders if we're adding software to an existing setup.

However, mcxToProfile has the potential to replace this method by converting the plists to Configuration Profiles. I have to do more testing to make sure that the "Set Once" key is applied, and works properly in the resulting profiles, though.

A second method with potential is writing a script that uses "defaults write" to create a plist in the /Library folder that will have all the above preferences set. This plist would then apply "Once" to any user logged in, or that will log in, to the computer. They're then free to make any changes if they wish.

So far, I have only tested the second method with one key, the kSubUIAppCompletedFirstRunSetup1507.

[tomr]

@itupshot The only reason I ended up deploying AutoUpdate was if our remote techs need to install updates on the fly (which doesn't happen often) they had the option.

I've been doing the same as far as inserting plists into user templates and modifying plists (using defaults) for existing users since for most things we give them some degree of latitude.
Though I would like to explore the mcxToProfile option for management purposes.

Aside from some Outlook first run preferences (which had to do with asking users to import mailboxes from previous versions of Outlook and changing navigation views) I've only tested the key you mentioned. Seemed to work in most of my scenarios but like i said we ended up wanting out users to see those screens.

[bpavlov]

I've had mixed results unfortunately with SetOnce in custom profiles created through MCXtoProfile and uploaded to Casper. In some instances what would happen is that settings would continue to revert to the profile's values everytime a computer is restarted. Obviously that can be annoying if say for example you're trying to set the home page just once and the user has to continue to change it because they want something different. At this point, I assume if it needs to be set once, I just forget about it. I figure if it's important enough to manage, then it needs to be enforced always and if it isn't important enough then I don't need to manage it. YMMV of course. Always good to do testing.

[itupshot]

There's always Managed Preferences as a fallback while the OS still pays attention to them.

I've just been experimenting with the alternatives I mentioned because the message seems to be that Apple is killing MCX off. :-(

[itupshot]

So, guess what, kids? All our efforts to keep MAU from installing with Office 2016 are undone when you install Lync.

Please note what Casper is installing as part of an imaging config:

But when you check the "Installer.app/SWU" tab, our friend, MAU is there. I have confirmed by navigating in Finder to /Library/Application Support/Microsoft that MAU, and MERP (old versions, no less) are installed:

I created a "no_mau_lync.xml" choices XML file for Lync that excludes "appsupport," which is the package that installs MAU and MERP from Lync's installer. I based it on @calumhunter 's choices XML file that worked for my Office 2016 installer.

<?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">
<array>
     <dict>
        <key>attributeSetting</key>
        <integer>0</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>appsupport</string>
    </dict>
</array>
</plist>

I then created a new package in Composer bundling the Lync Installer, the "no_mau_lync.xml" file, and a postinstall script that applies it. It looks like it worked with my test laptop.

[calumhunter]

@itupshot I highly recommend you invest in Pacifist, It allows you to view exactly what is in a package, any sub packages, scripts, resources etc etc.

It's an invaluable tool that will show you exactly what a package is going to do.

If you dump Lync into Pacifist you can quickly see what is happening.

[donmontalvo]

Pacifist is BBEdit, where Suspicious Package is TextWrangler. :)

Mother's Ruin's Suspicious Package plug-in beats Pacifist's QuickLook plug-in...so we use the former to compliment the later. This combo is unbeatable.

PS, thanks for @jaharmi for recommending it at previous gig.

Don

[blackholemac]

I've been using Pacifist for years...Suspicious Package looks like it might be a good tool to add to the box.

[donmontalvo]

@blackholemac we asked Pacifist why they don't offer a pref to offload QuickLook to Suspicious Package, got a nice response, hope it happens!

[itupshot]

I have Pacifist. I purchased it when I first started reading this topic. That's how I found that the package that installs MAU and MERP from Lync is called "appsupport" after I saw the receipts in my JSS.

I confirmed the identifier with the "-showChoiceChangesXML" command. Hey, I've been paying attention to your guys' methods.

Thanks for all the tips. :-)

[tcandela]

@itupshot so how are you getting the com.microsoft.office.LicenseV2.plist onto your computers ?

I have used the -applychoicechangesXML with Office2011 and now trying it with 2016, but the LicenseV2.plist is not getting put into the /Library/Preferences on the computers getting the policy.

If I run the Microsoft_Office_2016_Volume_Installer.pkg directly on a computer, it puts the com.microsoft.office.LicenseV2.plist in /Library/Preferences

I am ending up doing what @blackholemac is doing (read his comment on 11/13/15 10:54pm). This is basically the same thing I did for Office2011, but now based on Office2016 VL licensing I grabbed the com.microsoft.office.LicensingV2.plist from a computer that already had it, and am now using that LicensingV2.plist in my Office2016 installation.

my choice changes simply unchecks Outlook and AutoUpdate from installing.

<?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">
<array>
<dict> <key>attributeSetting</key>
! <integer>0</integer> <key>choiceAttribute</key> <string>selected</string> <key>choiceIdentifier</key> <string>com.microsoft.outlook</string>
</dict>
<dict> <key>attributeSetting</key>
! <integer>0</integer> <key>choiceAttribute</key> <string>selected</string> <key>choiceIdentifier</key> <string>com.microsoft.autoupdate</string>
</dict>
</plist>

[bentoms]

@tcandela you're better off using the serialiser.pkg, especially with some upcoming changes.

[talkingmoose]

@tcandela, the issue you're describing with serialization should be fixed in the v15.17 release on Microsoft's Volume License Service Center (VLSC) during the first week of January. Specifically, the license file will install correctly when Office 2016 is deployed silently via command line, which Casper uses.

Don't rely on simply copying the com.microsoft.office.LicenseV2.plist file from machine to machine. This works today, but Microsoft considers it a bug. It will be fixed around v15.20 (ETA end of Q1 2016). The serializer part of the installer is suppose to gather information specific to the machine and use that to create a unique com.microsoft.office.LicenseV2.plist that will only work on that machine.

For those machines where you've already deployed the licensing file, you'll find a second installer on the VLSC in January called something like "VL Serializer". This is a standalone package you can deploy after the fact to correct the serialization issue.

Right now, I think most folks are deploying the com.microsoft.office.LicenseV2.plist the same way you've described. It works. But be prepared to have to use the VL Serializer when it's released on existing machines. Office 2016 will deploy to new Macs correctly licensed starting with v15.17 in January.

[tcandela]

@talkingmoose awesome, thanks for the info. There is no rush for me to get 2016 out into the environment here.

I have only did my Office2016 deployment it to a couple test macs, so looks like i'm good to wait for the v15.17 release.

I currently zip up Microsoft_Office_2016_Volume_Installer.pkg and my Office2016choices.xml and put that zipped file in /private/tmp, drag that into composer, and then make 'postinstall' script to do the unzipping and installation, then pkg it up and away I go.

same process for installing the updates, zipping up of the excel/onenote/ppoint/word updaters ......

[donmontalvo]

(1) volume installer, (2) serializer pkg, and (3) suppression script.

Done.

[tcandela]

@bentoms I read the information in the page you linked.

little confused, So v15.17 will include the serializer.pkg ?

will v15.17 office2016_installer.pkg run the serializer.pkg ? or will I have to run the serializer.pkg after the installer.pkg?

[donmontalvo]

The 15.17 VL DMG has two PKGs; one is the Serializer.

[talkingmoose]

The full VL v15.17 installer (coming in January) will have a "fixed" serializer package within it to allow you to deploy it without having to do any workarounds for missing license files.

Run the standalone VL Serializer (also coming in January) just for those installations where you copied a com.microsoft.office.LicenseV2.plist file from machine to machine. This will fix their license files (make them unique to each machine) before Microsoft fixes its bug that allowed you to copy it in the first place.

[5Y54DMIN]

@talkingmoose @bentoms

For those cannot wait for the 15.17, what is the recommended way to package and distribute office 2016 15.16?

[talkingmoose]

For now, the simplest way to license a VL edition of Office 2016 is to deploy the com.microsoft.office.LicenseV2.plist file after running the installer. That will work until v15.20 is released around March 2016 (my ETA not Microsoft's).

However, once January arrives and the VL Serializer is released on the VL portal, you should run it on your Macs before March 2016 to avoid any licensing issues going forward.

[5Y54DMIN]

@talkingmoose

What if i just built office 2016 15.16 into the image and capture it? then deploy that image?

[5Y54DMIN]

@talkingmoose

However, once January arrives and the VL Serializer is released on the VL portal, you should run it on your Macs before March 2016 to avoid any licensing issues going forward.

And is this understanding correct once it arrives All i have to do is include both the packages into the install configuration and set to install during t he imaging process?

[talkingmoose]

@pgh, sorry for a long-winded explanation...

Until you get the v15.17 full installer from the VLSC in January, deploy Office 2016 using whatever method works for your environment. The purpose of the VL Serializer will be to correct/rebuild/regenerate the com.microsoft.office.LicenseV2.plist that we've been copying from Mac to Mac to work around the installer issue that prevented it from installing in the first place.

Series of events:

1. Office 2016 installer has a bug that prevents the com.microsoft.office.LicenseV2.plist licensing file from deploying correctly.
2. Mac admins discover they can copy the com.microsoft.office.LicenseV2.plist file from a working Mac to a non-working Mac to correct the problem.
3. Microsoft corrects the Office 2016 installer to correctly deploy the com.microsoft.office.LicenseV2.plist file in v15.17 (coming in January to the VLSC).
4. Microsoft discovers our workaround for copying the com.microsoft.office.LicenseV2.plist to our Macs and considers this a bug. They announce they will fix this bug come v15.20.
5. To avoid having to completely reinstall Office 2016 just to correct the licensing, Microsoft provides Mac admins a standalone VL Serializer (coming in January to the VLSC) to help us regenerate the com.microsoft.office.LicenseV2.plist licensing file where we've already copied it to our Macs.
6. Microsoft releases v15.20 (ETA March 2016). This version will no longer allow copied com.microsoft.office.LicenseV2.plist files to work.

What's the bug that Microsoft is fixing? The serializer part of the installer is suppose to generate a com.microsoft.office.LicenseV2.plist file that's unique to the machine by embedding hardware information collected from the machine. That's not happening now, but it will be happening come v15.17 and enforced come v15.20.

[5Y54DMIN]

@talkingmoose

Thanks for summarizing, it explained alot.

No other method i could find would work some i'm building office2016 into the image, i;m about to capture it with casper composer and will let you know how it goes. I have installed office2016 and done all the updates for office and el capitan updates. As we do not have the serializer until January unless there is something im missing i could not get it to work while installing the .pgk from casper imaging.

Every time i tried installing using casper it would not work i would have the issues discussed in the below link

https://jamfnation.jamfsoftware.com/discussion.html?id=18155

[tcandela]

I will not install any Macs with Office 2016 until v15.17.

just to confirm v15.17; will have 2 .pkgs (installer/serializer)

will the v15.17 office2016_installer.pkg run the serializer.pkg ?
OR will I have to run the serializer.pkg after the installer.pkg?

[talkingmoose]

@tcandela, if you wait until v15.17 then you only need run it. You do not need to run the VL Serializer.

The VL Serializer is primarily intended for folks who have copied the com.microsoft.office.LicenseV2.plist file to Macs to serialize them.

[tcandela]

ok, so with v15.17 Office2016_installer.pkg will correctly add the LicenseV2.plist , no need to run the serializer.pkg along with v15.17 installer.pkg, got it thank you.

serializer.pkg is for macs that have a copied LicenseV2.plist.