how to run a policy (job) immediately instead of a trigger

NOVELLUS
Contributor III

First a warm hello to the community and a happy new year to everyone ๐Ÿ™‚

I am looking for a solution to run a client policy (job) on jamf pro immediately after setting the scope to the policy instead of triggering it with a event like "change networkstate" or "recurring check-in". The reason is, we have to change a configuration file on the client dependent  of a server event in our windows domain.

I cannot find any article here, so I would be glad, if someone can help me to solve my problem.

greetings,

Michael

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor III

I put together a custom script, LaunchDaemon and Configuration Profile using the Application and Custom Settings payload that I can push to clients that triggers an immediate Check-in or Inventory Collection (Recon) or a custom policy trigger (proper scope still applies to that last one)

Unfortunately you can only choose one of these at a time, and the same option from the above will get triggered for all devices in Scope of the profile. For that reason, I only use it on a case by case basis if I need a machine to check in or submit new inventory as soon as possible. It also usually requires un-scoping the profile from any devices if you want to trigger it again on them. So it's not the most convenient process to use, but it does work.

Without using something like I described, a policy check-in will happen on the next cycle as mentioned above. Depending on your Jamf Pro settings that can be between 5 - 60 minutes usually, give or take.

View solution in original post

8 REPLIES 8

karthikeyan_mac
Contributor III

Policy works based on trigger. You can run  'jamf policy -id <policyid>' from the client to execute immediatley. If you want to trigger from the client with command line, you can try LaunchAgent/LaunchDaemon.

swhps
Contributor III

The policy won't happen until the endpoint checks in.  Setting the trigger to recurring check in means it will run the next time the endpoint checks in so that is about as close to instant as you can get.  From the endpoint you then recon or use the above syntax for jamf policy to get it to run right away.

mm2270
Legendary Contributor III

I put together a custom script, LaunchDaemon and Configuration Profile using the Application and Custom Settings payload that I can push to clients that triggers an immediate Check-in or Inventory Collection (Recon) or a custom policy trigger (proper scope still applies to that last one)

Unfortunately you can only choose one of these at a time, and the same option from the above will get triggered for all devices in Scope of the profile. For that reason, I only use it on a case by case basis if I need a machine to check in or submit new inventory as soon as possible. It also usually requires un-scoping the profile from any devices if you want to trigger it again on them. So it's not the most convenient process to use, but it does work.

Without using something like I described, a policy check-in will happen on the next cycle as mentioned above. Depending on your Jamf Pro settings that can be between 5 - 60 minutes usually, give or take.

alexjdale
Valued Contributor III

Interesting idea, is the LaunchDaemon watching /Library/Managed Preferences/ for a plist file that is created by the profile installation, which triggers it to run the script?  That's very clever.

mm2270
Legendary Contributor III

Actually yes, that's what it does. I didn't come up with the idea myself. I remembered seeing it or reading about it somewhere some time back, but when I decided I could use it myself, I had trouble finding it again. So I just recreated it. If I do end up finding out who originally designed this process, I'll give them credit and kudos, because it is actually a clever idea.

The only thing that is my idea is I expanded on it by using the Applications and Custom Settings payload to allow me to customize what it does, instead of only just a check-in. I can do check-in, custom trigger or a recon. I suppose technically more could be added to that, like having it do a jamf manage as well if needed.

If folks are interested in using it I can post the details of the script and other items here.

alexjdale
Valued Contributor III

Yeah, I was thinking about that last night, you could probably get it to run arbitrary code if you set it up properly.  Anything you can write to a plist from a profile to be read and interpreted by your script.  That would be wildly unsafe, of course.  You'd want to limit it to canned, safe actions like you have in place.

mm2270
Legendary Contributor III

Yeah for sure. I would never have it just run anything passed to the LaunchDaemon. As you said, unsafe. The Config Profile has canned options in it so you can only choose from a few preset items, like Check-in, Inventory & Custom. The script itself is only programmed to look for specific responses in the profile plist to respond to.

Here is what part of the Profile looks like:

Screen Shot 2022-01-13 at 12.40.22 PM.png

If I choose Custom from the drop down, there is another option below to enter a policy ID or custom event trigger.

Screen Shot 2022-01-13 at 12.41.00 PM.png

Of course, the script itself would be vulnerable to being overwritten with malicious code I suppose, but if any software/malware can overwrite the script, which I place in an admin level location, then it can do other things on the Mac as admin/root as well, so that would be the least of my concerns.

NOVELLUS
Contributor III

Thank you very much for your posts and hints.
For our Windowsยฎ clients, we are using Baramundi Management Consoleยฎ  to roll out and install the clients. There are installation jobs as well in Baramundi Management Consoleยฎ, but the jobs can be started immediately, so that the job starts on the client right after clicking "start the job". The Server is sending a push to the client and the job is starting. I hoped, that this would be reachable in Jamf Proยฎ, too.
After reading all the comments and suggestions here, I decided, to change the reconnect time of the clients to 5 minutes. This time is short enough, to change the file on the client in dependency of that server event, wich I had written about in my first post.
Thank you all for your support!