Can't Run Self Service Policy from Terminal

ktappe
New Contributor III

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?

9 REPLIES 9

Look
Valued Contributor III

Make sure the device is in the scope of the policy.
Also if the policy has a limited frequency (i.e. not ongoing) make sure the machine is not already in the logs as having run on that device.

emily
Valued Contributor III
Valued Contributor III

Yep, follow the advice @Look provided. It's most likely a frequency mismatch or not in scope.

davidacland
Honored Contributor II
Honored Contributor II

I'd launch self service on the Mac you're trying to run it from. If its not there, it won't be available in the terminal either.

Then it will be one of the reasons the others have mentioned.

scottb
Honored Contributor

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

ktappe
New Contributor III

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.

mm2270
Legendary Contributor III

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

mm2270
Legendary Contributor III

Another thought. You could go in an add manual triggers to all of these policies to use, meaning check "Custom" and add some trigger text there and try it that way while SSH'd in. That may work over a purely only Self Service policy.

Look
Valued Contributor III

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.

scottb
Honored Contributor

@Look - that's what I said above...a user/group limitation to the policy...