Most MacAdmins take an either/or approach to managing updates for Microsoft Office on macOS, utilizing either Microsoft AutoUpdate (MAU) or Munki. However I’ve found that a hybrid approach using both works best for us.
I’ve shared my setup severals times on the MacAdmins Slack, most recently in a direct message, so I wanted to provide more details here. Read on if you are interested in how I’m keeping Office up-to-date and providing for new installs.
I’ll start by saying there is no right or wrong way to go about this. As long as your fleet is patched in a timely manner it doesn’t matter which approach you take or system you utilize.
Microsoft AutoUpdate
The primary benefit of utilizing Microsoft AutoUpdate is the reduced size, and thus greater speed, of updates. MAU can easily take advantage of delta updates going back several versions. Microsoft is also working on “Ultra-Thin” updates that will reduce the download size to under 20 MB for each update. This will be a dramatic reduction in size once it arrives in MAU version 4. Combined with an MAU Caching Server there can be great savings in bandwidth in addition to controlling which updates are available to clients.
The downside is that end users can defer the updates indefinitely.
Munki
The primary benefits of utilizing Munki are only having to maintain a single server for all software updates and the ability to force the installation of updates with a force_install_after_date key.
The downside, in my opinion, is the increased size of serving the full installers to clients for each update or separately importing both the full installers and delta updaters Microsoft makes available into your repo. Trying to maintain the logic for both full installers and delta updaters in the repo will bring additional complexity as well.
However if you don’t use Munki as the source for original Office installs maintaining just the updates there could be much easier.
Similarities
Either option will allow you to control when clients are offered specific update versions and stagger the rollouts across your fleet in groups.
My Setup
In my setup I am using Munki for the initial installation of Office but using MAU to keep those installations up-to-date. Our Munki server is available on the internet while our MAU caching server is internal only. We rarely have employees out of the office with laptops for more than a few days so everyone gets patched in a timely manner.
My typical workflow is as follows:
- Within 24 hours of updates being released (almost always a Tuesday) I deploy them on test machines simply to make sure they install and open.
- If no problems are encountered I immediately make the updates available to our “beta” group of users. This group contains at least one person in each department here.
- If no issues are reported I release the updates in MAU for the entire fleet on Monday.
- One week later I release the updates in Munki with a force_install_after_date for the following Monday.
During phase 3, MAU will auto-update any applications that aren’t open and prompt users via Notification Center every six hours to close and update any running apps. The majority of computers get updated during this phase.
Phase 4 adds the extra step of Munki notifying the user about the pending updates. MAU will continue to notify during this time as well. Any users who have chosen to ignore two weeks of notifications will then be forced to install the updates by Munki when the force_install_after_date is reached.
By staggering updates like this it helps ensure that reporters or photographers in the field, on mobile hotspots, aren’t having 1+ GB Office updates downloaded by Munki in the background in most cases.
(While MAU can update itself I almost always make the latest version of it available to all computers within Munki immediately.)
There are two downsides to this hybrid approach. First, it does mean that I have to maintain packages on two servers. Thankfully automation helps keep this from being a burden and Office updates are usually only released once per month. Second, there exists a small window each month when Office could get installed on a new computer via Munki and then immediately need to be updated by MAU. I have run across this a few times and it only adds a few minutes to deployment since I know when we are inside this window.
Let me know if you have any questions and I’ll be happy to help.
UPDATE: October 11, 2018
Microsoft has started soliciting feedback for a forced update feature in MAU. Join the #mau4 channel in Slack or contact @dimehta directly to offer feedback. I’m looking forward to seeing what comes from it in the future.
UPDATE: July 30, 2019
Microsoft added the ability to force update deadlines in MAU version 4.13. Read about the feature in my new post, “Forcing Microsoft update deadlines with MAU.”