Update schedule not found

On some Macs, App Catalog stops running its hourly update check while continuing to look completely healthy: the app opens, users can install and update apps by hand, and the device keeps reporting in. Only the scheduled run is missing, so apps quietly stop being patched and mandatory apps stop being enforced.

This affects App Catalog 1.11.2 and earlier. It is fixed in 1.11.3.

Symptom

Running sudo catalog schedule-status reports:

Update schedule not found

This happens even when your configuration profile is completely correct — UpdateInterval set to 1, a valid authorization key, and the background item approval profile in place. The profile is not the problem.

Cause

The update schedule is registered once, when App Catalog is installed. That registration could fail without reporting an error, most often when the package was installed while nobody was logged in — during enrolment, or a pre-login deployment. Nothing retried it afterwards, so the Mac never ran a scheduled update check again.

Because everything else keeps working, there is no visible sign that anything is wrong.

Finding affected Macs

Deploy this as an MDM extension attribute or script. It has to run as root, which MDM scripts already do. If you run it by hand in Terminal, prefix it with sudo.

#!/bin/zsh

if [[ ! -d "/Applications/Catalog.app" ]]; then
    echo "NOT_INSTALLED"
elif /bin/launchctl print system/nl.root3.catalog.agent &> /dev/null; then
    echo "OK"
else
    echo "AFFECTED"
fi

The script reports NOT_INSTALLED separately, so Macs without App Catalog do not show up as affected. This is the check to rely on for scoping a fleet.

On an individual Mac, sudo catalog schedule-status gives a quick read as well and should report Update schedule is enabled. Where the two disagree, the script above is authoritative.

Recovering a Mac

Run this while a user is logged in. No reboot, nothing visible to the end user. Deployed through your MDM it already runs as root, so the sudo below is only needed when you run it by hand.

#!/bin/zsh

console_user=$(scutil <<< "show State:/Users/ConsoleUser" \
    | awk '/Name :/ && ! /loginwindow/ { print $3 }')

if [[ -z "${console_user}" ]]; then
    echo "No user logged in - run this while someone is signed in."
    exit 1
fi

uid=$(id -u "${console_user}")
agent="/Applications/Catalog.app/Contents/Resources/Catalog Agent.app/Contents/MacOS/Catalog Agent"

sudo launchctl asuser "${uid}" "${agent}" schedule-enable
sudo "${agent}" schedule-status

The registration has to run inside the logged-in user's session, which is why launchctl asuser is used. Running the command as plain root fails with SMAppServiceErrorDomain Code=3 "No such process".

Please do not use sfltool resetbtm

It does not resolve this issue, it requires a reboot, and it resets background item approvals for every vendor on the machine.

Permanent fix

App Catalog 1.11.3 installs the update schedule as a regular background service through the installer package, which removes the dependency that caused the failure. Installing and upgrading behave the same whether or not a user is logged in, and affected Macs recover automatically when they receive that version.

One exception: a Mac without a working schedule cannot fetch the update through App Catalog itself, because the schedule that would fetch it is the one that is broken. If you update App Catalog through App Catalog rather than through your MDM, push 1.11.3 from your MDM or run the recovery command above.