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

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.

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.

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?

That’s a good question. I would imagine you can, as to how, don’t know.

@pmcavey is it running on an windows server environment? then you can use command like beneath.

"c:Program FilesMySQLMySQL Server 5.7inmysqlcheck.exe" -u root -p --auto-repair --optimize jamfsoftware

I am running it on a Mac (10.12.6). I created a new package in composer, loaded it, made a new policy and added to self service and I still get the item is no longer available.

@pmcavey can you tell me to what or who you are scoping it to ? like AD users for example or just computers ?

I'm having the same issue after updating my JAMF server to 10.6 - I tried all the aforementioned recommendations but to no avail. Ended up having to revert my server snapshot back to 10.5.

Have you reported to JAMF? We really need to get their eyes on this.

I've just submitted a support ticket to JAMF. Even after reverting our server back to 10.5 using VMWare Snapshot, JAMF Pro isn't working. Either errors out with "Error" when deploying software or it errors out with "This item is no longer available."

Have you tried to recreate the policy from scratch? That seems to work, at least on our setup. Can't clone or modify and existing, have to start it from scratch.

Just recreated the policy from scratch using identical settings... issue persists.

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.

Just an update: came into the office this morning and it appears the changes I made last night do not work this morning... well they kinda do. A policy I recreated from scratch yesterday is giving the item not available error, but then the package deploys.

@ajfunk What is in the policy?

I figured out the fix (for me, anyhow):

The impacted policies had some post-flight scripts tied to them. Those scripts has some jamf-related commands in them:

jamf policy
jamf log
jamf manage

After removing those commands, the policies execute without issue.

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.

This issue appears to still occur in Jamf Pro 10.6.0...

While Jamf works on a permanent resolution to this, I've found that if it's a pre/postflight script that's causing the issue, you can send the stdout of the jamf policy to /dev/null which seems to do the trick.

/usr/local/bin/jamf policy -event CustomEvent > /dev/null 2>&1

@psliequ Thanks for that update, but could you explain it a little more? I am not quite sure I understand what you are doing or how you are doing it. Thanks!

Removed Duplicate post

In my case I've seen this recently when I have a policy scoped directly to an LDAP user. When I change the scope to point directly to the device instead the issue goes away. Anyone else seen this behavior?