Best Practices for Updating MS Office 2016

[jgalante]

I'm curious how you all are updating MS Office 2016 for your users, assuming you are managing the patches and not leaving it up to your users to keep Office up to date.

When we first deployed Office 2016 to users, I used Composer to create a single .pkg installer of all the Office apps and patched to 15.19. As updates continue, do you think it best to 1. push the individual Excel, Outlook, Word, etc. .pkg installers, or
2. push a single, patched Office .pkg installer?

The total size of the deployment would be about the same either way and it seems better to have only one installer run instead of four or five separate installers.

Your thoughts? How are you updating Office for your users?

[donmontalvo]

There are delta updaters, not sure how easy it would be to push out the right updates to the right existing versions.

The volume installer is <1.5GB, on a fast network you can cache the installer and alert the user to install. Sandboxed app, so if the user doesn't quit the app during the install, the update should kick in after relaunch.

Cache > Install Cached = thank you HTTP an resumable downloads

Don

[Josh_Smith]

I use the full suite vendor package from MS for both new installations and patching. I think the full suite package is smaller than the sum of the updates and it is nice to have one Office pkg per version rather than 6!

Composer can sit on the bench for this one...just download the package and drag it into Casper Admin. (We have 365 user licensing so I haven't played with volume licensing)

I confirmed with MS that re-running the full installer to update the apps was a supported upgrade method, they said they test and support it.

[alexjdale]

Sandboxed app, so if the user doesn't quit the app during the install, the update should kick in after relaunch.

I've definitely observed this behavior, but is this actually OK in practice? Certainly much easier than interrupting users.

[denmoff]

@alexjdale I wouldn't recommend it. Not sure what might happen, maybe nothing, but not worth the risk. I had deployed Chrome this way and it caused problems when users opened new tabs after the update ran. The new tabs could not get to any sites, while the previously opened tabs worked just fine.

[charles_hitch]

I am curious how many folks are not requiring Office apps be closed during the install. As @alexjdale indicated I have seen this work with Office 2016, but I question if anyone has run into issues.

[bpavlov]

The MS folks on Slack have not recommended you try to install Office 2016 while the apps are running. I know others have suggested they haven't seen any issues (and that may very well be the case), but I'm not taking chances.

[donmontalvo]

+1

I should clarify, while we haven't seen any issues in our testing of updating Office 2016, we use Before scripts (stolen from @mm2270) to force-quit the apps we are patching, after warning the users firsts

[jgalante]

I use the full suite vendor package from MS for both new installations and patching. I think the full suite package is smaller than the sum of the updates and it is nice to have one Office pkg per version rather than 6! Composer can sit on the bench for this one...

Thanks, @John.Smith and @donmontalvo. You're right, the VL installer for the full suite is considerably smaller in size and far easier than pushing several installers. I was making more work for myself with Composer.

@donmontalvo, do you have a link to those scripts? I didn't see any on @mm2270's GitHub. Thanks!

[mm2270]

@jgalante I don't have anything on my github page for what Don's referring to. It was in a post here on a thread.
If it helps though, here's a script I'm using when we "update" Office from 2011 to 2016 (really just installing Office 2016). This script is called first in the policy, which checks the running processes list for any of the older Office applications, and alerts the user they need to close them before continuing. The only reason for this is we are also removing the old Office 2011 at the end once the install is complete, so the apps need to be closed for that.
It loops if there are still offending apps open and won't continue until they are all closed. It uses cocoaDialog for the messaging, but you could easily swap it out for something like jamfHelper or even Applescript dialogs I imagine.

#!/bin/bash

cdPath="/Library/Application Support/JAMF/bin/cocoaDialog.app/Contents/MacOS/cocoaDialog"

customTrigger=""

if [[ "$customTrigger" == "" ]] && [[ "$4" != "" ]]; then
    customTrigger="$4"
elif [[ "$customTrigger" == "" ]] && [[ "$4" == "" ]]; then
    echo "A Custom trigger was not specified in parameter 4. Script cannot execute. Exiting..."
    exit 1
fi

appCheckList=(
"Microsoft Outlook"
"Microsoft Word"
"Microsoft Excel"
"Microsoft PowerPoint"
"My Day"
)

function checkForRunningApps ()
{

runningAppsList=()

x=0
while read appname; do
    if [[ $(ps axc | grep "$appname") != "" ]]; then
        runningAppsList+=("• ${appCheckList[$x]}")
    fi
    let x=$((x+1))
done < <(printf '%s
' "${appCheckList[@]}")


if [[ "${runningAppsList[@]}" != "" ]]; then

appListText="The following applications are running and must be closed before continuing with this installation.

$(printf '%s
' "${runningAppsList[@]}")

Close the above applications, then click Continue. If you need to Cancel this installation, click Cancel."

    promptUser=$("$cdPath" msgbox 
        --title "EMC IT" 
        --text "Applications must be closed" 
        --informative-text "$appListText" 
        --button1 "Continue" 
        --button2 "Cancel" 
        --icon info 
        --width 400)

    if [ "$promptUser" == "1" ]; then
        checkForRunningApps
    else
        exit 0
    fi
else
    echo "No applications running to be shut down. Continuing..."

    installInProgressText="The Microsoft Office 2016 installation is now in progress. Please be patient as it takes some time to finish.

Please do not try to open any Office applications until you see a final "Microsoft Office 2016 Installed" message at the end. You can dismiss this window and the installation will continue."

    "$cdPath" msgbox 
    --title "EMC IT" 
    --text "Installation in progress" 
    --informative-text "$installInProgressText" 
    --icon info 
    --button1 "   OK   " 
    --timeout 300 
    --timeout-format " " 
    --width 450 
    --quiet &

    ## Call the install policy by manual trigger
    jamf policy -trigger "$customTrigger"
fi

}

## Get the free disk space on the internal drive
freeDiskSpace=$(df -H / | awk '{getline; print $4}' | sed 's/[A-Z]//')

## If free space is too low, alert user and exit
if [[ "$freeDiskSpace" -lt 12 ]]; then
    "$cdPath" msgbox 
    --title "EMC IT" 
    --text "Not enough free disk space" 
    --informative-text "Sorry. Your Mac only has $freeDiskSpace GBs of free disk space. This installation requires at least 12 GBs free to continue. Please make the additional space available required for the installation, and then try again." 
    --button1 "   OK   " 
    --icon caution 
    --width 400 
    --quiet

    exit 0
else
    ## Otherwise, move on to checking for running Office apps
    checkForRunningApps
fi

What's nice about this is it explicitly tells the user which apps need to be closed in the dialog that pops up and refreshes the list each time they click Continue. So if for example it starts off with Outlook, Word and Excel all running, it displays those apps in the message. If they close Word and Excel but leave Outlook open and click Continue, it pops back up but this time only shows Outlook in the list of apps needing to be closed.
Once everything's properly closed, the script then calls a second policy by its custom trigger (passed in $4) that does the actual Office 2016 installation. So this script is used in a "pre" policy to make sure the conditions are right. Since Office 2016 is so large, I'm also checking for enough available disk space before allowing it to continue as you can see. While we also do this disk space check in the Smart Group, I don't always trust that the inventory information is up to date since available disk space can change rapidly.

Obviously this is all designed to be run from Self Service, so its interactive, but you could adapt the idea to a silent script that locates and closes the apps that need closing.

[jgalante]

Thanks for sharing @mm2270! Script looks very good. I will modify and test it for silent install.

[mbezzo]

ooo, this is nice. Thanks @mm2270!

[dpertschi]

Ditto Mike, thank you for sharing! Very good timing and much more polite than my killall script to quit the open apps, hahaha.

Let me ask this, are you (or anyone else here) using the cocoaDialog v3 in production or sticking with v2.
I'm only just getting my feet wet with it.

[mm2270]

I use v3 beta because, despite it being called "beta" its proven a little more reliable as OS X progresses. v2 had only been built and tested on very old long gone versions of OS X. Also, v3 has several new window styles that I make use of in my scripts, like checkboxes, radio buttons and a few other features. Those aren't available in version 2.

[hcodfrie]

Hallo @mm2270 just tried this one out and it does what you mention taking this one home thx ;)

Henk

[mconners]

@mm2270 I haven't done much scripting in my years, I know, get with the times right? Anyhow, I see the custom trigger piece. Will this script run if I comment out that portion or do I need to put a custom trigger? We don't do anything with custom triggers. I tend to "borrow" scripts that are easy to modify for our environment. I would love to learn how to modify this so we can get this one going.

Thanks much!!

[CAJensen01]

I've found that if the install is executing in the background (at the "Running Package Scripts" phase), and a user tries to launch an Office 2016 app, they'll encounter this error. When the install eventually finishes, they should be able to launch the applications fine.

I haven't had the time to invest in making a preventative solution, but just an FYI for those who might run into it. Basically, you need to make a script that is running for the duration of the install, and throwing an alert if a user tries to launch one of the apps and kills it. Mildly annoying.

[pcrandom]

I need to deploy to a large user base and have been experimenting with ways of deploying Office 2016 as silently and unobtrusively as possible. One thing I've been experimenting with was caching the installer and having it install on start-up. I noticed when I did this, I was able to launch Word 2011 applications without the above warning (I didn't try the others).

Any other tips to installing Office 2016 silently and in the background?

[bbot]

@CAJensen01 We fight with the same issue here..although ours doesn't seem to recover at all. We have to re-install the entire office suite if the user opens it while the updater is in progress.