Policies don't run

I've been on 9.101 for a while now but I've only started seeing this since the recent Security Updates from Apple. I can't say that is definitely the point it started but that's the only major change that's happened before I started seeing it.

Side note as you aren’t a newbie...in my earlier days I had this happen and my DP had a failing hard drive. I’m guessing you checked your DPs functionality but it may help other folks.

I’m on 10.0.0 and policies are still running in patched high sierra

Yeah all our server drives are constantly monitored and they are all fine. Thanks for the tip.

Running into the same thing as of this AM. I am also on JSS 9.101 and 10.12.6. I try to re-run 2018-001 Security Update over and over in Self Service. When I click install, it zips right through, and the policy doesn't leave Self Service. I've rebooted and tried with the same result. I noticed if I leave it plugged in, it will eventually install -- I have the policy set for reoccurring and Self Service. A Sudo Jamf Policy doesn't force it.

This isn't a case of the policy blackout window coming into play is it? The policy didn't fail previously on these same Macs did it?

Not for me. I just checked and the Security 2018-001 was pushed about an hour later.

No, there's no blackout or previous failures. The scopes don't have any groups excluded where the computer could hide. All these policies worked just fine before recently. The icons for the policies show up in Self Service and they go through the motions but they fail to actually DO anything and no where anywhere is there any log entry of success or failure.

Are the policies on Self Service only?

I played around with this by re-enrolling the Mac via a Quickadd.pkg, then running all the policies again. Or, I disable the problematic policy and created a new one. Both aren't ideal, but maybe this gives some insight into the problem.

I just found a Mac where NONE of the policies run! None in self service, and none as event triggers. I did removemdmprofile, mdm, and manage with no change. This is getting serious. I can't remove the framework and then re-enroll Macs to fix this because the enrollment process overwrites changes that have been made since the user got their Mac.

Hopefully it's a one-off, and not many.

That's the problem, it's not a one-off. More and more Macs are showing this behavior and the logs show NOTHING at all. Not even a failed attempt. The one I found today just happens to be the worst affected.

...

@AVmcclint Have you checked to see if this is related to the Security Updates changing the UUID on devices as has been reported elsewhere? I would pull up one of the affected Macs in your Jamf console and locate the UDID string, then run ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}' in Terminal on the affected Mac. Compare the 2 UDIDs to see if they match.

Second, you might have mentioned this already, but, do you have a case open with Jamf support on this? If not, I would do that to get something going with them. They might be able to help you figure out what's going on here. I would be concerned if I saw Macs stop running policies. Without being able to run policies effectively, the product loses a lot of it's usefulness.

There must be something different on the affected Macs vs ones that are working ok. Have you taken a look at the Jamf device signature? I'm not sure how to actually check it to make sure it's still valid, but if you have access to one of these Macs, are you able to force inventory submission? Usually if the device signature is bad, inventory won't work either in my experience.

Also, what changes get overwritten by re-enrollment? It sounds like re-enrollment might be your only valid option for at least some of these. Trying to understand why that isn't feasible for you.

The UUIDs do match. I don't have a case opened because I don't have anything to give at this point - logs aren't showing anything at all.

However, something did just happen. I got fed up with the Mac that wasn't running any policies at all and I left it in our IT lab plugged in and logged in while I worked on other things. A few hours later i decide to check some things on it and I discovered that the policies ended up running on their own at some random Check-in an hour or so later. There were a couple policies not set to run at Check-in so I ran them from Self Service and they worked. This is very strange, but I'l just have to see if a wait-and-see approach will let them eventually run. I'm hoping to upgrade to JAMF Pro 10 in the next couple weeks so maybe that will solve whatever glitch is happening in 9.101.

I am in the same scenario. Eventually, the policies will run on it's own after a bit. Curious, is your JSS on premise?

Yeah it is our own Windows 2012 server as are the distribution points.

Just ran into a Self Service policy that just ran right through and said completed. I disabled the policy, saved, then re-enabled. Tthe policy installed okay after that.

