I started encountering this with some policies as well, and it does seem to match a few of the things listed here:

• It is a pkg file


• Unchecking "make available offline" and saving seemed to resolve it.


• It started happening after using Jamf 10

I'll create a ticket with Jamf. If someone else has tickets to reference I can bring that up and maybe we can see if this becomes a product issue.

Following this thread as this has started cropping up here as well.

I have this happened on a basic pkg now too, with no special options checked.

@RobinMonks do you scope your policies to AD groups? If you do, we found the only way to stop this happening was to force the users to login to Self Service.

We are seeing this too. Editing the policy and saving without making any actual changes seems to work for us so far.

I wonder if it a timeout issue. We are seeing it when we try to onboard to many users at a time to the network. If they are all trying to install larger apps over the Wi-Fi then sometimes those apps become unavailable.

I figured I'd just say that we are seeing this issue consistently on a policy that has 8 packages associated with it. This policy is scoped to all managed computers limited to AD users in IT Staff.

Doesn't matter which DP we use (JCDS vs in house DP). I'm thinking it is getting cranky with the 8 packages honestly.

Update: I totally missed the fact that for some reason when our computer went through pre-stage it wasn't getting managed..... after I realized this and manged the computer the policies started running. facepalm

Started cropping up today for us. This morning we updated our server to 10.2.1... Seems to take a couple restarts of the client computers for the error to go away. Very frustrating, especially if its a policy that runs without user interaction.

This is a known issue in the 10.2 release notes, although we discovered the edit policy workaround by chance.

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

I thought I read through the release notes thoroughly before upgrading, so I did not see the reference to the known issue. I ran into this issue yesterday. Now I have to test all of my self service policies. What fun!

This appears to be working for us so far - tested by intentionally interrupting/cancelling a Self Service policy. Previously, would give us the dreaded "no longer available" error every time for a period of 60 minutes, after which the Self Service policy would allow execution again.

After running these mySQL commands, we are no longer observing the "no longer available" error after interrupting a Self Service policy.

Please reach out to your Jamf Buddy for guidance if needed, and please back up your databases before doing this --

<path-to>mysql -u root -p

From within the mySQL shell:

use <DatabaseName>; 



DELETE FROM jss_custom_settings WHERE settings_key = 'com.jamfsoftware.jss.objects.policy.blackoutPeriod'; 



INSERT INTO jss_custom_settings (settings_key, value) VALUES('com.jamfsoftware.jss.objects.policy.blackoutPeriod', '0');

The default blackout period value is '60' - adjusting this to '0' has so far eliminated that error message, but you may want to monitor policy usage to make sure you don't have trigger happy end users since there is no more waiting period between duplicate Self Service policy requests.

I hope this helps!

So what seems to be causing the issue? I only use one self service item right now. It runs a script to see if a driver package is installed and if it is, printers are added. If the driver is missing, it will be installed before the printers are added. We see this issue on computers that do not have the driver package already installed (or the odd user on OS 10.9). If I manually send the driver package, the script usually works. If not, it will fail like this...every time. Even after waiting an hour or a day...

@kwoodard hmm, I'm unsure, there. Our symptoms were pretty consistent, and testing through the course of today, I've been able re-run 3 culprit policies after the 60 minute period. Testing the same way after these SQL commands - no more Self Service error stating "no longer available.."

Our interruptions to policy installs are usually a handful of people who tend to stop and start their Self Service installs between wake-sleep and between physical wireless AP's on campus. We have a few who clicked cancel for <whatever> reason.

Since you have the one primary policy, have you tried re-creating that policy from scratch as new? (no cloning) We had some luck with that prior to this SQL tweak..

@gokoudes, I have not rebuilt the policy. I have gone in and edited each piece and saved, but the issue seems to persist. Did not have this issue in 10.1.

Well, the only work around that seems to work with our system is to completely redo the policy. Modifying the existing policy isn't enough...

Anybody else try running through the MySQL commands @gokoudes mentioned above? I'd like to see it resolve the issue for a couple more folks before we try it in our environment.

Noah, we are giving it a try today.

Had this problem in 10.1 today. Editing and saving the policy with no changes worked for us as well.

Some follow-up - this seemed to work well for us until last night, when we upgraded to 10.2.1. Started seeing these errors creep back.

I re-ran those SQL blackout commands and restarted Tomcat and MySQL. So far, I've had to edit/save one culprit policy even after these SQL commands, but that seems to be it for those errors so far. Will update again with any new findings..

We are running into the issue here as well. As our Jamf Pro is hosted, we are not able to run the SQL commands.

Sorry found the post !!!

C

I tried the SQL commands because there's a script we have in Self Service that users run but if they exit out before the script finishes they obviously get the "This item is no longer available" screen. I tried the SQL command but that didn't solve the issue.

It’s frustrating that we don’t have a JAMF person in this conversation. When we called support, they had no clue about the issue. Seems pretty widespread.

Just been upgraded by Jamf to 10.2.2 this weekend and unfortunately this issue persists in that version, too.

That's frustrating. Only work around that I have found is to make a new copy (not a clone) of the policy and delete the old one. Some folks are lucky enough to be able to edit the policy and save.

Unfortunately I'd already tried that, same issue exists with a new copy of the policies in question :(