Custom Trigger Question

[casafrancisco]

Hi Everyone,

I just recently learned about Custom Triggers and I think they are great. I have a question about how I can get this done though.

Policy 1: (made to be fast)
-install essential software
-force restart in 2 minutes
-next login enable FileVault 2

Policy 2:
-install supplemental software
-install printers
-install etc

How can i trigger Policy 2 to run after that restart?

[Hugonaut]

I'm assuming that Policy 1 & Policy 2 are intended to run in sequence back to back guaranteed everytime. Here is One Way to Skin This Cat!

As a part of Policy 1 you could package and a deploy a LaunchDaemon & a script that the LaunchDaemon calls on.

For Policy 2, set the trigger to only a Custom Event (for sake of post we will name the event "policy2triggername")

Policy 1 Runs and deploys the launchdaemon & script, along with everything else it is suppose to do and then restarts.

The LaunchDaemon will run at load, when the user logs in & call the script.

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 
<plist version="1.0">
<dict> 
     <key>Label</key>
          <string>com.example.app</string>
     <key>Program</key>
          <string>/Script/Location/SCRIPT.sh</string> 
     <key>RunAtLoad</key> 
     <true/> 
</dict> 
</plist>

The Script in /Script/Location/SCRIPT.sh will contain the policy trigger command

#!/bin/sh

sudo jamf policy -event policy2triggername

Now Policy 2 is Triggered at login. As a part of Policy 2, you need to run another script from the JPS at the end to unload & then remove the LaunchDaemon & /Script/Location/SCRIPT.sh.

[casafrancisco]

@Hugonaut I want them to run in sequence but I don't want Policy 2 to start until after the restart. Would this still work for that?

I currently have a script that will call Policy 2 and it works but I believe it starts Policy 2 but then the restart process of Policy 1 occurs then when the computer comes back up the Policy 2 process was terminated by the restart.

[ryan_ball]

You could package this up and place it into /Library/LaunchDaemons and call it com.yourcorp.example.plist

You could then in your policy that this kicks off, do you printer installations and whatnot and also remove this plist afterward. You'd want to test that my syntax is correct, as I just quickly threw it together.

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 
<plist version="1.0">
<dict> 
     <key>Label</key>
          <string>com.yourcorp.example</string>
          <key>ProgramArguments</key>
          <array>
               <string>/usr/local/bin/jamf</string>
               <string>policy</string>
               <string>-event</string>
               <string>your_trigger_goes_here</string>
          </array> 
     <key>RunAtLoad</key> 
     <true/> 
</dict> 
</plist>

[ShaunRMiller83 · Accepted solution]

From a diffrent perspective if you want to keep it all within JAMF.... You could add a "watermark" to the system ( touch /var/db/.Policy1Done ) that runs with policy 1, run a recon at the end of policy 1, have an extension attribute looking for the "watermark".

Then you can run Policy 2 scoped to "Watermark Present" at login or startup. The last steps you would want to do in policy 2 is add a "counter watermark" file ( touch /var/db/.Policy2Done ) have an extension attribute looking for that "counter watermark".

The logic for the "Watermark Present" Smart Group would be Policy1Done is Present and Policy2Done is Not Present

[GGInquisitor]

I'm looking to do something similar but I'm a scripting noobie(although investigating this has started me on a journey).  Would you be able to expand a bit more on the code required to place and then remove the watermark?  Same for the extension attributes to then look for those watermarks?

I think this is going to help solve a fairly big issue for us.  Appreciate any guidance!

[ShaunRMiller83]

It's a bit hard to give specific details with such broad details but you could

deploy a policy to a scope of systems, in the policy run a script at the end with something like

if [ -e <path to file> ]; then 

echo "File installed"

touch /var/db/.FileNameInstalled

elif [ ! -e <path to file> ]; then 

echo "File installed"

touch /var/db/.FileNameNotInstalled

fi

The EA would be:

if [[ -e </var/db/.FileNameInstalled> ]]; then 

echo "<result>yes</result>"

elif [[ -e /var/db/.FileNameNotInstalled ]] || [[ ! -e </var/db/.FileNameInstalled> ]]; ; then 

echo "<result>no</result>"

fi

If you can give more details on what you're trying to do can be more helpful. Hopefully I am explaining that clear enough, and my formatting didn't get jacked up

-Shaun 

[Hugonaut]

@casafrancisco Yes, LaunchDaemons/Agents run at boot or login. Because you are just deploying and not manually loading the daemon in policy 1, it will then trigger once the computer restarts and initiate, then calling policy 2. Use @ryan.balls plist - his process is cleaner! As Always!!! haha ...now I just gotta go back and rethink my Daemons because I overlooked that! @ShaunRMiller83s process is also flawless. +1