testing to see jamf policy is already being run by root

[jmartinez0837]

Hello everyone, I am leveraging DEPNotify to 'image' our school's devices and I am running into an issue where my DEPNotify script tries to use 'sudo jamf policy' only to find that it is already run by root and the script moves on. I am looking for a way to test to see if jamf policy is already being run by root before continuing with the script. Has anyone been able to create such test expression? 

[sdagley]

@jmartinez0837 A couple of things to keep in mind when calling the jamf binary from a script already being run by a Jamf policy:

1) Do not use sudo unless you're specifically trying to run as a different user than root because scripts running from a Jamf policy are already running in the root context.

2) You can call the jamf binary to execute a policy from a script already being run by the jamf binary, you just can't do the generic 'jamf policy' to check for any pending policies. Instead you have to be specific about the policy to be run (e.g. 'jamf policy -event InstallGoogleChrome') 

You mention using DEPNotify, but are you using https://github.com/jamf/DEPNotify-Starter in conjunction with it? If not definitely take a look as DEPNotify Starter will greatly simplify your adoption of DEPNotify.

[mm2270]

As already mentioned by @sdagley , you don't want to kick off your policies during an enrollment with the standard jamf policy trigger. This gets called automatically by the LaunchDaemon that gets installed at enrollment, so there's always a chance, in fact I'd say a really good chance, that you'll bump into it and it will mess things up, as you've already found.

In fact, in my custom enrollment DEP policy script, I actually temporarily disable the check-in trigger LaunchDaemon. The Mac is forced to restart at the end of all its installs and enrollment anyway, so it kicks back in after the restart. I found that even if I used all custom triggers, sometimes policies would end up kicking in during the check-in trigger that I didn't want during that initial setup. Sure, this can be fixed if you're super careful with all your policies and scope for them, but it was just easier to temporarily turn off the recurring check-in on the device while my script was taking care of setup.