Skip to main content
Solved

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

  • January 12, 2022
  • 11 replies
  • 107 views
A
  • Anonymous

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

Best answer by mm2270

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.

    11 replies

    karthikeyan_mac
    Forum|alt.badge.img+18
    • karthikeyan_mac
    • Honored Contributor
    • January 12, 2022

    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.

    S
    Forum|alt.badge.img+11
    • swapple
    • Valued Contributor
    • January 12, 2022

    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
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • Answer
    • January 12, 2022

    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.

    karthikeyan_mac
    R
    A
    Forum|alt.badge.img+17
    • alexjdale
    • Contributor
    • January 12, 2022

    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.


    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
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • January 13, 2022

    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.


    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.

    S
    karthikeyan_mac
    R
    A
    Forum|alt.badge.img+17
    • alexjdale
    • Contributor
    • January 13, 2022

    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.


    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
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • January 13, 2022

    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.


    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:

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

    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.

    R
    A
    • Anonymous
    • January 14, 2022

    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!

     

    S
    Forum|alt.badge.img+6
    • stevenjklein
    • Contributor
    • February 1, 2024

    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.


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

    Very interested. Please do post the details.

    R
    Forum|alt.badge.img

    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:

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

    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.


    killer job over here. Would mind sharing with us your process, would love to implement this. thanks. 

    F
    Forum|alt.badge.img
    • fsocietylearn
    • New Contributor
    • October 22, 2024

    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.


    Hi,

     

    That is a very clever way to trigger a policy. Could you share with me the custom script and the process of setting this up? I am also looking for something similar 😄

    Terms & ConditionsCookie settingsAccessibility statement