Office 2011 Updates via casper

It's the stupid quit_apps script. I typically edit the "distribution.dist" file inside the package to disable that from running by default. Let me dig into this and write this up.

Are you caching the packages first or just trying to install them directly from your CasperShare? I have run into issues with the MS Office Update mpkgs and pkgs getting corrupted when they download from a CasperShare, especially when doing a cache / install from cache type installation and when you are using http downloads. I don't see this happen with any other pkgs in our CasperShare. Only with the Office updates.

If you're using http, try forcing the policy to use AFP/SMB in the Override Default Policy Settings section (first tab in the policy) Check the "Force Distribution Points to use AFP/SMB instead of HTTP" box and try it again. If it works, you may have an issue with HTTP on your CasperShare. I have found the Office updaters are very susceptible to any problems with http downloads, and get damaged quite easily. This is a common problem when using a Windows server as your CasperShare DP that don't have the correct mime settings for pkgs, but in our case they are coming off Mac servers DPs, so I don't have a good explanation of why it happens for us.

I've got a post on how to edit the all_quit function that Robert referred to. It's available here: http://derflounder.wordpress.com/2012/09/26/removing-the-office-2011-installers-application-quit-function/

Thanks guys, I shall try some of these solutions and let you know how I get on.

I dont seem to be able to edit that file. The terminal command to make the office_edit does not work

Thanks

Dan

Dan,

Sorry, should have clarified. The pkgutil --expand command only applies to flat packages. If you can right-click on the package and see Show Package Contents, it's not a flat package. In that case, you can access the all_quit script by finding the Office2011_all_quit_14.x.x.combo.pkg and editing the preflight (instead of preinstall) script.

One thing I do instead of having to hack the installer package is just run a "before" script that does a

#!/bin/sh
killall -m Microsoft
killall -m Safari

I let the user know in Self Service that they should quit Office and Safari first else they'll be forcibly shut.

What about deploying the updates as DMG made from Composer?

What about deploying the updates as DMG made from Composer?

You can certainly do that, but that tosses out any vendor logic that's provided. Where possible, I try and preserve that, especially with a big product like Office unless you like slamming the entire suite down for a point update (I've seen it done on fast networks).

I've also seen that method become problematic with Office if you've laid down a DMG-version and then try and update with a pkg installer where the installer doesn't find the right receipts it's looking for and refuses to update even though all the bits are on the disk that should be updated. It's been awhile since I've seen that problem with Office though.

With MS updates, and Adobe updates, I generally try to do them at login or logout, preferably logout. I typically send an email out to my user base and ask them to restart their computers while on the network here, so that maintenance can be performed.

This approach seems to get past the "app X is open and stops the update" from happening (per Jared's mention of killing Safari). Those seem to be the only two times you can be 98% certain the apps you need to update are not open.

So let's say you want to update the version of Office out there, and you know that your users are going to be in Outlook, they have laptops thus never log out, and you've been told to update Office silently with no user interaction, and it's been highly suggested that they not even have to restart / logout for this to happen if at all possible.

What are the options? Will running the update while they have some part of Office open (after killing the quit_apps script) affect their current usage and successfully update the app? Or is it just "unpredictable" at that point.

Based on my testing, installing the update will close any Office apps that are open.

Han, yeah, no one can really say how an app will behave when it gets updated while it's open. Totally understand it's best to do this with no one logged in, or at login/logout, but sometimes you don't have that option (i.e. BYOD project where users rarely/never log out).

BTW, @golby and I have both seen some screwy issues after modifying the Office packages (expanding, either editing the Distribution file to disable the quit_apps script, or by editing the actual quit_apps script as Rich describes here: http://derflounder.wordpress.com/2012/09/26/removing-the-office-2011-installers-application-quit-function/

Flattening the package, I've seen both the OS as well as Casper gripe that the package is corrupt. Sigh. Haven't tried with 14.3.2 yet, but soon...

--Robert

Yeah, as I mentioned in my post earlier up, the Office packages seem to be very susceptible to becoming "corrupted" if certain changes are made to them. We've seen that too, which is why we chose not to go the route of deleting the quit_apps script in the pkgs.

@hkim, how the Office installers/updaters work is, if the installer is being run in the GUI with the regular Installer.app, it detects this in the script and will throw up the message to quit offending apps to the user. If it sees its being run from the command line, aka, silent/background install, it just quits the offending apps without any message, UNLESS you decide to yank out that quit_apps script altogether. But then you could run into the issues that RobertHammen and I and others have seen with the installer not working well after recompiling.
I guess try it both ways and see.
But I would think its not going to be a good idea to leave any apps open for too long after they've been updated. At the very least you might want to have a post install or After script run to let the current user know their apps have been updated and to restart them as soon as they can. At least that way they've been warned if anything wacky starts happening.

Thanks for posting all these methods guys. Recently tried stress testing deployment of Office 14.3.4 with Word open and it appeared to totally hose the Office install. Not just Word, the whole Office suite. Nice.

Faced with the same situation @hkim is in, I think I may go the logout + dialog method as my Office Update trigger though FYI on a neat little prompt + wait script that Steve & Robo posted up last year that may be useful here for those who want to trigger during user session and not forcibly kill Office:

https://jamfnation.jamfsoftware.com/discussion.html?id=6134