Microsoft Office for Mac 2011 14.4.8 via casper taking longer than via MS AutoUpdate

[ericjboyd]

We have been downloading the update via MS support page, pulling the .pkg out of the .dmg and renaming the .pkg to remove spaces and uploading to the JSS.

The policy to install the patch triggers on logout.

Is there something we should be doing to speed up the update process?

We have tested installing the update via MS AutoUpdate, as well as via our policy, and something is causing our policy to hang.

Should we be doing something different with the update?

[davidacland]

Hi,

I'm only testing this update at the moment but have tried deploying it from an AFP distribution point. No speed issues.

Do you have "update inventory" as part of the policy? Or do the policy logs give you any clues where it is getting stuck?

[mm2270]

If the policy is hanging, I wonder if there is any policy log at all for it in the JSS. It may not ever get to that point.
I suspect the issue is the logout trigger. I haven't really tested it yet, but if there is something in this latest update that requires a user login session, having it install at logout could be causing it to hang.
Can you scope it to one Mac using the regular check in trigger and see if it succeeds then? if so, it may be the trigger you're using.

[calumhunter]

I had a similar problem trying to deploy these updates when it wasn't logged in. Theres a quit all script that runs which causes a hang if its not logged in. You can run this script over the office update and it will fix it for you

https://gist.github.com/hunty1/b74d65efa75702f1fca0

I haven't tested this with 14.4.8

But it works with 14.4.7. YMMV

[ericjboyd]

The policy only shows 2 successful installs, many pending and no failures. We are performing the maintenance > update inventory. We were triggering it at logout to reduce potential data loss, since all office apps and browsers need to be closed.

[davidacland]

So it sounds like when it is run if it is completing successfully. The update inventory at the end could add a chunk of time to the process but without it you won't know which machines have the package.

You could try it at login instead as at least it's going into the user environment.

I would also double check manually installing it (excluding casper) and compare the with the policy log to see if the times are the same.

[RobertHammen]

Lot of laptops? Bet the users don't log out. So yeah, run at login AND logout and see if you get more users with successful policy histories...

[joecurrin]

No issues here either. All installs have run at normal speeds.

[#9]

This is also how I've been deploying Office 2011 updates, installing from AFP DPs without caching at logout. I haven't seen any hangs with 14.4.8 but I'll take a closer look as I deploy to my wider test base and then the fleet.

[Nix4Life]

@ejboyd][/url
could be something with your setup as others have mentioned. Installs are going out via munki with no issues speed or otherwise

LS

[johnnasset]

@ejboyd][/url

Rich's method for stripping out the all-quit requirement for Office has worked for me as of 14.4.7

https://derflounder.wordpress.com/2012/09/26/removing-the-office-2011-installers-application-quit-function/

[ericjboyd]

Wouldn't the login trigger get skipped if FV2 is enabled?

And if I trigger at startup (for non FV2) would that give the same issue i am seeing at logout since no user is logged in?

If i trigger is at startup for FV2 systems, then the user has already logged in and it is likely that office apps or browsers will be running already.

Wish the update could be run without issue with the office apps open as with Lync.

[mm2270]

@ejboyd - I may get some flack over this from some folks, but believe me when I tell you, I've been installing Office updates over running apps now for some time using a NoQuit.xml file and the command line installer, and have not had a single instance of corrupting an app or database or anything. I'm not saying its impossible for it to happen, but given that I've seen other applications go bad from updates installed while the app wasn't running, there are no guarantees of anything. But my testing has shown no issues with installing on top of running Office applications.

In short, the worry about having the apps running while installing these updates is actually nothing to worry about in my experience.

Let's put it this way - Microsoft could have easily designed their updaters to not allow for bypassing the quit function with an installer choices xml file, but its there for the using. My guess is MS is also aware its not actually necessary to shut down the apps beforehand. They likely only do it as a CYA.

Also, to answer your question on FV2, login still occurs. Login simply means the Desktop loading up as the user's profile is loaded. Just because FV2 bypasses the regular login screen doesn't mean "login" isn't occurring. Its still happening, it just looks different.

[jhbush]

@mm2270 I'm editing the NoQuit script, but I would interested to know how you are using that .xml file?

[mm2270]

@jhbush1973-

Create the xml file, like so-

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<dict>
<key>attributeSetting</key>
<integer>0</integer>
<key>choiceAttribute</key>
<string>selected</string>
<key>choiceIdentifier</key>
<string>quit</string>
</dict>
</array>
</plist>

Save it as NoQuit.xml or whatever you want to name it.

Create a package in Composer that drops the Office update plus the xml into a temp directory, like /private/tmp/ or you can cache them into another more permanent location

Create a script or a post install script, whichever makes sense, that does something like:

/usr/sbin/installer -pkg "/path/to/Office 2011 14.4.8 Update.pkg" -tgt / -applyChoiceChangesXML "/path/to/NoQuit.xml"

This runs the Office update package and tells "installer" to use the xml file you created in the first step to bypass the quit apps function inside the installer. Using this method there is no need to expand the package, edit it and then rebundle it. Either method works fine though of course. The advantage of modifying the installer is that its more portable, since it can be run standalone, but it also means touching every one of the updates released by Microsoft.

The above process is included in my Update_Core_Apps script when doing any Office updates.

[rmorgan314]

@jhbush1973 ......I'm somewhat new to Casper - I can make the install work (via command line), but I'm having trouble creating a package in composer that drops the office update plus the xml into a temp directory. Can you provide the basics of how to create a pkg in composer that will do this? I've tried a few times with no success.

[RobertHammen]

@rmorgan314

1) Create a /Library/OfficeUpdate folder
2) copy in the Updater and the xml file into that directory
3) Open Composer
4) drag your /Library/OfficeUpdate folder into the Composer window (into the left-hand sidebar under SOURCES)

This should let you create the installer package or DMG that you need as part of deployment...

[spankky]

in new office Mac 2015 or 2016, whichever they're going to call it, Microsoft AutoUpdate stores the temp installer downloads here: /private/var/folders/k6/rcv55fmx17504zxf1s83stz40000gn/T/MSau_1280/