@nicholasmcdonald Same issue here, started after I patched to 10.7 (from 10.5)
Couldn't remove the limitation either so I had to recreate a bunch of policies from scratch to fix it...

@nicholasmcdonald I have the same issue and cant seem to fix it. Recreating policy has not helped..opened ticket with Jamf.

A policy has been set to once per computer for self-service. Please change that one to 'Ongoing' for self-self-service.

There's more than one thing that will cause this Self Service message to display, but one that effects our environment is if there's a Self Service policy that triggers within it another policy for which the machine is out of scope.

For example:

1. A Self Service policy to install app X that triggers an "Install Java" policy as app X requires Java.




2. A Java policy that excludes machines that already have it.

A machine without Java: Will run the policy, installing both Java and app X.

A machine with Java already: Will display "This item is no longer available" whenever the Java policy is triggered.

This is a bug. Very easy for me to duplicate in both production and test JSSes. Where to file bug reports....

@nicholasmcdonald yep... same, pointing to LDAP user doesn't work, pointing to user's machine works great...

It seems to be related to how jamf runs the policy from Self Service. Let's say my user in LDAP is 'eirik@example.com', while my user account on the computer is 'eirik'. I can scope a policy to my LDAP user, and it shows up in Self Service. But when I run the policy from Self Service (or 'jamf policy -event EVENTNAME'), it will run by checking the user scope 'eirik'. And since 'eirik' is not 'eirik@example.com', the policy is not found.

Basically, this means that LDAP user/group scoping is non-functional for policies run by Self Service. A Self Service policy must be scoped to the computer in order to work. This is not ideal...

I'm having this problem with a brand-new JSS. Version 10.11.1-t1553545638.

Devices affected (so far) are 2018 Mac minis running Mojave 10.14.4.

My policy in question is a policy that uses dockutil to customize the Dock for the device admin account. I had a policy limitation set to JSS admin accounts.

With the limitation set, the policy fails. When I removed the limitation it works.

So we have a policy that simply did a jamf recon, jamf policy and jamf manage in the "File and Processes" options under "Execute Command".
We call it "Jamf Refresh" and have it only in Self Service.

Recently noticed that we were getting the "This item is no longer available" message after it finished running.

Replaced the jamf recon, jamf policy and jamf manage commands like this:
/usr/local/bin/jamf recon > /dev/null 2>&1; /usr/local/bin/jamf policy > /dev/null 2>&1; /usr/local/bin/jamf manage > /dev/null 2>&1

Now it works with no issues. Why? I have no idea!

I'm having this issue as well. Device enrolled through DEP, shipped from Apple running 10.14.4 and Jamf Pro at 10.13.0 cloud. Device goes through Pre-stage, creates admin account, binds to AD and gets default profiles. Then after getting the error in self service I notice the device says unmanaged in JAMF. I can run sudo Jamf recon and and sudo Jamf policy in terminal but nothing in Self Service will work on the device. I just get the same error that started this post. Manually reenrolling the device clears this up for me. This is not every machine and there really is no rhyme or reason to it. Hopefully JAMF looks into this ongoing bug.

I've been running into this as well, with several policies. In my case it also seems to be a scoping-related issue. When the policy is scoped to a user, it can be triggered via terminal, but the error comes up in Self Service. After changing the scope from the user to a computer group, the policy runs fine via Self Service.

We are experiencing this as well. Testing out the immediately-aforementioned fix with the computer group now.

is there a solution yet? I still see "This item is no longer available".
running jamf 10.29 on Catalina. btw: all Macs up to 10.14.x are working fine with jamf with any policy.

The solution is to enable the ability to login to Self Service in Jamf settings and then when users login with their AD account they see what is personally scoped to them and downloading works without error.

This still seems to be an issue sometimes in Jamf Pro 10.50.0. Rebooting the client machine seems to fix it. I think it is mis-caching something that doesn't get cleared when refreshing or relaunching Self Service.