Is It Possible to Create a Self Service Policy To Run ALL Policies?

[themacdweeb]

Interesting dilemma on something I figured would be super simple: creating a Self Serve policy that runs all available policies. Normally, going into terminal and running "jamf policy" from any admin account brings down any available policies. Simple. Easy. Effective.

Try passing that command via Self Serve (via the "Files & Processes" section) and it's another story entirely: as the jamf agent is already running the self service policy I'm calling, it can't concurrently run a second policy. Makes sense. However, I need a self-serve solution for mobile users who aren't usually on the network: something that will easily run all available updates and policies.

My two solutions aren't working, as shown below, but perhaps what I'm asking is impossible. Is it even possible to create a Self Serve policy that will run all other available policies?

Executing Policy Run All Policies - Self Service...
[STEP 1 of 1]
Running command jamf policy...
Result of command:
This policy trigger is already being run: root 627 18.6 0.2 689620 15644 ?? SN 3:26PM 0:00.34 /usr/sbin/jamf policy -id 105 -showSteps -username -selfServiceOnly -forceNoRecon

Same result if I pass osascript -e 'do shell script "jamf policy"':

Executing Policy Run All Policies - Self Service...
[STEP 1 of 1]
Running command osascript -e 'do shell script "jamf policy"'...
Result of command:
This policy trigger is already being run: root 4895 11.5 0.2 689620 15648 ?? SN 4:38PM 0:00.30 /usr/sbin/jamf policy -id 105 -showSteps -username -selfServiceOnly -forceNoRecon

[mm2270]

Create a LaunchDaemon that uses a WatchPath as its trigger that runs jamf policy as its ProgramArgument.
Deploy this LaunchDaemon to all your Macs and make sure its active by enabling it with launchctl.

Have your Self Service policy do something simple like write a value into the WatchPath file. It can be a simple log file that you deploy along with your custom LaunchDaemon. When the LaunchDaemon sees the file has been modified it will run the jamf policy command, which will run all scoped policies based on the Recurring Check-in trigger.

The only issue I see with the above is that your users won't really see any feedback on what's going on. If you wanted to, I suppose you could script something that would pop up a dialog of some kind while the policies are running to let them know stuff is happening. If you want to be really fancy, a cocoaDialog progress bar could be done that would grab information from the jamf.log to show what's being run.

The above idea is just off the top of my head. Maybe it will give you something to go on.

[freddie_cox]

How often do you have your policy check-in set? (Settings, Computer Management, Check In)

You can go as low as every 5 minutes.

I guess I am trying to figure out why you would need/want to run a policy check on-demand from Self Service when it can run it so frequently on its own. It will always fail in the manner because a policy (your self service policy) is already running and it can't call the binary to run another policy while using said binary.

As @mm2270 said, you'll have to have the SS policy trigger something that is outside of Casper that can wait on your SS policy to run and then run the binary as root.

[bpavlov]

The majority of the policies I have actually run through a policy that runs a scripts that then calls another policy. The script basically checks for running processes to make sure the application being updated isn't running. I literally call the other policy using:

jamf policy -trigger "$4"

With $4 being the variable value in the policy. It has the name of the custom trigger for the other policy it needs to run.

So perhaps this is an option for you.

[rtrouton]

I had a similar-sounding issue with regards to triggering jamf manage to run, where the issue I ran into is that jamf manage waits until all policies are finished running. This was a problem for me since I wanted to have a policy where jamf manage was run, then the policy would perform an inventory update.

My solution was to deploy a script and LaunchDaemon with Casper, then have the policy load the LaunchDaemon. The LaunchDaemon then triggered the script to run and the script ran jamf manage and the inventory update instead of a policy directly running both. That allowed jamf manage to run like I wanted it to.

For those interested, I have a post on what I did available from here:

https://derflounder.wordpress.com/2014/06/15/automatically-fixing-mdm-certificate-enrollment-with-ca...