Policies not found after flusing out a failure

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.

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

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

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.

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.

(duplicate post)

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.

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.

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).

@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.

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.