Microsoft MAU ManifestServer and Caching Server

[BOBW]

Just wondering if anyone has the new Caching server running for Microsoft office 2016 updates?

http://macadmins.software/docs/MAU_CachingServer.pdf

this requires MAU 3.8
http://macadmins.software/docs/MAU_38.pdf

Allows admin to run silent install of office updates and hold back updates. Looks pretty interesting

[Nix4Life]

Pretty quick setup. I used a Mac Mini running Server 10.10.5. confirmed updates pulling down via http logs on server, and added it to our Jenkins workflow

L

[BOBW]

For anyone interested I have been able to get this working quite well, although there are some gotchas

Pushing out MAU 3.8.1 - When this is pushed out through Casper you need to be able to trust the app before it opens, this can be done with:
https://gist.github.com/erikng/7cede5be1c0ae2f85435

Also need to add :

defaults write com.microsoft.autoupdate2 StartDaemonOnAppLaunch -bool TRUE

once the app is allowed to open you need to add each app to the MAU plist so it knows what to check during updates:
this can be done by looking at the post install script for each app, example is for Outlook:

#!/bin/sh

if ! [[ $COMMAND_LINE_INSTALL && $COMMAND_LINE_INSTALL != 0 ]]
then
    domain="com.microsoft.autoupdate2"
    defaults_cmd="/usr/bin/sudo -u $USER /usr/bin/defaults"
    application="/Applications/Microsoft PowerPoint.app"
    application_info_plist="$application/Contents/Info.plist"
    lcid="1033"

    if /bin/test -f "$application_info_plist"
    then
        application_bundle_signature=`$defaults_cmd read "$application_info_plist" CFBundleSignature`
        application_bundle_version=`$defaults_cmd read "$application_info_plist" CFBundleVersion`
        application_id=`printf "%s%02s" $application_bundle_signature ${application_bundle_version%%.*}`
        $defaults_cmd write $domain Applications -dict-add "$application" "{ 'Application ID' = $application_id; LCID = $lcid ; }"
    fi
fi

exit 0

Once you have added all the Microsoft apps to the MAU plist then you should be able to open MAU from /Library/Application Support/MAU2.0 and the app will see all installations

We have built with the help of @pbowden a powershell script which has been tested on Windows Server 2012 R2 to run caching and manifest server.

Hopefully its not too hard to follow

[pcrandom]

@BOBW, I'm looking at the MAU Caching Server document on macadmins.software, and I am confused about the need to add each app to the MAU .plist. Can't you control which Microsoft applications are available on the server end by populating the Production folder with only the application collaterals you want? I assume this is how one would control whether make available certain updates...

...though I am also a bit confused by how one might control and make available only an earlier version of an update and not anything newer. For example, if my company has a policy of always waiting a month before making an update available, then I'd want to make sure that my MAU caching server acting as a ManifestServer. I want MAU to update all applications but only to 15.29.16120900 and 15.29.16.121500, so I'd want to put all of the collaterals in the Production folder, but AFAIK I can't tweak the the packages or the .xml since the .cat will detect that. Do I simply remove the 15.30.17010700 packages from my cache folder, leaving the 15.29 packages, and that's the latest version update my managed systems will install? Do I need to avoid running MAUCacheAdmin so it doesn't redownload the 15.30 packages?

I think I'm probably just missing something fundamental because I haven't done this before.

[talkingmoose]

Microsoft AutoUpdate (MAU) reads the collateral files first and treats them as authoritative. You can put them on your server and point MAU to that server. It will read the files and consider those versions to be the latest, even if Microsoft has released newer versions.

[BOBW]

@pcrandom how were you thinking of deploying the server?

The manifest Server and Caching server are really two different things. The caching server is just the same as the Apple Cahcing server and will only use this when it is availble, otherwise they will go off to the web to download the updates.
this is done by setting on the client as per doco:

"
defaults write com.microsoft.autoupdate2 UpdateCache -string 'https://server/folder/' In this scenario, MAU will still use the collateral on the Microsoft CDN to detect updates, but before downloading those update packages over the Internet from the CDN, it will first check the UpdateCache server. If the UpdateCache server has a local copy of the update, a 200 response will be sent to the client and MAU will obtain its up
"

If you then configure a manifest server, (this could be on the same box) this is the tool which will allow you to stop the machines going off onto Microsofts CDN to download the updates.

When you do configure the manifest server you will need to make sure you change the path of your downloads away from production. then when you are ready just move those files over to prod.

