I thought the old "-trigger" flag still worked in Casper Suite 9, but the new preferred term is "-event" now. Perhaps as of version 9.22 they removed the ability to use the old flag. Not sure. Anyway, try updating your policy to use -event instead and see if that fixes it.

The "-trigger" flag does still work in v9, however the name of the trigger has been changed. Instead of every15 (or every5 or every30), the JSS is now expecting the trigger "recurring check-in" to be called. If you run jamf policy without any flags, it will automatically check for policies on the "recurring check-in" trigger.

Hope that helps!

-Kitzy

Just a quick clarification, if you try to manually run the recurring check-in with an event of "recurring check-in", it will not actually work. The "recurring check-in" happens when a client machine checks in with a blank/empty event. The logs will record this as a "recurring check-in" event type. This was tested to be true as of 9.21.

Doesn't work:

jamf policy -event 'recurring check-in'

The following work:

jamf policy -event ''
jamf policy -event
jamf policy

This information was useful, but unfortunately it appears as though I cannot manually trigger a "recurring check-in" (formerly every15) via Self Service.

Commands I attempted… $ sudo jamf policy -event '' $ sudo jamf policy -event $ sudo jamf policy

Results in Terminal: successfully triggers a recurring check-in.

When this command is run via a Self Service policy: The following is logged…
Result of command: This policy trigger is already being run: root 1277 6.3 0.2 661128 8868 ?? SN 9:53AM 0:00.39 /usr/sbin/jamf policy -id 594 -showSteps -username -noInteraction

Any ideas of how I could force an immediate recurring check-in via Self Service? I don't use it often, but it sure is nice to have. I miss it from Casper 8.

(maverick) Resources 26 9:13am% sudo jamf policy trigger
Checking for policies triggered by "recurring check-in"...
No policies were found for the "recurring check-in" trigger.

@dmohs][/url, you may simply be running into a timing issue. Even on version 8.73, at times when I try to run sudo jamf policy -trigger every30, I occasionally get a similar error that the trigger is already running. If the regular check in cycle has already been started by the LaucnhDaemon, but the random delay time hasn't been reached yet, you'll get that error, and there is nothing you can do from what I can tell to force the check in to occur any faster. You simply have to wait out the random delay before being able to manually trigger the check in again. I find this a little annoying myself, but I've accepted that this is just how it works.

As a test, you could try temporarily disabling the jamf LaunchDaemon that starts the check in just to ensure that it won't run on its own, then try again from Self Service to see if it works.

Thanks for the information. That just might be the case.

That also explains a few times in the past that it didn't kick-in for me, but I never investigated. Perhaps its just picker in v9 or I've been unlucky with my timing since the upgrade.

When it works, I really appreciate it.