Microsoft AutoUpdate and the Need to Collect Package Versions From Receipts

[mschroder]

Hi,

I just learned that Microsoft AutoUpdate 3.9.0 (170409) is not checking automatically for updates when it is set to do so. So I wanted to monitor the issue, and make sure users get the latest version of MAU. Unfortunately MAU is not an app, so I can not use the app version in JSS recognize the effected clients. And it looks as if JAMF still does not collect the version info from the package receipts.

Does anybody have an idea how I can detect the bad version of MAU?

[martin · Accepted solution]

I use a script to force update MAU once a week for example. You could read the version of MAU via an extension attribute:

mau_version=$(defaults read /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/Info.plist CFBundleShortVersionString)

echo "<result>${mau_version}</result>"

[mschroder]

Thanks a lot, that looks really promising.

[steve_summers]

Have you tried Smart Groups? I have a smart group setup to detect versions "like" 3.8. Seems to work. I'm deploying the latest version to folks who have versions below 3.9.
I believe Microsoft AutoUpdate is a category all by itself.

[talkingmoose]

Microsoft AutoUpdate (MAU) is indeed an application, but it lives in the /Library folder.. By default, Jamf only collects application inventory in the /Applications folder.

You can edit your Inventory Collection settings to include the path to MAU and collect application information via recon and as part of the Update Inventory policy:

/Library/Application Support/Microsoft/MAU2.0

[mschroder]

I did consider adding the MAU path to the inventory collection for apps, but since I don't know how the collection behaves in case a path does not exist I rather went for an EA as shown above.

[martin]

@mschroder, Jamf just added a new Patch Policy for Microsoft AutoUpdate. You can now delete the EA and start using the new Patch Policy.