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.

[kwoodard]

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

[ThijsX]

@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

[pmcavey]

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.

[ThijsX]

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

[ajfunk]

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.

[kwoodard]

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

[ajfunk]

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

[kwoodard]

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.

[ajfunk]

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

[ajfunk]

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.

[ajfunk]

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.

[kwoodard]

@ajfunk What is in the policy?

[ajfunk]

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.

[GeorgeCasper]

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

[garybidwell]

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.

[kwoodard]

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.

[jimd]

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

[psliequ]

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

[nberanger]

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

[nicholasmcdonal]

Removed Duplicate post

[nicholasmcdonal]

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?

[vaksai]

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

[KarmaLama]

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

[maheshveldandi]

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

[tuinte]

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

[tsylwest]

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

[eDooku]

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

[gskibum]

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.

[david_dondero]

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!

[J_Mukite]

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.

[thefaded]

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.

[d_mccullough]

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

[Yoda]

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.

[Pamoman]

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.

[esummers78]

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.