looking for this?

https://support.microsoft.com/en-us/kb/3074482

That is it, it looks like Microsoft is making it harder on us by breaking down the updates into each app instead off on file.

indeed. I originally had to google "Office 15.12.3"

I wonder how long it will be before AutoPkgr starts getting some JSS recipes for Office 2016.

@McAwesome If it's anything like Office 2011, there will be autopkg recipes for the updates, but not for the installer-from-scratch.

@elliotjordan That's what I'm hoping for. People in another department always package the Office installer+license together, so I only need the updates down the line.

So you have to install 3GB+ of updates to what was originally a 1.16GB application installer? How is that even possible?

I really hope Microsoft can address this. The old Office updates were ~120MB for the entire suite.

Is Microsoft serious here? Individual application updates instead of just a single updater? This is a big step backwards if that's how they are working it now. How does this make sense? And more importantly, how does a decision like this even get approved inside an organization? Totally ridiculous. : /

I think Microsoft is not to blame here this is an artifact of Apple's sandbox environment and the mandate from Apple that each application be self contained. Of course when you stop sharing the same files you used to things will grow. Its kind of hard to count on a library file existing in the Excel application structure when it may or may not be installed.
So, if you want to play the game by the new Apple rules you kind of have to live this way.

And actually I am quite surprised you do not have to get it out of the App store. That is what I was expecting when they released this is the only way to get it would be through the app store. Of course that may soon be coming as well.

@nessts And what is to stop Microsoft from creating a metapackage installer that contains the individual updates within it that only get installed if the apps in question are already previously installed? While it may mean that the overall installer will be quite large it at least would be possible to push a single update to clients. or maybe they can offer a single .mpkg installer like that for enterprises? If they don't, I suppose I will be creating my own custom installers with all the individual updaters within it.
I guess what I'm saying is I don't put the blame squarely on Apple. Yes, their new, constantly changing sandbox rules do make things tougher, but there are still ways to accomplish this without copping out with a bunch of individual installers if you ask me.

@mm2270 I wrap everything to work with the way we do things here anyway, so its just not that big a deal to me I guess whether its one or 12 packages. It could give you more flexibility to only give people the apps and updates they care about. Of course I never understood all the complaining about having to package firefox every 6 weeks. people spend more time complaining about it than it takes to do it I think. To each his own. I suppose if you have participated in the beta program you could give feedback on the separate packages and see if it makes a difference.

@mm2270, I completely get the frustration about the updates being larger than the actual installer. @nessts is correct about sandboxing and we're seeing the result of that.

My instinct tells me if we feel this is a problem then so does Microsoft. It's just too glaring an issue for them not to pay attention.

First question is: Why are they doing it this way now? I suspect it's because Office 2016 for Mac isn't fully released to the public yet. We've seen it released to Office 365 customers and today released to volume license customers. Retail is next in September and—who knows?—maybe the Mac App Store at some point. Full app updates probably made sense while running the Preview.

Second question is: Will Microsoft begin releasing that smaller all-in-one updater in the future? I suspect so. It only makes sense. Sometimes, though, the sensible thing has to come in a series of steps that we don't get to see.

It's also possible that this will allow the individual programs to update without needing to update all of the versions. With the sandboxing already in place, they don't have to worry about unforseen impacts when an update to fix something in Excel causes Outlook to not open the main window or something. Also, why force Excel to update if you're only fixing something in Word?

This may be the case, that updating only what's needed to be updated is the end goal. But in actuality, that's basically how the old Office 2011 updates already worked. Some updates only targeted one or two apps in the suite. The others were only touched by way of updating the version # to match across all applications. This made it easy to see what version of Office was running since all applications in the suite would contain the same version number.
I'm just hoping that splitting the updates this way doesn't mean we're back to pre Office 2011 days where each application could have its own version number. I suspect this isn't the case, and I also would guess that someone would have noticed this by now, so its probably an unwarranted concern.

@talkingmoose Thanks for the post and additional information. You make a good point that we are probably not seeing the final product right now since the full retail version isn't out yet. I hope you're correct that Microsoft has an end goal of making the updates a little more palatable. In addition to the hefty size of the updates being reported, having each app have its own update could make automating the process a little more complicated. For an end or home user. it will probably be a bonus to split them up, but for enterprise deployment, it adds a little wrinkle to things.

The office 365 site where they have the full installer for 365 users, they have been keeping that full installer up to date with the current version (so far). They just don't explicitly put the version number on there. But right now the current version is 15.12.3. That full installer is only around a gigabyte because when they lay down the apps they lay down the skeleton of the apps but only dump one copy of the shared framework. One of the post install scripts copies that one copy of the frameworks into each app bundle which balloons everything up to the six gigs or so in the installation. We are using 365 so I have been able to upgrade peoples installs just using that full installer.

Updates for Office applications for Windows are often separate as well. While this is annoying I would hardly call it shocking.

Hopefully Casper Suite 10 will assist with this stuff (that is what they promised at JNUC 2014).

@chriscollins You are using the full installer to update existing installs? How is that working for you in terms of user experience (does it reset any of the welcome screens/activation prompts?) and installation time?

@Josh.Smith The "updaters," at this point, really are just the full installers, just missing the Volume Licensing stuff and Microsoft Auto Updater. I would think there should be no difference in the user experience.

Hey fellas..

Any consensus on installing the volume license version, apply the updates then repackaging with Composer? I've never done that with and Office install, so didn't know if was recommended.

The Office installation is fairly complex and scripted, I would simply use Microsoft's deployment packages.

I have exactly zero "captured" applications packaged with Composer. I don't trust that method, frankly.

@Josh.Smith The update packages for Office 2016 do not close the program when they are run. On the next opening of it, they will be the new version. If you want, you can run them silently. I'd probably pop something for after the policy runs to let the user know they need to quit out of the program and reopen it.

I would say you would be fine with a Composer snapshot. I'm not using that method, but I did one first in a virtual machine just to see what gets put where, and it worked fine.

All the "scripting" in the Microsoft deployment package really does is copy the "shared" stuff -- the Frameworks, the Proofing stuff, and the Fonts -- from one location into each of the application bundles.

I would say you would be fine with a Composer snapshot. I'm not using that method, but I did one first in a virtual machine just to see what gets put where, and it worked fine.

I recommend against using snapshots. Using a method like this one is more modular, and will probably prove easier to maintain as Office updates are released.

Use Composer or update package deployments at your own risk as neither is supported by MS.