Just tried recreating the policy from scratch again, only this time I used a different policy name... this works fine. It sounds to me like a database issue or something? I'm going leave my support ticket open and follow up with someone from JAMF.
I'm also going to test every package available in my Self Service catalog to see if it's just policies with post scripts that are impacted.
I've been seeing this today. In our case, what seems to cause this is having a policy that contains a bash script that as part of it's execution calls a jamf policy. (We do as part of a printer install script policy - it attempts to run a separate policy that installs a driver, and that policy is run-once, so that we only install the print driver once, instead of each time we install the printer.)
Ive also been seeing this issue randomly on 10.4.1 this last week
it doesn't seem consistent, as recreating policy with exactly the same options can get it working again.
(in our case these are policies to install a .pkg for installing different builds of Adobe CC 2018 and run a separate pre-flight bash script in the same policy to remove old version first)
Other times we have fully working policies that when duplicated to create a new one with a different .pkg, will not work on the cloned policy unless the script is removed first
So far we've only seen this happen with policies containing either pre-flight or post-flight scripts as GeorgeCasper & ajfunk previously mentioned above.
I think we’re on to something. Seems it’s scripts with pre or post flight scripts that fail. My big one that always gives me trouble has both a pre and post script as part of the policy.
Btw @gbidwell i would love to see your scripts for removing Adobe. It’s becoming the Bain of my existence.
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.
A Self Service policy to install app X that triggers an "Install Java" policy as app X requires Java.
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....
It seems to be related to how jamf runs the policy from Self Service. Let's say my user in LDAP is 'firstname.lastname@example.org', 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 'email@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.