@sdagley I was able to make all the changes to the version and made sure they are all "2019" now. Unfortunately, I am still seeing the same error I've been seeing since starting to use the pbowden script. Here it is...

When I take a look at the line in question (212) I don't really see anything to glaring as to why the script dies here each time. The weird part is even with this error I have had intermittent success with the script. Meaning it actually does updates sometimes on some machines even after generating this error.
@kricotta Even that script still requires someone to be logged in. There's no getting around that with the current interaction between msupdate
and Microsoft AutoUpdate.
@sdagley aww, ok gotcha. Any suggestions on how to update a fleet of machines by perhaps having an admin user log in during the firing of the script?
@kricotta In my environment we don't have machines on the network unless someone is logged in so I don't have direct experience with your issue. It seems like you could try having the Policy triggered at login so that will (hopefully) ensure having a logged in user when the script runs.
@sdagley thanks again! The weird part of this is that I ran this script against 3 machines, all with no user logged in. It "failed" on one of them with the error I posted previously, but actually updated Word on the other 2 only.

@kricotta Where the emoji for banging one's head against the wall? :-)
@sdagley I hear that for sure. To make matters weirder, I have logged into a machine and manually run msupdate cmd line and it manually updates PowerPoint and Excel so even so I think there is something going on with the pbowden script that isn't allowing all installed apps to be recognized and updated correctly. This is beyond the "need a user logged in" issue at this point. I'm hoping @pbowden will weigh-in soon as he is the master on this.
10.13 or 10.14 machines? I just discovered I need to setup a PPPC for Terminal to access the MS AutoUpdater in 10.14 otherwise I get this message.
@kricotta I am getting the same results in our labs. we want to be able to update our labs in the middle of the night when no one is logged on to cause issues.
@hkabik all of our fleet is 10.13.6 at this point, not sure what we are going to do moving forward.
@mcfarlandp same here, trying to trigger updates in the evenings when no one is logged in, but apparently we need someone logged in to update in this fashion. I'm thinking that I may just go to packaging each update and pushing them out like that.
I am now seeing this on a large swath of machines as well. Almost half my fleet. 98% 10.13.6.
:/
@kricotta We currently use an Auto-update feature thru Autopkgr. We update each Application individually. That has been working, but if someone has the Application open at the time of update then it will corrupt Office. I wanted to use this with Users logged in and not logged in so if say Word was open it would not update it.
I have found that if you run the command again immediately after the error it works. So I just added a second msupdate --install after a sleep 3 (to give it time to fail) to the script. Ugly, but it's working now.
@hkabik thanks, does this mean that you aren't using the pbowden script and just calling the command line? If so, would you be cool with posting a screenshot of how your policy is configured. I would love to give it a try here too. Thanks!
Yeah, until this is sorted I'm forgoing Paul's script and just running the simplest of simple scripts for this one.
#!/bin/sh
/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/msupdate --install
sleep 5
/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/msupdate --install
That's legit all I'm doing for right now and so far it's working. I have that scoped to a smartgroup of users needing the latest Office update and it's doing it's job. Blunt and ugly... but at least it's working.
@hkabik well I'm gonna follow your lead and try this as well. It is truly bizarre if this works as it doesn't do anything to register the apps for MAU as far as I know (pbowden's script does that part too). The mystery continues...
@hkabik no dice for the double command method for me. Had the same error I had in my first post of this thread. Back to the drawing board...
It's somehow even weirder that this works for me and not you.
Keep in mind, you still get that error in the logs from the first run through. But for me, the second run works. I do believe it still shows the policy as a failure though.
You may want to double check that both of your commands failed, not just the first.
Yeah it looks like both of them failed for me. I just tried going back to the pbowden script and just setting it to trigger at login. That runs clean although only seems update Word for the time being and nothing else as it doesn't think anything else needs to be updated. However, my Jamf Patch Management section indicates otherwise.
This works for me but you'll still get that same error if nobody is logged in. You'll have to find a way to log into all those computers remotely
!/bin/bash
LoggedInUser=$(ls -l /dev/console | /usr/bin/awk '{ print $3 }')
sudo -u $LoggedInUser /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/msupdate --install
Anyone get this to work via Self Service?
@DJC You really should try @pbowden's msupdatehelper as it makes keeping Office for Mac update via Jamf Pro incredibly easy. There's a link to a video training for it on that page.
I am having this exact same problem - both trying to just run the simple 1 liner and also when trying to run pbowdens msupdatehelper script. Did anyone ever find a solution?
Here is the log (pbowdens script)
Executing Policy Update Office for Mac apps
Running script MSupdate...
Script exit code: 0
Script result: User is logged in
Detecting and downloading updates...
No updates applied
Detecting and downloading updates...
No updates applied
Detecting and downloading updates...
No updates applied
Detecting and downloading updates...
No updates applied
Detecting and downloading updates...
No updates applied
Detecting and downloading updates...
No updates applied
Running command /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/msupdate --install...
Result of command:
2019-10-11 10:51:02.945 msupdate[26318:409477] -[NSCFConstantString objectAtIndex:]: unrecognized selector sent to instance 0x7fff8f0fd040
2019-10-11 10:51:02.946 msupdate[26318:409477] Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSCFConstantString objectAtIndex:]: unrecognized selector sent to instance 0x7fff8f0fd040'
First throw call stack:
(
0 CoreFoundation 0x00007fff337b3d63 exceptionPreprocess 250
1 libobjc.A.dylib 0x00007fff696a2bd4 objc_exception_throw 48
2 CoreFoundation 0x00007fff3383e206 -[NSObject(NSObject) __retain_OA] 0
3 CoreFoundation 0x00007fff3375a51b ___forwarding 1427
4 CoreFoundation 0x00007fff33759ef8 _CF_forwarding_prep_0 120
5 CoreFoundation 0x00007fff336f3f3e CFArrayContainsValue 197
6 HIServices 0x00007fff3197bb79 TransformProcessType 927
7 AppKit 0x00007fff30957c5a -[NSApplication setActivationPolicy:] 67
8 msupdate 0x000000010e438706 main 122
9 libdyld.dylib 0x00007fff6aa01405 start 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Why not just try
#!/bin/sh
su - $(stat -f%Su /dev/console) -c "/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/msupdate -i"