@itupshot Re-read my post again. Pay attention to the commands i am running and the commands i am NOT running.

You seem to be doing a lot more than is required. Also not using the correct commands.
Also your choices.xml is not complete. Look at mine.

@blackholemac I just wrote out a whole thing then saw your on Slack and Paul has got you sorted.

FWIW i download the latest sku-less full suite installer (Currently 15.16) from MS its 1.2Gb. Then i apply the VL serialiser package and i have a fully installed and up to date Office 2016 VL. Can't get much easier than that.

Until Casper supports choice changes xml natively (Like Munki) You would have to script the install.

I'm not sure why y'all just don't run the installer Microsoft supplies then patch it. Freakin' cake.

I was just going to post and refer future posters there. The MacAdmins Slack is the place to go to solve this. I still stand by my choices.xml method, BUT there are other ways given what can be learned there. Go specifically to the #MS-Office channel.

@tnielsen I think the issue is scale.
When you have thousands or tens of thousands of clients, with tens, hundreds, thousands of remote sites.
Pushing a 1.3Gb installer package, and then ~4Gb of patches to bring it up to date is a lot of data that needs to be pushed around or pulled down the WAN from each client.

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.

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

@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

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.

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.

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.

@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.

@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.

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.

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

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

@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.

@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.

@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.

@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.

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.

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. :-(

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.

@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.

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

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