Deferral limit reached, but no message show up anymore

I haven't tested it that thoroughly but it does sound like a bug.

@Dalmatian I'm also seeing this behavior, did you ever find a fix?

@mapurcel I ran into a defect (D-010208) where policy deferrals would not work properly. You might want to talk with your TAM and see if they have any update on when the issue will be fixed. I haven't had a chance to read all the release notes for 9.93 to see if the issue is resolved or not.

@mpermann thanks - appreciated. I've brought that defect to the attention of my TAM and he is researching now..

Any update on this?

Hey all,

The defect mentioned further up (D-010208) was closed as a duplicate of PI-002382. If you're seeing this issue and want to open a case or already have a case open with your TAM or STAM, please reference PI-002382 instead of D-010208.

PI-002382 is listed as being in the list of things fixed for JSS 10 so, until JSS 10 is released, we'll continue to see the behavior described in this thread where deferrals are concerned.

Thanks!
Amanda Wulff
JAMF Support

I also noticed now since we recently upgraded from 9.81 to 9.96 that if a user CMD Q's the notification and the policy is set to once per machine.

When checking the policy logs in the JSS it says complete in the logs with blank info for that record and the policy will no longer run.

In version 9.81 if the user quit the notification the policy would re-run at the next check-in.

@myronjoffe I didn't realize someone could CMD+Q out of the Management Action dialog box (though it does not seem to work in OS X 10.9). I just did some testing, on a OS X 10.11 system, with a "Once per computer" policy on JSS 9.93, and here's what I found:

When I quit out of the dialog box, even though I didn't choose a deferral option, an entry is still written to /Library/Application Support/JAMF/.userdelay.plist with the policy ID and a date entry which corresponds to the current date and time (in Zulu Time, a.k.a. GMT). The JSS shows the status of the policy as Complete with a blank line when I click "Show" to see what the policy did on the system.

(I'm not sure if version 9.81 also writes the policy ID and current date/time to .userdelay.plist, but it's probably moot since a subsequent attempt to run the policy will be past that point in time. I'm assuming the reason that the policy runs again later after quitting out of the dialog box on version 9.81 is because the policy is not being marked as Complete, unlike on version 9.93.)

If I try to run the policy again on the system, it will not run again since it's "Once per computer" and considered Complete by the JSS. But if I flush the log first, then the policy will run again. So the issue with the policy being marked as Complete when canceling the Management Action dialog box is still there, but otherwise things function basically as expected.

Back to the original issue, which we're seeing as well on 9.93 and have reported to our TAM: If an user defers a Management Action prompt for a period of time and then that time has passed, the prompt does not reappear as expected, on policies set to "Once per compute" since JSS records the status as Complete (with blank details) when the prompt is deferred. Waiting on next release for permanent fix.

In our situation, a software update was scoped to a large number of computers, which prompted users to apply the update. Those who deferred will never be prompted again to apply the update since the status has been marked Complete, and the policy is set to "Once per computer".

To work around this, if we flush the logs for the policy, then computers that check in again should attempt to execute the policy. However, when they originally deferred, the deferral time was written to .userdelay.plist. And if the deferral time is still in the future when the policy is triggered again, the policy immediately gets marked as Complete again without running, and we're in the same situation.

So in order for these policies to prompt again and actually execute, we have to both flush the logs and delete .userdelay.plist. (We could also just wait until the latest possible deferral time and then flush the logs, but that puts this off too long.)

All that being said, instead of deleting .userdelay.plist and flushing the logs, we are experimenting with setting the frequency to "Once every day". Since that's based on how long between policy log submissions to the JSS, it's harder to test in a shorter period of time, so I don't know what the interaction will be with the entries in .userdelay.plist.