as per the doco:
"If MAU has been configured to use a custom manifest server, it will use that exact path as the single authority of updates. If your custom manifest server is down or non-functional, MAU will report that the update server could not be reached. It will not fail-through to Microsoft’s servers"

[pcrandom]

Thanks @talkingmoose and @BOBW. I understand the concepts and the configuration differences on the client end, I'm still a little fuzzy on the configuration on the server end, but I think I just need to set up a test server and play around with it.

I had started to do so by creating a "cache" folder and a "collateral" subfolder. I downloaded the MAU_15.29.0_161209.dmg collateral file, created a folder by that name (w/o the .dmg) inside "collateral", and copied the contents of the .dmg into that folder. I then ran MAUCacheAdmin specifying "cache" for CachePath, expecting it to look at the collateral files I had placed in "collateral" and not download anything newer than 15.29. It ended up downloading ~6 GB with of updates into "cache" including 15.30 and the Office 2011 updates, and created matching version number folders (and "Legacy") in "collateral" too.

If I wanted MAUCacheAdmin to only download the 15.29 updates like I thought I was doing above, should I have used --CopyCollateralFrom:MAU_15.29.0_161209, or am I still misunderstanding the concept? Should I be thinking of the "cache" folder as always containing all possible updates and I just control what's available to clients with the "collateral "folders (the CopyCollateral(From|To) parameter doesn't actually control what gets downloaded to cache, for instance)?

---

I think the other thing that was throwing me is that the .cat and .xml files are named exactly the same for different update versions of a particular app, 0409MSWD15 for example for Word. So in setting up a "Production" subfolder under collateral to begin configuring a manifest server, I had initially assumed if the 0409MSWD15.cat and 0409MSWD15.xml file were in "Production" folder then MAUCacheAdmin would then download the latest version of Word. But now I understand that there are different versions of the collateral files, though they'd all be named the same for the same application.

So, if a colleague and I were both maintaining a MAU manifest server and he loaded all the collateral files into the "Production" folder previously, I wouldn't be able to tell at a glance what version updates the server is offering to clients. That'd need to be communicated ahead of time, or I'd need to view the .xml files and scroll to the bottom to see what versions the payloads were.

---

Lastly, should the "folder" in defaults write com.microsoft.autoupdate2 ManifestServer -string 'https://server/folder/' point to the "Production" folder or the "collateral" folder? (I believe in the UpdateCache version of this command, the "folder" should point to "cache".) If it should point to "collateral" as a manifest server, does MAU automatically know to look in a "Production" subfolder to tell which updates the administrator chose to offer?

[AVmcclint]

One gotcha that I discovered is that if your server doesn't have a trusted certificate from your own CA or an external CA, the MAU app on your client Macs will silently reject your server's self-signed cert and it won't install any updates. The only way I've found to work around this is to specify http instead of https in defaults write com.microsoft.autoupdate2 ManifestServer -string 'http://server/folder/'
and make sure your server doesn't redirect http requests to https. For our needs there is no reason to use https just to download Office updates from an internal server.

[EdLuo]

@pcrandom Did you ever get this working? I'm looking to setup a MAU manifest server too.

[donmontalvo]

This is all going away with MAU4...you'll be able to manage all the desired version stuff through command line.

[EdLuo]

@donmontalvo Thank you. Dug around for information about MAU4 and found this training video.

https://www.office4mac.com/courses/mau4b1

It is a huge improvement over MAU3. But since it is still beta, I'll need to get Manifest server working with MAU3. And I think I got it working. I'll need to test when I'm back in the office.

[EdLuo]

I got MAU3 working with our manifest server. The tricky part was figuring out the folder structure between the collateral files, .pkg and the DMG containing the collateral files. The MAUCacheAdmin script created folders causing this confusion. Since MAU4 is coming out soon, I'll skip the details. But if anyone is interested in getting MAU3 working with a manifest server, let me know.

[donmontalvo]

FYI...https://www.jamf.com/jamf-nation/discussions/27108/mau4-beta-course-updated

[k3vmo]

Is this a separate box I'll need to run - outside of my patch management withing Jamf Pro?

[http://docs.jamf.com/10.9.0/jamf-pro/administrator-guide/About_Patch_Management.html
](link URL)
I see that 3rd party can be handled - I'm wondering whether I need to build a local MAU server outside of Jamf?

[sdagley]

@k3vmo Yes, you would run the MAU caching server as a separate server instance than your Jamf Pro infrastructure.