We just experienced this as well.
Yesterday I was running self-service policies on a MBP cart of about 30 machines and all but one of the machines in the cart was able to apply the self-service policies, the one that could not apply the policy started showing that same message "This item is no longer available"
Everything on the backend looks good though, machine entry shows up on pending on the policy logs and policy shows up in self service but weird it does not run especially since it worked on the other machines...
UPDATE: Had a ticket with Jamf to get them some logs, so walked over to the machine in the cart and tried running the Self Service policy, and sure enough, it worked with no issues, classic...
I opened a ticket with Jamf and they had me run in Terminal on the affected machine sudo jamf policy -id 1391 which matched the ID in the policy URL. The result was "No policies were found for the ID 1391." I deleted the policy and created a new one with the same .pkg installer and it now works. Very strange.
I've been getting this as well in Self Service since the v.10 upgrade, the policies carry out correctly but bring up the 'This item is no longer available' warning when they complete.
Have done some testing on it this afternoon and found, for me at least, this only occurs with policies that have the 'Files and processes' option selected, e.g. a package install that also runs a command at the end, such as to license the software etc. Removing that option from an existing policy where it was happening stopped me getting the warning.
I then created a completely new policy solely with the 'Files and processes' option in it and a command in, put it into Self Service and ran it, and got the same warning.
Will continue investigating.
@theguvnor I can confirm I ran into the same issue with a SS policy that had a Files and Processes option set. Deleting that option and moving it to a post-flight script resolved the issue I was seeing. That's a pretty egregious bug (among all the others in Jamf Pro 10); has anyone opened a case with Jamf over this detailing that information?
I am having this issue as well, except we are not running any additional commands. Just like everyone has said, it runs fine for some users and not for others. Since these are student computers locked down (standard users), they are all running Sierra. We also updated to JamfPro v10 last week. In this situation, we are trying to install Adobe Illustrator--very larger pkg at 2.6GB.
We are seeing the same issue on 10.12.6 clients with Jamf PRO 10. When we scope to LDAP groups this issue presents it self, when scoped to all:all the issue goes away. Only workaround that has worked so far! Asked Jamf support about this yesterday and if it is a known PI, but no. They have not seen it before???
@m.gunnarsson Can confirm that we had some issues, albeit intermittent, with setting LDAP group limitations and seeing the same Self Service bug. Removing the LDAP limitation allowed the policy to run successfully, but this is a pretty huge issue. Did you open up a case with Jamf to investigate this?
We have also been seeing it when scoping to LDAP groups, but only on Macs that were built / enrolled after we updated to JAMF Pro 10. Any Macs that were built / enrolled in version 9 seem to work fine.
In testing we found that if we enable sign-in for Self Service, once you sign in with the LDAP account the policy runs correctly. With sign-in turned off we get the error. This makes me think that for some reason it's not passing the username through correctly when you're not signed in.
We have opened a ticket with JAMF and are also looking at updating to 10.1.1 so hopefully will have some answers soon.
We have found that enabling users to logon to Self Service fixes the issue, so we are currently forcing logon and are in the process of setting up Single Sign-On.
We have raised it with JAMF support and this is their latest response:
Thank you for working closely with our US team this past week. We appreciate you bearing with us as we investigate. With the information and testing provided (thanks for that!), we're identifying this as an older Product Issue (PI-001899) where Policies limited by LDAP User or Group are visible in Self Service, but those policies fail to run unless the user authenticates to Self Service. Self Service understands that the user assigned to the machine in the JSS falls into the limitation for the Policies, but when authentication is not required to Self Service the machine fails to find the Policy. We're finding that forcing authentication allows the policies to run as expected, as you have also found. This was supposedly resolved in Jamf Pro 9.9; and I would believe that based on your own testing. Now that you're able to replicate this with Jamf Pro 10, I will need to investigate reopening the existing Product Issue. Unfortunately, until this is properly addressed by QA, I would suspect that our only workaround is forcing authentication.
In other words, using a workaround is currently the only way around the issue until JAMF release a fix for it at some point.
I started encountering this with some policies as well, and it does seem to match a few of the things listed here:
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.
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
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.
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..