MAU 4.3 command line issues

[metalfoot77]

I've been trying to get MSUPDATE 4.3 working via command line. I should mention that I had all kinds of issues with MAU 4.1 and 4.2 as well. After trying @pbowden's script and not having any luck, I thought I would just simplify things and just use the single line to install updates for all installed Office products.

This works as expected if I log into a machine with local admin and run it. However, when I make this a script in Jamf and then call it, it errors out every time. Anyone else seeing this kind of behavior?

Here is my script:

#!/bin/sh

cd /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS
./msupdate --install

and here is the output from running the above script on a machine:

Script result: RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. 2018-09-20 03:04:25.790 msupdate[28666:289450] -[NSCFConstantString objectAtIndex:]: unrecognized selector sent to instance 0x7fff9d0157d8 2018-09-20 03:04:25.792 msupdate[28666:289450] Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSCFConstantString objectAtIndex:]: unrecognized selector sent to instance 0x7fff9d0157d8' First throw call stack: ( 0 CoreFoundation 0x00007fff42f892db exceptionPreprocess 171 1 libobjc.A.dylib 0x00007fff6a130c76 objc_exception_throw 48 2 CoreFoundation 0x00007fff43021db4 -[NSObject(NSObject) doesNotRecognizeSelector:] 132 3 CoreFoundation 0x00007fff42eff820 ___forwarding 1456 4 CoreFoundation 0x00007fff42eff1e8 _CF_forwarding_prep_0 120 5 AE 0x00007fff4404903e _Z23aeBroadcastForRecordingPK11AEEventImpl 304 6 AE 0x00007fff44036d0f _ZL10sendToSelfPK6AEDescPS_il 615 7 AE 0x00007fff4400ac2f AESendMessage 1697 8 msupdate 0x0000000105355dee CaseInsensitiveSetContainsString 41992 9 msupdate 0x0000000105355c10 CaseInsensitiveSetContainsString 41514 10 msupdate 0x0000000105356085 CaseInsensitiveSetContainsString 42655 11 msupdate 0x000000010535612d CaseInsensitiveSetContainsString 42823 12 msupdate 0x00000001052c7373 main 10209 13 msupdate 0x00000001052c66e5 main 6995 14 msupdate 0x00000001052c69ee main 7772 15 msupdate 0x00000001052c4f18 main 902 16 libdispatch.dylib 0x00007fff6ad185fa _dispatch_call_block_and_release 12 17 libdispatch.dylib 0x00007fff6ad10db8 _dispatch_client_callout 8 18 libdispatch.dylib 0x00007fff6ad25217 _dispatch_queue_serial_drain 635 19 libdispatch.dylib 0x00007fff6ad18166 _dispatch_queue_invoke 373 20 libdispatch.dylib 0x00007fff6ad25f0d _dispatch_root_queue_drain_deferred_wlh 332 21 libdispatch.dylib 0x00007fff6ad29d21 _dispatch_workloop_worker_thread 880 22 libsystem_pthread.dylib 0x00007fff6b061fd2 _pthread_wqthread 980 23 libsystem_pthread.dylib 0x00007fff6b061be9 start_wqthread 13 ) libc++abi.dylib: terminating with uncaught exception of type NSException Detecting and downloading updates... /Library/Application Support/JAMF/tmp/MSUPDATE Cmd: line 4: 28666 Abort trap: 6 ./msupdate --install Error running script: return code was 134.

[marklamont]

might be worth asking in the microsoft-office channel in macadmins slack if you haven't already

[metalfoot77]

good idea, I'll try there as well.

[cotterp]

@kricotta - any love? I am hitting the same result on a set of workstations.

[metalfoot77]

@cotterp not yet, waiting to see if pbowden will get back to us on the Macadmins Slack channel about updating the script for Office 2019/Office 365.

[nvandam]

Try adding

-u $(stat -f%Su /dev/console)

to the beginning of the script. That fixed this for me.

[mcfarlandp]

@kricotta are you trying to run it in a not logged in state? I am having the issue when a user is not logged in. I am wanting that behavior in computer labs.

[metalfoot77]

@nvandam thanks, I will try that now.

@mcfarlandp yes, I am trying to run this without any logged in user.

