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.

[NoahRJ]

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.

[kwoodard]

Noah, we are giving it a try today.

[tommrkr]

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

[gokoudes]

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

[nberanger]

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

[gachowski]

Sorry found the post !!!

C

[Over9000]

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.

[kwoodard]

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.

[theguvnor]

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

[kwoodard]

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.

[theguvnor]

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

[kwoodard]

And you are making the policy from scratch? Not using the clone option?

[adamlalicker]

I have tried the SQL commands and updating with 10.2.2 and no luck, anyone find a solution for this?

[nberanger]

I've got an ongoing support ticket open with Jamf support for this. So far we have had no luck in finding any sort of fix.

[theguvnor]

It looks like we may have found the root cause of this after much testing.

We originally had Self Service items (e.g. software packages) that were scoped to appear in the Self Service for 'All Computers'. At the end of the installation of one of these we were running some custom triggers in the 'Files & Processes' section of the item's policy, separated by semi-colons, to in turn install particular license packages scoped to a few different sets of computer groups.

We found that, if the machine on which you are running the Self Service item is in one of the scoped computer groups of the policies triggered by the semi-colon-separated commands but doesn't exist in one of the other groups then the Self Service will throw up the "This item is no longer available" message, although it will still go through with successful install of the item and running of the trigger. Equally, if you're only using one trigger command at the end of the item installation, but the machine isn't in any appropriate scoping group for the trigger target to run, the item will install but the trigger will naturally fail, and the message will be shown.

An easy way we found to test this was to have the test machine not be in the scoping group for a particular license package to run, but to also have an empty dummy policy scoped to 'All Computers' that had the exact same custom trigger as the license package one, thereby ensuring the test machine on which the Self Service item was being run was in-scope for at least something, albeit something that did nothing.

When the Self Service item installed and called that trigger, even though the computer wasn't in one of the regular scoping groups for licenses associated with the trigger, the fact it was in scope for the empty dummy policy temporarily associated with the trigger stopped the message from appearing.

All rather complicated, but it may be that other people experiencing this were running single or multiple commands at the end of Self Service items like us, but the machine on which they were running them was only in scope for one of the groups associated with the trigger target.

Fortunately, in our case, we were only doing this with Adobe apps, so now, rather than having, for example, three separate triggers the item called to install the appropriate license for a particular group, we now have one main licensing trigger and the dummy trigger to ensure the computer on which the Self Service item is being run is in-scope for at least something :)

[dsavageED]

I made a new policy with the following custom trigger call from "Files and Processes" option "/usr/local/bin/jamf policy -event No-Such-Trigger" we have no policies associated with "No-Such-Trigger" and so it will always produce the "This item is no longer available" error in Self Service.

Running the command in Terminal, Checking for policies triggered by "No-Such-Trigger" for user "username"...
No policies were found for the "No-Such-Trigger" trigger.

I think that the simple way to describe the issue is - "This item is no longer available" is to Self Service what "No policies were found for the "No-Such-Trigger" trigger." is to the command line. The v9.X Self Service application ignored these messages where as v10.X is warning the user that something maybe didn't work as expected.

The issue can be easily reproduced by adding a policy like my "No-Such-Trigger" one...

[rbean]

We are experiencing this same issue.
Jamf Pro 10.1.1 and all MacBooks are running OS X 10.12.6 with latest updates.
I have done everything suggested so far, Editing the policy and saving without making changes, No luck
Editing and saving with a change, then changing it back, No luck
Creating a new policy from scratch, 1st Policy No luck, after that, still no luck.
Cloning policy from existing one, 1st policy success, after that, No luck
After any/all of the above, also tried running from terminal with command 'sudo jamf policy trigger -id xxxx' but No policies were found for the ID xxxx
It doesn't seem to be happening on older policies, not sure how far back.
I can say that policies I created as recent as November 2017 are working.
Also, I don't have 'Files and Processes' set on any of my policies.

In desperation, I just deleted(uninstalled) and re-installed Self Service, and - No Change.....

I am unable to locate any logging for Self Service, either in the JSS or locally.
I have found, that there is a logs folder at /Library/Application Support/JAMF/logs/ but it is empty.
Also found /var/jamf/Library/Logs/, but it too is empty.
There is also a /Library/Application Support/JAMF/Self Service/ folder, but it is empty as well.
It would be nice to have the JAMF client and/or Self Service actually log things locally, as well as on the JSS.

[remyb]

We also experienced this issue and it turned out to be exactly what @dsavageED is describing two posts above.

[rbean]

I'm not seeing any more discussion regarding this issue.

Does that mean that I am the only one that this is happening to the DOESN'T use custom triggers, OR have 'Files and Processes' set for the policies that are acting this way?

Just curious, as the last couple of posts before mine seem to have been accepted as the answer.

[kwoodard]

No rbean, I still see it periodically. I don't use the "files and processes" area for anything, but occasionally I will use a custom trigger. My biggest policy that saw this error constantly used a custom trigger, but I have two others that I had to recreate that didn't use either one. Almost seems like the software has "off-days" where it just doesn't want to work, then other days were its fine.

[JBPiper]

