Policy errors after policies have been disabled and/or not scheduled?

[rseide]

I'm getting Policy Error messages in the JSS 2 days after a couple of policies have been scheduled NOT to run AND when I've disabled them. In addition, I'm getting false errors reported as well.

Over the weekend, I scheduled patches to run from 7:30pm on Friday (8/16) to 2am Monday morning (8/19). I was still receiving policy errors yesterday after they were supposed to stop. So I went into the JSS and disabled all the ones that were supposed to run over the weekend.

This morning, I'm still getting a handful of policy execution errors that are from the policies I have stopped.

Also, I'm getting false errors reported too. These are on Adobe Air and Reader updates.

Is any of this normal? If not, what could be causing the issues?

Thanks in advance.

[talkingmoose]

Did you possibly enable this policy for offline use?

[rseide]

No. And I even removed any computers in the scope.

[nessts]

I have seen in the past, especially with policies that run at login, sometimes you have to wait for a second "check in" to get past policy changes.
If you think about it you set something to run, the database gets that record set, and if the computer never checks in during your execution window, that something to run is still waiting. And if the client itself knew it had to run something and was not turned on during the time it had to run it, it may say oh look i have not done this yet, thats what launchd does with some things.
Of course this is all speculation on my part. Maybe its a bug or enhancement request that needs to be entered, to ensure something that has a set range of time to run can only install during that time frame. Seems like you might want updates to run on one hand, and i can see instances where you might not.

[SamF]

You may also want to check if the logs indicate that they were not logged at the time of execution. If a machine that's executing a policy loses connectivity to the JSS it will store the log locally until it's able to connect at a later time. This should be indicated in the log, and generally means the policy failed as well. Hopefully, that helps to explain this specific scenario.

[mm2270]

^ What Sam said. That's pretty much what I was going to post. These are likely machines that already ran the policy but didn't get to upload a policy log at the end, or the policy started and just didn't finish somehow until recently. Possibly because the Mac was put to sleep or something like that. We see that on occasion ourselves when we disable a policy. Logs can continue to trickle in for a little while afterwards. I'd only be concerned if you continue to see lots of policy errors coming in that don't taper off.

[rseide]

Thanks, everyone!

I will check the logs and see what I can find. I also wasn't aware the some machines may be late in reporting to the JSS about the policy execution.