Skip to main content

I've seen a lot of scripts managing Microsoft Autoupdate, but for years we have simply blocked the executable named 



Microsoft AutoUpdate


found from the path here (and probably I went through the process of finding it's name through) 



ps -ef | grep AutoUpdate | grep -v grep

33849  3595     1   0 11:38AM ??         0:00.42 /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AutoUpdate

33849  3596     1   0 11:38AM ??         0:00.17 /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AU Daemon.app/Contents/MacOS/Microsoft AU Daemon


But now with Office 2016, or MAU 3.x probably, the blocked executable doesn't work anymore. Did I miss some massive change that would be causing that? After realizing that, I went and started looking at this, and am also now blocking 



Microsoft AU Daemon


since that was not being blocked, but that does not seem to kill the process either. Thoughts? Do I need to move away from this? Shouldn't killing an executable, regardless of what it is, in fact kill it?

Have you tried changing the Restricted Software entry to Microsoft AutoUpdate.app



I just set that up as a test, using "Restrict exact process name", and it seems to work here for me. Still on Jamf Pro 9.x, so I don't know if something changed with v10 that would make the result different.
One thing I noticed is that it sends up 2 messages when it kills it. My assumption is because MAU 3.x runs both the app and the daemon from within that path, and Restricted Software kills both since they are using part of the same process, hence 2 messages. Just speculation though.

That may be the only combo of names/processes/selections I didn't try. I thought I had actually done that, but doing it again seems to work. Sometimes you need a second set of eyes...

Terms & ConditionsCookie settings