Microsoft AutoUpdate vs. Jamf Mac Apps Installers

[janzaldua]

Hi All. We noticed a lot of network bandwidth when using the Mac Apps installers via Jamf, and abnormally large sizes for application updates, such as Microsoft Excel. I asked Jamf Support in a ticket how big the update was for Microsoft Excel, going from 16.76 to 16.77 [for the Jamf Mac Apps installers], they said it was 1.23GB. But when using MAU (Microsoft AutoUpdate), the update size is much smaller (less than 100 mb).

Another user commented on this a few years ago, but it was in reference to Jamf Patch Management (not Mac Apps installers). That link to that thread can be found here.

Within that thread, the user links to a Mac Admins site, which showcases how big the current updates are for all Microsoft apps: https://macadmins.software/updatesize/

You can see the update size for Excel is under 100mb, and nowhere near 1.2gb. It may be possible that Jamf is using the updater PKG provider by Microsoft, which by itself is around 1gb. If you scroll down on this page, under Update packages, the Excel PKG is very large. 

I assume MAU is not using these update packages, as they are getting the updates directly from Microsoft. Rather than having the updates compiled into a PKG for deployment through an MDM (like Jamf). The reason I am making this post, is because we were having a lot of Network Bandwidth issues during RTO, when 100+ MacBooks all start downloading 1-2GB (per application: Excel, Word, etc..) at the same time. Aside from the size discrepancy, there was also the issue of Jamf Mac Apps installers deploying the applications at the exact same time (down to the minute).

[talkingmoose · Accepted solution]

What you’re seeing is normal.

Microsoft AutoUpdate (MAU) has a unique feature that allows it to deploy updates at the bit-level rather than the file level.

macOS apps are made of nothing more than a folder of more folders and files in a very specific hierarchy. You can right-click any app and choose Show Package Contents to see this structure.

Generally, if any single file is updated within the app folder structure, the updater will copy an entire new version of the file to the computer. However, MAU is designed to replace only the changed bits of a file rather than the entire file itself. That’s why its updates are so much smaller.

Also, the Office installer package, which installs everything, is smaller than the sum of the individual installers because each app includes hundreds of the same resource files (fonts, libraries, etc.). The full installer only needs to download these once and deploy to each app bundle, but the individual installers must be packaged with their own copy.

Long story short, the full Office installer and MAU updates are much more network bandwidth efficient by design.

[janzaldua]

Thanks for the response! I had a few clarification points.

1. Does Jamf have a way to utilize MAU instead of updating MS Apps through Jamf Mac Apps Installers?

2. Do you know why Jamf Mac Apps Installers would push all at the same time? I will show an example:

As you can see, 5 MS Apps pushed at the same time in office. And since Jamf Mac Apps Installers don't utilize MAU, they were at least 1GB each. And with 100+ MacBooks in the Office at once during that time, all MacBooks were downloading 5GB each exactly around 1:30pm.

This obviously isn't typical behavior of Jamf Mac Apps installers, I would assume? It actually lead me to start an idea for scheduled deployments. But it is still in review: https://ideas.jamf.com/ideas/JN-I-27592

[talkingmoose]

Jamf Pro can manage MAU settings using Computers > Configuration Profiles > Application & Custom Settings > External Applications > Jamf Repository. However, App Installers itself cannot use the same downloads as MAU. The technology to do what it does is only built into MAU.

Office updates are all released at the same time, which is why App Installers shows them triggering at the same time. They’ll install sequentially not consecutively, though, because the Installer app on macOS only supports one install at a time.

Because of Microsoft Office’s larger sizes and the features built into MAU to accommodate them, my recommendation is to manage MAU and let it handle the updates instead of App Installers.

[janzaldua]

This makes sense. Thanks for the info!

[daniel_behan]

Another good way of saving bandwidth is to curl the Office installers directly from Microsoft.  I actually use Microsoft's scripts.  You can read through them and remove any functions you don't need.

https://github.com/microsoft/shell-intune-samples/tree/master/macOS/Apps

Also for Office, make note of the Shim install of Defender.

https://macadmins.software/shim/

[janzaldua]

Thanks Daniel. The shim install is a good catch, as we we will definitely be excluding that. For the Microsoft Apps, do you not use the Mac Apps installers at all?

[daniel_behan]

I use the Office installer excluding the Defender shim, then I use the standalone scripts for Defender and Edge.  I leave all the updating to Microsoft Auto Update.

I personally don't use the Mac Apps installers often, but I use the Patch Management module as a dashboard.

[nigelg]

This was an issue for us yesterday when we turned on automatic "Mac Apps" updates for Creative Cloud 2024.  The download via the CDNs was maxing out on each Mac simultaneously which took up all the internet bandwidth.  I am very surprised (or disappointed) that there is no functionality for a local repository for these updates - handing it off to the Appstore daemon also queues everything and there's no way to stop it.  Rebooting and disabling the deployment didn't do it.  It's designed for self service only in my opinion and should have a warning/disclaimer in the UI that turning it on the automatic functionality will hammer your bandwidth as each client downloads as soon as an update is made available on the CDNs.  We have had to disable it and will use other methods/products to do our updates in the future (most likely candidate is the deployment functionality in Tanium).