Microsoft AutoUpdate (MAU) version 3.18 msupdate command-line tool

[scottlep]

From https://docs.microsoft.com/en-us/DeployOffice/mac/update-office-for-mac-using-msupdate

"Microsoft AutoUpdate (MAU) version 3.18 and later includes the msupdate command-line tool. This can be used to start the Office for Mac update process, in addition to reporting the current AutoUpdate configuration. The tool is primarily designed for IT administrators so that they have more precise control over when updates are applied. Use the following steps to start using the tool"

Is anyone using this yet as a scripted way to update MSO2016? Perhaps similar to doing scripted updates for Chrome and Firefox? I was going to set up a test policy, triggered to run once per week. It seems to work as expected via command line and Unix command via Apple Remote Desktop. It even seems to delay the update of any apps that may be running and then installs once the app has quit. I have also added inventory collection for /Library/Application Support/Microsoft/ to be sure clients are running MAU 3.18 so policies can be scoped only to those where the msupdate commands will actually work.

[HNTIT]

Don't have an account on there.

Did try addressing posts on here to him, but nothing back yet

[sdagley]

@HNTIT You can get a free account for MacAdmins slack here: https://macadmins.herokuapp.com

[HNTIT]

Tried Posting there, no luck.

My Config Profiles were based on the Original Beta Versions, so i have now changed my registration ID for the AutoUpdate from MSau04 to MSau03.

I now see updates available is i do msupdate -l, but they never install.

If i do msupdate -c, MAU never shows a "Version On Disk" I am wondering if this is an issue?

[macsysadminjamf]

Does anyone actually have this working reliably? It seems 'fine' in basic testing but as far as I can tell the msupdate process is a bit....flakey or obtuse?

I've got machines with Office 2016 15.x. I am installing the latest MAU 4.2 from macadmins.software. Then I'm running Pbowdens script on the login window.

I also have a configuration profile scoped to the machine providing the .plist at the computer level.

So far, I have MS Word updated on one test system, on another nothing happens at all. Both are identical. These are labs so plenty of machines to test with.

Why would MS word update and no other apps? These systems have OneNote and PPT/Excel also. I'm yet to be convinced that this is a reliable solution. Do I need to run this script again and again to get it to work?

My goal is to be able to run updates from the loginwindow with no users installed. For some reason, MS continues to encourage users to update unless you remove MAU from the system so the only way we can provide an environment to the user that doesn't offer updates is to add/remove MAU each time we want to run updates...fun...

[burdett]

@macsysadminjamf MAU will only update apps that are registered. look at talkingmoose he has a configuration profile that will register apps for everyone.

[macsysadminjamf]

thannk you for the reply burdett.

I'm using that configuration profile from talkingmoose (with the correction to the last key also)

[macsysadminjamf]

okay, so i've manually added that.plist to the computer. there may be some other JSS related issue here but at least i'm seeing updates listed for the root user when run /path/to/msupdate --list

when I run the msupdate command from the loginwindow (either with jamf or ARD) it shows the apple logo and Microsoft Autoupdate and Help menus on the top of the loginwindow above the username/pass fields. It's very weird and obviously not a desirable behavior. The QUIT button is available in the menu and fully functional.

Not sure how a GUI application is launching from the login window but thats what this command below gives me.

/path/to/msupdate --install --apps xcel15

edited to add that i'm running the latest MAU and the --list command is still showing MAU 4.2 as an available download even though that's what it's running

I think it's clear this is an issue with registration or my running the command as root, but I think the fact there's no benefit to doing it this way is what gets me. With a lab environment, where updates are most critical, managing this seems so unreliable. We just want to have a system that installs updates in the backgrounds without the users having to see prompts to upgrade. The fact the only way you can do that is to uninstall MAU is a major part of the hassle of this. This binary badly needs an override command where it just does what you tell it to. No user is going to be running the MSupdate binary from the the commandline, save perhaps via Self Service. Is all of this just to support people who install to locations other than /Applications?

Again because we need to make user students don't get prompted while they use MS apps, we have to remove MAU completely after it's installed.

So to install updates in a silent way, without having 45 kids get dialogues to update randomly during classes, the process is:

-have all users logged out
-install MAU 4.2
-install .plists to trick MAU 4.2 into thinking the applications are registered so that it can be run outside the user context
-run ./msupdate --install --apps xcel15 mswd15 pppt315 onmc15
-wait a reasonable amount of time
-uninstall MAU 4.2

I think I need to leave this on this Friday PM and start fresh next week. Thanks for the help folks!

[sdagley]

The msupdate tool needs to be called when a user is logged in.

[macsysadminjamf]

If someone can give me a good reason why a command line binary with no GUI must be run with a console user logged in, I'm all ears. I'd love to at least know why MS is trying to keep admins from updating properly.

I'd also love to be wrong about this. I'm sure I'm missing something, but I think part of the challenge is that I fundamentally don't understand why I'd need a commandline binary that only can be run by a console user...

[sdagley]

The msupdate tool calls the Microsoft AutoUpdate to do the actual work of installing the updates. That’s a GUI app and you really don’t want to be running it without a user logged in.

[talkingmoose]

@macsysadminjamf, Microsoft isn't trying to keep admins from updating. As @sdagley responded, it's a command line tool that calls the GUI app. You may notice when running on a Mac with a user logged in the app icon appears briefly in the dock.

Only the GUI app contains the logic to correctly download the necessary software (version, delta update, full update, Insider updates, etc.). The msupdate command line tool relies on the app for all that.

You're right. This isn't ideal, but it's more than we had a year ago. It'll also get better as we give feedback to Microsoft. If you're not already part of the MacAdmins Slack workgroup, I highly encourage you to register and pop into the #mau4 channel. You'll find Olof Hellman from Microsoft has joined us there. He's now the principal developer of MAU 4. He's listening and interacting with us.

If you'll be attending JNUC this year, we also have @pbowden (Office for Mac installers, updaters and general wizard without a long beard) and Jeff Kalvass (PM for Outlook for Mac) coming to present and meet folks. Bring thoughts. Bring ideas.

[troyewebster]

I have deployed the newest version of MAU (4.14) and we have office 2016 installed ... need to update our user base and trying to get this script working:

https://www.jamf.com/jamf-nation/third-party-products/383/microsoft-office-for-mac-2016?view=scripts

I have version 2 installed ... when I run it thru self service, the call to msupdate -l gives me this:

"No result returned from Update Assistant"

.. but if I run the command directly from terminal, I get a whole list of 'updates available' ... which is what I would expect. I then modified the script to run as the currently logged in user, and re-ran the self service app ... still getting the 'no result' error.

Has anyone figured this out since the last time a post was made? I posted to MacAdmins slack about it, but haven't gotten actionable responses yet. Any help is appreciated ...

[perryd]

I'm also having issue with MAU.

Any kind of automation i use to run it i see the dock flicker a number of times like its trying to do something then nothing happens.

I've used a few scripts including @pbowden script but still cant get updates to run.

If i type it all in from the terminal i can see updates are needed and then if i try to install them all i ever get is queued. Has anyone else had this issue?
I don't want users to use the MAU app but no form of automation seems to be working.

[ngedemer]

Blows my mind this is still an issue...

I haven't gotten anything to work