Jamf Pro 11.30.2 (Jamf Cloud),
SYMPTOM
An App Installer deployment stays IN_PROGRESS forever after the install has
already completed successfully on the Mac. Once stuck, Jamf never issues another
InstallEnterpriseApplication for that (Mac, title) pair. retryable is false, and
per the docs "Retry all failed" does not cover in-progress deployments, so there
is no way back other than toggling the deployment off/on (a PUT to the deployment
re-dispatches it within minutes).
WHAT MAKES THIS DIFFERENT FROM THE USUAL "STUCK IN PROGRESS" THREADS
We can point at a trigger. From /var/log/install.log on an affected Mac:
until 2026-07-12: Will start wait for 1 apps to close with timeout: -1.0
from 2026-07-13: Will start wait for 1 apps to close with timeout: 172799
July 13 is the day we set a global update deadline of 48h (previously: no
deadline, so timeout -1 = wait forever). Every stuck deployment we have dates
from after that change. With no deadline, the install only ever happened when
the user closed the app, and the state always closed correctly.
CLIENT-SIDE EVIDENCE (Google Chrome, one Mac)
23/07 16:23 Will start wait ... timeout: 172799 (48h deadline starts)
25/07 16:40 App termination monitor - start timeout wait 1.0 seconds (deadline hit)
25/07 16:57 Installing PKG package did finish ok.
25/07 16:57 App installer service did finish task with success.
-> then 16 days with zero InstallEnterpriseApplication commands for Chrome,
while the same Mac kept receiving and installing updates for other titles.
The install works. The server-side state never closes.
IT IS NOT A MISSING INVENTORY RESPONSE
That same Mac completed 110 InstalledApplicationList commands between 25/07 and
10/08 while the deployment stayed IN_PROGRESS. The responses arrive; they just
don't seem to be applied to the wedged deployment.
IT IS NOT SELF SERVICE ONLY
Across 1,101 installations: 24.3% stuck on INSTALL_AUTOMATICALLY deployments vs
21.1% on SELF_SERVICE. Both distribution methods are affected roughly equally.
IT IS NOT OUR CONFIGURATION (as far as we can tell)
- Healthy and wedged deployments have byte-identical settings across all 16
fields (deadline 48, notify 24, quitDelay 5, suppress false, relaunch true,
same smart group, same installPredefinedConfigProfiles).
- Notification settings requirement is met (NotificationsEnabled = 1 for
com.jamfsoftware.selfservice.mac).
- Collect unmanaged apps is enabled (so not PI-232 / PI110772 from 11.29.0).
- No overlapping scopes; no title has two deployments.
- The only variable that changed on July 13 was the deadline. The profiles that
disable in-app updaters predate it by three weeks and caused no issue.
WHAT CORRELATES
Apps users keep open all day: 34.2% stuck. Apps opened and closed per task: 6.3%.
A 5.4x difference. Only the first group ever reaches the deadline and the forced
quit — which is exactly the code path that seems to lose the state update.
QUESTIONS
1. Is the state transition to INSTALLED known to be unreliable when the install
completes via the deadline-triggered forced quit, as opposed to the user
closing the app on their own?
2. Is there a supported way to recover a wedged deployment for a single Mac,
rather than toggling the whole deployment (which re-dispatches pending updates
to the entire scope at once)?
3. Is PI121695 (fixed in 11.10.2) related, or is this a separate issue? Ours
affects both distribution methods, whereas PI121695 reportedly spared Self
Service.
Happy to share the full install.log excerpts and the per-deployment status dump.