Self Service - This item is no longer available.

[nvandam]

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.

[kowsar_ahmed]

Is it set to once per computer? Perhaps clear self-service cache and/or remove JAMF framework before re-enrolling.

[rickwhois]

I 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

[aetnde]

I'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.

[NPU-Casper]

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

[ImAMacGuy]

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

[tech_services]

We experienced a similar issue after upgrading to JAMF Pro. We ended up recreating the self-signed SSL cert That did the trick.

[systems_support]

I'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.

[systems_support]

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.

[aetnde]

Must be nice. That didn't work for me :(

[ImAMacGuy]

edit the policy and save it (don't make changes). then try Self Service again..

[systems_support]

I'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.

[CBing]

We have been seeing this more and more. The policy will normally run fine after a reboot. Still investigating.

[theguvnor]

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.

[nvandam]

Yes, 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.

[NoahRJ]

@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?

[clarkep]

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.

[a_simmons]

I'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.

[m_gunnarsson]

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???

[NoahRJ]

@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?

[rymoe001]

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

[a_simmons]

Does anyone know if this was fixed with Jamf Pro 10.1.1

[TPoustie]

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.

[WhippsT]

We'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.

[m_gunnarsson]

Has anyone found a solution to this problem? Or is the "clone" thing the only workaround atm?
Jamf support has nothing on this.

/Martin

[TPoustie]

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.

[btaitt]

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.

[musat]

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

[RobinMonks]

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

[a_simmons]

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

[admindaly]

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.

[mh314]

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

[kwoodard]

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.

[lashomb]

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.

[howie_isaacks]

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!

[gokoudes]

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!

[kwoodard]

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

[gokoudes]

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

[kwoodard]

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

[kwoodard]

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