I have a situation where:
When logged in as the machine's inventory user - Self Service fails "The Item is no longer available" for LDAP limited policies

I can log in as any other user (except the asset's owner) and the packages install fine.

Log back in with the registered owner's LDAP ID, the LDAP packages fail.

[kwoodard]

Now that is interesting. I have never tried to see if a different LDAP user sees the same issue. I will have to try that.

[lehmanp00]

We just updated to 10.2.2 from 9.101. We are seeing this error all over the place. Very, very frustrating. This is especially frustrating when I'm trying to get DEP 'imaging' working and none of the policies run!

[SegalCo]

I've see this on 10.2.2 for a policy set to "Once per computer" with an inventory update and it's like the Mac falls out of scope while the policy is running in Self Service and we're shown "This item is no longer available." Also, I've seen this on a cloned policy that was set to "Once per computer" but changed to "Ongoing" for the new policy — it seems to inherit the "Once per computer" and reproduces the "This item is no longer available."

[cgardner]

I just had this issue come up on two computers side by side. I tried cloning the policy, running recon, policy, and a few other things. Then I went back to my roots and just Rebooted the machine. This resolved the issue on both of the machines.

[kwoodard]

@cgardner You are fortunate. A simple reboot didn't help at all on any of the machines that I have had this issue with. The only solution I was able to come up with was recreating the policy from scratch.

[alexjdale]

We saw this prior to our 10.2.2 upgrade (I think when we hit 9.100 and then 9.101), and it seems to be less frequent but we are still seeing it for some policies scoped to LDAP group. Editing and saving the policy resolves it. The policy has no trigger or command execution, all it does is run a script. It's very annoying.

[marktaylor]

We are seeing this too on multiple policies, 10.3.1-t1522933524. Editing the policy and restarting machine does not fix for us!

[alexjdale]

I think I finally sorted this out. It's interesting behavior. This is on 10.2.2.

If two users are logged into the OS via fast user switching and the active user runs a Self Service policy, the policy will be executed three times. This is the core problem. The visible behavior varies based on the policy configuration and blackout period configuration.

If the policy is set to "once per computer" frequency or if it's set to "ongoing" and the blackout period is set to anything but 0 (or anything small enough that the policy trips it), the "this item is no longer available" message appears for the second and third execution because the policy is effectively no longer in scope. The blackout period acts as a limiter and operates on a per-computer, per-policy basis by temporarily removing a computer from the policy scope.

If the policy is set to "ongoing" and the blackout period is 0, the policy will execute three times in a row with three different jamf PIDs. Depending on what the policy does, the effects will vary. A pkg install will be installed three times. A script will run three times. In my testing, a script with a CocoaDialog element that requires interaction will appear to hang in Self Service with no UI elements appearing, but then if you cancel the policy it will run properly two times in a row with the UI elements appearing as expected.

I originally thought it was an intermittent bug, but this explains why we only saw it periodically and only with our LDAP-scoped policies: we only run Self Service with user switching when our techs are working on a system (but not every time), and they are the only ones who run LDAP-scoped policies.

[EddieDDUB]

I'm having this issue on 10.1.1 on 3 of our policies so far. I'm lucky enough, it seems, to just clone and delete the old for the policy to work. I was hoping for this to be patched in the later versions but looking at the posts here, it still exists.

[marcusbjerknes]

I've been having this issue as well, but for me it seems to be associated with the Mac computer not being correctly enrolled. Jamf has introduced some changes in 10.3 that I was totally unaware of. Updating the JSS server without first checking the release notes for changes is apparently not the best way to go...

So, once the computer got enrolled completely, the issue was gone.

Se this link for details;

https://derflounder.wordpress.com/2018/04/01/user-initiated-computer-enrollment-now-using-mdm-profile-enrollment-in-jamf-pro-10-3/

Cheers!

[Planet312]

We experienced this when scoping to users. Changing it to scoping to smart computer groups fixed the issue.

[kwoodard]

@Planet312 I wish that was the simplest solution... Although we do a couple static groups, we saw the issue in both static and smart groups. :/

[edullum]

I was also experiencing this issue on 10.4.1. When I create a new policy with the exact same options, it works.

[pmcavey]

Does creating a new policy always resolve the issue?

[kwoodard]

@pmcavey In my own experience, a newly created policy does resolve the issue. Might take two tries, but it does work eventually. Cloning hasn't worked at all. Neither has modifying an existing policy.

[seansb]

@alexjdale - The issue you described with fast user switching and Self Service installing multiple times is a known jamf defect: PI-004871. I would definitely get jamf to associate your account with this product issue. Not sure if the "This item is no longer available" is related, but I know what you described is definitely a jamf bug.

[pmcavey]

Is there something else that needs to be done other than just making a new policy. I created a new policy with a single package payload that I had just added to JSS through the admin panel. Still get this item no longer available.

[kwoodard]

Is the old policy still there? Maybe delete the old policy and create a new one again? I had to create a new policy a few times before it worked.

[pmcavey]

I deleted the old policy and created and deleted and re-created the new policy. Still erroring. My database may have some corruption. Is there a good way to repair the database?