Logging stops at Microsoft AutoUpdate for all my devices

[Artos254]

I am currently in the process of performing my first production usage of Patchomator, but I'm running into the following issues:

• When I am executing the policy (using Jamf as my MDM) while interacting with the device either by Self Service or Recurring Check-in, it runs well. However, when I allow a delay (in this instance 2 days) the script will run, but not actually update anything. The logging shows that it does begin and go through the checks for which applications need updates, but no actual patching is done. I suspect the policy is trying to run while the computer is closed during the weekend (due to our patching cycle that's when the 2 day period ends). Unfortunately, the logging gets cut off at the same point every time during the application update process so I don't have much to go by as far data, which leads me to my second issue...
• Logging gets cut off for all my devices during the patching process after Microsoft AutoUpdate. No other applications are documented in their updating beyond that regardless of what other apps are available.

Any ideas about how to approach these problems?

[Artos254]

By the way, I want to say I LOVE this tool and really, really want to make it work in my environment. Thank you so much for creating it!

[Mac-Nerd]

Thanks for the kudos - I hope people find it useful, even as I slowly, so so slowly, overhaul the underlying scripts.

As for your issue, I'll try and recreate it. Can you share the command line or config you're using? Also, what version of Microsoft Auto update is installed?

I suspect MAU is kicking off something that either needs user interaction, or waiting on MS apps to quit before proceeding, and so it just .. waits.

[Artos254]

I'm using a slightly modified version of the MDM Execution Script provided here in your MDM folder and the command is "patchomator.sh --yes --install --ignored --required".

More detailed testing has shown that Patchomator can't seem to close MS apps very well. If they're open when the script begins running, it doesn't seem to ever prompt about closing them. I'm planning to create another script that runs before Patchomator to close key applications that I've noticed don't play nicely with asking to be closed during the patching process.

I have some other thoughts I would like to get your input on:

• What does the lift look like to implement a screen takeover during the run to prevent the user from interacting with their computer during the patching process? Anywhere you'd recommend to start?
• I've tried running the script a second time immediately after the first as a catchall for anything that failed or was missed the first time, however, it seems to pick up all of the same applications it did the first time. I can only guess that the script relies on indexed data for applications versions and the reindexing takes time which hasn't occurred immediately after completing. Any info you can provide on this front would be helpful as I'm not sure how to proceed. Many of my users have terrible internet so it's not unheard-of for downloads to fail and need to be retried. My management and I want reliability in patching and a second run would help, but right now it seems unhelpful until I can get it to recognize the work the script just did.

Thank you again!

[Artos254]

I meant to include this as well: the logging right up until it stops. Other applications are patched after this, but they're not logged and this is the case for hundreds of computers.

Installing microsoftautoupdate...
2024-09-30 09:32:40 : REQ : microsoftautoupdate : ################## Start Installomator v. 10.6, date 2024-08-30
2024-09-30 09:32:40 : INFO : microsoftautoupdate : ################## Version: 10.6
2024-09-30 09:32:40 : INFO : microsoftautoupdate : ################## Date: 2024-08-30
2024-09-30 09:32:40 : INFO : microsoftautoupdate : ################## microsoftautoupdate
2024-09-30 09:32:41 : INFO : microsoftautoupdate : setting variable from argument IGNORE_APP_STORE_APPS="no" LOGGING="INFO" SYSTEMOWNER="0" NOTIFY_DIALOG="1" NOTIFY="success" INTERRUPT_DND="yes" LOGO="appstore" REOPEN="yes" BLOCKING_PROCESS_ACTION="tell_user" PROMPT_TIMEOUT="86400"
2024-09-30 09:32:41 : INFO : microsoftautoupdate : BLOCKING_PROCESS_ACTION=tell_user
2024-09-30 09:32:41 : INFO : microsoftautoupdate : NOTIFY=success
2024-09-30 09:32:41 : INFO : microsoftautoupdate : LOGGING=INFO
2024-09-30 09:32:41 : INFO : microsoftautoupdate : LOGO=/System/Applications/App Store.app/Contents/Resources/AppIcon.icns
2024-09-30 09:32:41 : INFO : microsoftautoupdate : Label type: pkg
2024-09-30 09:32:41 : INFO : microsoftautoupdate : archiveName: Microsoft AutoUpdate.pkg
2024-09-30 09:32:41 : INFO : microsoftautoupdate : no blocking processes defined, using Microsoft AutoUpdate as default
2024-09-30 09:32:41 : INFO : microsoftautoupdate : name: Microsoft AutoUpdate, appName: Microsoft AutoUpdate.app
2024-09-30 09:32:41.643 mdfind[72572:12026448] [UserQueryParser] Loading keywords and predicates for locale "en_US"
2024-09-30 09:32:41.643 mdfind[72572:12026448] [UserQueryParser] Loading keywords and predicates for locale "en"
2024-09-30 09:32:42.189 mdfind[72572:12026448] Couldn't determine the mapping between prefab keywords and predicates.
2024-09-30 09:32:42 : INFO : microsoftautoupdate : App(s) found: /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app

[Artos254]

Performing more investigation, it looks like the local logs are recording just fine with or without MS AutoUpdate exempted, but fail to continue in Jamf if it is within patching scope (aka not exempted). I understand that Jamf isn't your platform to support, but I was just curious if you had any ideas why that might be. Never run into this before, escrowed logs usually match local logs.