We have a policy that is designed to be run from Self Service only; that is, there is no trigger, just "Make this policy available in Self Service". It runs fine from the GUI.
But I had occasion just now to need to run it from Terminal when SSH'ed into the Mac. I tried running it but it wouldn't:
# jamf policy -id 450 Checking for policy ID 450... No policies were found for the ID 450.
It is true there were no waiting triggers for that policy on that Mac...because it's an exclusively Self Service policy. Why won't the jamf binary run the policy if I'm asking it to? Is there a "-force" option or something I can use to make it just run the darn thing instead of refusing to?
Another thing to check is if you have deferrals setup for it.
I just ran one of mine from the Terminal and it gave me that since the deferral date was in the past.
Also, is the policy scoped to a user/group? If so, you'd put in something like this:
sudo jamf policy -username joe.dirt -id 3
The policy is scoped to all workstations and is set to "ongoing". Both have been set that way for a long time; no recent changes. It runs fine from Self Service; the point is that we don't always have GUI access to the workstation so I wanted a way to replicate Self Service from Terminal.
I believe this to be a deficiency of the jamf binary--that it will only run policies that are scheduled to run on the workstation; it cannot be used to run optional policies. I was hoping someone had a workaround.
@ktappe I'm not sure why its not working for you, but I've had no issues doing this. I just tested on my Mac with a purely Self Service policy; the policy has no actual triggers, but is set up for Self Service only and scoped to my Mac as Ongoing frequency. When I call it using the jamf binary with sudo jamf policy -id <id> it runs perfectly for me.
Are you attempting this while SSH'd into the Mac or while physically on it? If its the former, that may be the problem. I don't know if its possible to call a Self Service policy while SSH'd into the Mac under a different account. I've never tried, but that could be the problem.
I think I know what it could be...
Is the policy restricted to specific users or groups on the limitations tab?
This could well prevent it being in scope when run remotely from a script, terminal or Casper Remote. If the JSS couldn't determine the username the device would fall out of scope and it's not actually always very good at working that out except during OS login and Self Service login.