Scoping Office AutoUpdater updates?

Since that app is not in the regular /Applications/ path, unless you either:
a) Add in a custom path in your Software inventory options
or b) Create an Extension Attribute to gather the apps version #

You won't be able to easily create a Smart Group for it since your JSS isn't aware of its existence or its current version.
But both of the above options will work. The first will likely gather a bunch of other application data, if you choose to put something like /Library/Application Support/ as an additional path.
The second option would just involve writing a basic script with defaults to read its CFBundleShortVersionString or something like that.

Thanks for the tip, mm2270.

I was wondering if someone could help me out a bit with an Extended Attribute script.

I'm using this to determine the version of the Microsoft AutoUpdate version:

mdls -name kMDItemVersion /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app

But when I run this EA, the version is not being displayed. Obviously I am missing something.

How do I get the EA to display the version of the MAU app?

Thanks in advance.

i would probably do something more like
defaults read /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/Info.plist CFBundleShortVersionString and then of course save that to a variable and put the result tags around an echo of the variable.

Is the above line all you have in your Extension Attribute? If so, its not a complete script for one, and second, all Extension Attributes need to have an echo line that reports back the results but enclosed in "<result></result>" tags. That's how it knows what information should get populated into the database. Take a look at some exiting EAs as well for examples of this.

Second, while the mdls command works, you can also do this simply with defaults. Either way is fine.

defaults read /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/Info CFBundleVersion

Then put it all into an actual script, starting with a shebang and include the echo line-

#!/bin/sh

MAUVers=$(defaults read /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/Info CFBundleVersion)

echo "<result>$MAUVers</result>"

You can use your mdls command in the above as well if you want, but keep in mind the way you have it will return something like: kMDItemVersion = "2.3.6" so not just the version string. Easily fixed, but just something to be aware of.

Thanks to both of you. Once again, you both have been very helpful.

That's a pretty small update. You could save yourself the time of making an EA and just scoping it to all your Macs with Office 2011 installed. I wouldn't expect anything terrible would happen if they already have 2.3.6 and you re-install it. Of course testing it first on a system with it already installed would probably be wise. ;-)

Having /Library/Application Support/ as an application search path wouldn't necessarily be a bad thing.

I just ran

find /Library/Application Support/ -iname "*.app"

on my computer and discovered 29 apps.

Note that two of those items were within Composer sources, so keep that in mind if you build packages on computers used in production.

mpermann is probably correct, both in his hypothesis and in that the proposed process should be tested.

mm2270: Nice script.

Office updates do tend to exit gracefully if they don't apply to the target system WITHOUT rendering a fail state in policy logs (namely, exiting with status 1). I discovered this when a policy wasn't updated along with its smart group, and Macs running Office 2011 14.3.6 were targeted with the 14.3.6 updater.

Overall, however, I still prefer the EA approach, if only for theoretical reasons. Essentially, the above approach is to target everything, and trust that it will only apply where required based on installer logic. You can test this scenario and observe no issues, but I prefer to precisely target the computers you intend to update with the specific update they require, if only to limit potential instances of failure.

Probably a distinction without a difference in this case, but as a habit, I think it's cleaner.