Anybody know why this is happening? The same policy I'm running to get this result works on other computers. I've restarted, re-enrolled, updated inventory. Same result.
Question
Self Service - This item is no longer available.
+9+8Is it set to once per computer? Perhaps clear self-service cache and/or remove JAMF framework before re-enrolling.
+7I experienced this yesterday too. It only occured on a policy I had sert to cache (Make available offline). I unchecked that option and it has been working fine since. Not sure if you are experiencing the same
+1I've tried clearing cache, changing the cache options with this and it still fails to install the software I'm trying to install. Two days ago it ran fine. Now today, fail. Any ideas?
Self Service seems to think it's installed. If I try to reinstall it crashed Self Service.
+4We 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...
+23Having the similar problem with JP10, but seems to be only affecting one policy (that has a lot of scripts and package installs). Sometimes it seems a reboot or two will allow the policy to run, other times not.
reopened my ticket with jamf on it.
+1We experienced a similar issue after upgrading to JAMF Pro. We ended up recreating the self-signed SSL cert That did the trick.
+2I'm getting this error as well on a factory-imaged Mac running 10.13.1 with the latest security patches. It looks like any policy that installs a .pkg is failing - my other policies that use a .dmg work just fine.
+2I 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.
+23edit the policy and save it (don't make changes). then try Self Service again..
+2I've tried editing and saving the policy as suggested by jwojda but still get the error. Jamf also suggested flushing the policy logs but still the same error.
+1We have been seeing this more and more. The policy will normally run fine after a reboot. Still investigating.
+4I'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.
+9Yes, the Self Service policy in my OP is to force a Check-In. It just runs "jamf policy" in the Execute Command field in Files and Processes.
+14@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?
+5I 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.
+8I'm getting the same error as well. I scope the policy to usernames, so Ive logged into 4 Macs using the same username and get the error on 2 of them, but it works correctly on the other 2.
I have upgraded to Jamfpro 10.
It errors on my 10.13 VM and a mid 2017 iMac running 10.12.
+2We 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???
+14@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?
+6We are also having this issue and will be opening a case with JAMF Pro 10 and this issue with SS policies. I have also found that it seems to be related to limiting to LDAP groups, if you limit to LDAP user it works fine.
+2We 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.
+7We're seeing this issue with JAMF Pro 10.1.1... The fix that works for us is to clone the policy, and delete the original.
+2Has anyone found a solution to this problem? Or is the "clone" thing the only workaround atm?
Jamf support has nothing on this.
/Martin
+2We 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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.