Posted on 11-27-2017 06:47 AM
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.
Posted on 07-17-2018 07:45 AM
That’s a good question. I would imagine you can, as to how, don’t know.
Posted on 07-17-2018 01:26 PM
@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
Posted on 07-19-2018 06:33 AM
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.
Posted on 07-19-2018 10:55 AM
@pmcavey can you tell me to what or who you are scoping it to ? like AD users for example or just computers ?
Posted on 07-25-2018 01:50 PM
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.
Posted on 07-25-2018 01:55 PM
Have you reported to JAMF? We really need to get their eyes on this.
Posted on 07-25-2018 02:10 PM
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."
Posted on 07-25-2018 02:12 PM
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.
Posted on 07-25-2018 03:10 PM
Just recreated the policy from scratch using identical settings... issue persists.
Posted on 07-25-2018 03:48 PM
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.
Posted on 07-26-2018 05:13 AM
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.
Posted on 07-26-2018 08:54 AM
Posted on 07-26-2018 09:30 AM
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:
After removing those commands, the policies execute without issue.
Posted on 07-26-2018 12:06 PM
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.)
Posted on 07-26-2018 02:52 PM
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.
Posted on 07-26-2018 02:59 PM
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.
Posted on 08-24-2018 09:00 AM
This issue appears to still occur in Jamf Pro 10.6.0...
Posted on 09-11-2018 12:52 PM
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
Posted on 09-19-2018 11:12 AM
@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!
Posted on 09-19-2018 12:25 PM
Removed Duplicate post
Posted on 09-19-2018 12:26 PM
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?
Posted on 09-24-2018 04:42 AM
@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...
Posted on 10-01-2018 03:26 AM
@nicholasmcdonald I have the same issue and cant seem to fix it. Recreating policy has not helped..opened ticket with Jamf.
Posted on 10-01-2018 04:02 AM
A policy has been set to once per computer for self-service. Please change that one to 'Ongoing' for self-self-service.
Posted on 10-30-2018 02:15 PM
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....
Posted on 12-14-2018 07:10 AM
@nicholasmcdonald yep... same, pointing to LDAP user doesn't work, pointing to user's machine works great...
Posted on 01-11-2019 02:45 AM
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...
Posted on 05-06-2019 06:37 PM
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.
Posted on 06-12-2019 03:08 PM
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!
Posted on 07-16-2019 07:35 AM
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.
Posted on 07-17-2020 02:48 PM
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.
Posted on 12-23-2020 12:04 PM
We are experiencing this as well. Testing out the immediately-aforementioned fix with the computer group now.
Posted on 07-05-2021 03:41 AM
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.
Posted on 10-01-2021 12:39 AM
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.