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