[mcfarlandp]

@kricotta if that works can you share the full script?

[metalfoot77]

@nvandam so is the -u in your example a switch for the msupdate command line? Or are you saying to add that snippet to the beginning of the @pbowden script?

[mcfarlandp]

@kricotta have you had any success with this?

[metalfoot77]

@mcfarlandp unfortunately I haven't had any luck. I tried what @nvandam suggested above but I'm not totally clear about where I am supposed to put that in my command line.

[mcfarlandp]

@kricotta I am trying what @nvandam suggested as well with no luck.

[metalfoot77]

@mcfarlandp I have had some luck posting in the #mau4 channel of the MacAdmins Slack. However, I am also at the same stopping point there trying to get things fixed and mostly watching to see if @pbowden can weigh in on the situation.

[nvandam]

Sorry for the late response. This is what I'm doing and it's been working for me.

[metalfoot77]

thanks @nvandam, I am trying this out now. I will report back on how it goes.

[metalfoot77]

@nvandam I ran the policy exactly how you have it above and I am still getting the "RegisterApplication(), FAILED TO establish the default connection to the WindowServer" error.

I have a question though, are you running any sort of Configuration Profile for registering the Office apps with MAU. I currently have a custom plist (com.microsoft.autoupdate2.plist) that runs and not sure if you had something similar. I'm just curious what else you may have running around the MAU process that could be attributing to your success with the command.

[nvandam]

@kricotta I have that same config profile. All my Macs are also single user devices, so there's USUALLY someone logged in. I see you're doing this in labs, so it probably can't collect a user to run the script as. Try logging in one a Mac and running it.

[metalfoot77]

@nvandam well, I logged into a few machines and it ran with no errors. So next question would be, how do I do this on a lab of machines that most likely do not have users logged in?

[sdagley]

@kricotta You really need to have to have a user logged in. The msupdate tool actually launches Microsoft AutoUpdate to do the update, and that is not designed to run without the Mac GUI up.

[metalfoot77]

@sdagley thanks! I think I have seen a few people using scripts to act as a signed-in user in order to trigger the updates. I will look at that avenue and see what I can come up with. Thanks for your help as well @nvandam

[sdagley]

@kricotta Is there any reason you don't want to use @pbowden's msupdatehelper script and call it from a Policy in Jamf Pro? It really will make your life easier. The only thing you might need to change in the script if you update to Office 2019 are the application signatures as version 1.4 of the script has hard coded references to the Office 2016 app signatures.

[metalfoot77]

@sdagley I would love to use @pbowden's script and I have tried before but had similar issues with it failing so I was trying to simplify the process a bit. I would gladly switch back to it but I'm not really sure where I need to adjust these applications signatures in the script? Also, do you still need a custom plist to register the Office apps if you use the @pbowden script?

[sdagley]

@kricotta The app signatures are easy to change in the msupdatehelper script, just look for things that end in 15 and change them to end in 2019 (there's 2 signatures per app). You don't need the configuration profile if you're using the script, but I deploy that as well. Don't forget to deploy the "fully managed" profile from @pbowden's example profiles unless you want users to be able to manually run updates.

[metalfoot77]

@sdagley perfect, I am currently running his "fully managed" config profile as well and it runs great. So just to clarify I need to change each of the apps versions in the script from, for example Word, MSWD15 to MSWD2019. Or would it be MSWD19? Sorry for the constant questions, just want to make sure.

[sdagley]

@kricotta It'd be MSWD15->MSWD2019, and there should be 2 occurrences of each app signature in the script

[metalfoot77]

Ah, never mind @sdagley, I found this article which lists out the versions.

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

[metalfoot77]

@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.

[sdagley]

@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.

[metalfoot77]

@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?

[sdagley]

@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.

[metalfoot77]

@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.

[sdagley]

@kricotta Where the emoji for banging one's head against the wall? :-)

[metalfoot77]

@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.

[hkabik]

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.

[mcfarlandp]

@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.

[metalfoot77]

@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.

[hkabik]

I am now seeing this on a large swath of machines as well. Almost half my fleet. 98% 10.13.6.

:/

[mcfarlandp]

@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.

[hkabik]

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.