I just discovered that this is still happening under 10.2.1! This time, instead of there being no errors, after the policy "runs" it says "This item is no longer available" But the item still appears in Self Service, the app was not installed, and there is absolutely nothing in the logs. HOWEVER, disabling the policy on the JSS then re-enabling it does NOT fix it. Oh boy.

When I try to run the policy as a trigger, this is what it says

MacName:~ RJ$ sudo jamf policy -event RDP -verbose
 verbose: JAMF binary already symlinked
 verbose: JAMF agent already symlinked
 verbose: Checking for an existing instance of this application...
Checking for policies triggered by "RDP" for user "admin"...
 verbose: Checking for active ethernet connection...
 verbose: No active ethernet connection found...
 verbose: Removing any cached policies for this trigger.
 verbose: Parsing servers...
 verbose: The Management Framework Settings are up to date.
No policies were found for the "RDP" trigger.

The policy does exist and RDP is the correct trigger and I have confirmed that the computer has NOT run the policy before.
I plugged the computer into Ethernet and ran it again:

MacName:~ RJ$ sudo jamf policy -event RDP -verbose
 verbose: JAMF binary already symlinked
 verbose: JAMF agent already symlinked
 verbose: Checking for an existing instance of this application...
Checking for policies triggered by "RDP" for user "admin"...
 verbose: Checking for active ethernet connection...
 verbose: Active ethernet connection found...
 verbose: Removing any cached policies for this trigger.
 verbose: Parsing servers...
 verbose: The Management Framework Settings are up to date.
No policies were found for the "RDP" trigger.

Still no change.

Since you've been dealing with this for a month - I'd highly recommend contact Jamf support and opening a case. You might not have any "logs" to show but part of the reason we all pay so much for jamf is so that you can pick up the phone and have someone help you out!

When I've seen issues with policies completing in zero seconds, it turned out to be related to having cruft in:

/Library/Application Support/JAMF/Downloads

or maybe it was...

/Library/Application Support/JAMF/Waiting Room

Even if the files shown in those directories are not related to the policy that was failing, I learned that deleting them would resolve the issue. I suspect it more likely for items in the Downloads folder.

If you have any Antivirus or security agents on the client, as a test, temporarily exclude those locations from real-time scanning.

Check both locations, delete any files within them, and see if that resolves the issue with the policy.

I checked those locations and they are empty. Unfortunately excluding the folders in McAfee takes an act of congress around here.

@AVmcclint, I've seen this happen on occasion in our environment (9.97). Generally it's when a policy has been cancelled from running (Ctrl+C while running a sudo jamf policy command, or more commonly, when a Self Service policy is cancelled through the UI), and then reattempted. The "solution" is similar to @mvu's, except I don't even bother with disable-save-reenable-save. I can literally just click Edit on the policy, then click Save, and it will work on the Mac that's having the issue.

The strange thing is that the policy will continue to work on other Macs without having to do the Edit/Save, and on the affected Mac other policies will run successfully (I'm pretty sure). The issue with the particular policy on the affected Mac eventually "times out" after about about an hour, and then the policy actually does what it's supposed to. I could swear there's a known issue on this, but I can't find it right now.

Edit: Search for PI-003515. Apparently, this is a known bug, supposedly only for JSS 10.2, but I'm seeing this in 9.97:

[PI-003515] When a policy doesn’t complete successfully, future occurrences of that policy will not be available for a period of up to 60 minutes. Workaround: Edit and save the existing policy.

Just stopping by here 3 years after this thread was created...I STILL see this happen on 10.26...every time I try and push a zoom update at recurring check-in, there will be maybe 50% of my deployment just won't run it for DAYS or ever despite the fact that I see the clients checking in. I even have 65 Mac Minis that are ethernet that have wake on lan enabled and the same thing happens with those. I'm probably going to have to go in on the weekend into each classroom with a Mac Mini and manually install those by hand...thanks Jamf, yeah, saving me LOTS of time for sure....

Same here, computer check's-in but the policy won't run, Following this thread to learn..