Policies not found after flusing out a failure

kmabe
New Contributor III

I'm on 9.98 and currently testing machines on macOS Sierra. Since the upgrade, I've noticed when a policy fails for whatever reason and I flush out the failure, the computer returns to the pending queue but the policy never reruns. Even running a sudo jamf policy on the computer returns "no policies for the recurring check-in trigger".

Is anyone else seeing this? This did not occur prior to our upgrade to 9.98. The only way I have found to get it to re-try is to delete the computer, re-enroll, run a recon then policy trigger again.

11 REPLIES 11

tobiaslinder
Contributor II
Contributor II

Hi @kmabe We see exactly the same behavior on our machines. We can provoke it with "sudo killall jamf" but also without this many machines just suddenly stop running policies. We are now in contact with jamf to try to get to the source of the problem.

The_Lapin
New Contributor III

I've been seeing the same behavior sporadically through 9.98 and still with 9.99.

kquan
Contributor

i've noticed it on 9.99, i've had to uncheck/recheck the "Enable" policy and it works. it's a bit annoying

jphillips
Release Candidate Programs Tester

We've been seeing this too (9.98), and it's not just flushing the logs. It happens all the time to me while editing a script that might be attached to the policy.

I've found the just by going to the policy, clicking edit, and then immediately clicking save, the policy works as expected until another change is made. Very frustrating.

The_Lapin
New Contributor III

I've noticed this more and more over the past couple weeks. It doesn't seem to be limited to failures that are flushed out, I'm also seeing it on freshly enrolled Macs that have never run the policies before.

Checking the management section for the Mac in JSS, Policies will show a dozen or so in scope, most of which are triggered with the recurring check-in. Run sudo jamf -policy -v on the Mac in question will return "No policies were found for the "recurring check-in" trigger." Running a recon then trying again yields the same result.

I just tried kquan's fix of un-enabling/re-enabling the desired policies and that seems to work but something is clearly buggy. It's not all Macs / policies though, really does seem to be randomly failing to detect policies in it's scope.

The_Lapin
New Contributor III

(duplicate post)

tania_dastres
New Contributor

I'm seeing this with 9.99, and it's very annoying.

If I change the custom trigger, or disable and reenable the policy, it works.

mm2270
Legendary Contributor III

I see this a lot myself (9.99.0). It's very annoying, because it's like we can't really rely on the scope of a policy. Even when a machine is sitting in the Pending state for a policy, the jamf binary just won't recognize that it needs to run that policy. This even happens with policies that use a custom trigger or calling it directly by it's JSS ID.

I don't know what causes it, but would love to see this prioritized and fixed. It makes it tough to feel confident that policies will fire off in a timely manner as we expect, or even sometimes fire off at all. We cannot be expected to go into policies and click Edit > Save or Edit > Disable > Save and then reverse it each time this happens. That's not a workable situation.

emily
Valued Contributor III
Valued Contributor III

Yep, the trick is to "Edit" the policy then "Save." This was posted somewhere else I think, but if a policy fails there is some kind of timer that prevents it from running again for about an hour or so. The timer gets reset if you "Edit" the policy (you don't have to change anything, just click the button and save).

mthakur
Contributor

@emily and others commenting above:

There are at least two bugs here:

  1. The internal timer is failing to reset automatically after a failed policy is flushed.
  2. There is no error message or warning, either in the JSS or on the endpoint, that informs the administrator that a pending policy isn't actually being executed because of this internal timer.

Impact: The clear intent of the administrator is being superseded: Flushing a policy means the policy should be re-run, either manually or automatically, in short order. Even worse, the administrator isn't informed that the policy isn't actually being run.

Does anyone know whether the above issues have been submitted as bugs to JAMF?

And more imporantly, have they been fixed in a more recent release, e.g. 9.100 or higher? I'm experiencing it on 9.97, and others above indicate 9.98 and 9.99 are affected.

steve_summers
Contributor III

FWIW, I'm on Jamf Pro 9.101 and still seeing this. I have a policy that runs a script and a condition in my script will call a policy (to install something) via the Policy ID. I'm seeing "No polices were found for the ID..." but it's there, the policy exists with that ID.

@emily I've tried the recommendation you have here and hopefully it'll work. Thanks.