Policy Custom Trigger Question(s)

[ChrisTech]

Gooooood Morning!

I'm working on two policies that:

Policy One:
Deletes a user account
Creates a user account
Trigger a second policy

Policy Two:
Installs a two packages Installs a LaunchAgent
Reboots computer

Policy one runs OK but it seems like it can't find the custom trigger for Policy Two sometimes. I can check the logs for Policy Two and it's running. I created a script to run after in Policy One to trigger Policy Two. Will running the script after all the other actions ensure that the first script has ran, the account created before triggering Policy Two?

Why do I see more activity in Policy Two, it can only be called by it's custom trigger, right? I thought it might be because the first policy is doing recon while the other policy has been triggered.. ?

[davidacland]

As long as there are no other triggers on the second policy, it should only be triggered by the first one.

Not sure if it will make any difference but I normally do it slightly differently with a script that runs both policies in order:

#!/bin/sh

jamf policy -event trigger1
jamf policy -event trigger2

exit 0

I then use a policy to run this script only.

Hope it helps!

[marklamont]

just wondering why you need two polices to do this?

you could delete then create the accounts in a before script, install the packages and the launchagent as packages then restart all in one policy.

[sdagley]

@ChrisTech Try triggering your 2nd Policy via an Execute Command in a Files and Processes option in your 1st Policy. That way the 2nd will definitely be executed before the 1st runs a recon. And make sure that the device your intending for the 2nd policy to run on is actually in scope for that policy

[ChrisTech]

Well I played around with a script that executes the second policy with a trigger - that worked better except the JSS was flooded with inventory requests and only a handful were able to check in to the JSS and get/find the second policy. It works great in Self Service when you are just doing one machine at a time.

@marklamont I did think about that. Don't you need to specify the uniqueID of the account when creating it with dscl? These are lab machines with probably 50 accounts on them already and I didn't just want to pick a number.

[marklamont]

@ChrisTech try this little routine.
I populate the other variables elsewhere in my script but the first bit works out the highest account number then adds one to it.

lastid=$(dscl . -list /Users UniqueID | awk '{print $2}' | sort -n | tail -1)
if [ "${lastid}" -le "500" ]; then
            nextid="501"
        else
            nextid=$((lastid + 1))
        fi

       dscl . create /Users/$eusername  #account name
        dscl . create /Users/$eusername UserShell /bin/bash
        dscl . create /Users/$eusername RealName "$enduserrealname"  #account full name
        dscl . create /Users/$eusername UniqueID "$nextid"
        dscl . create /Users/$eusername PrimaryGroupID 1000
        dscl . create /Users/$eusername NFSHomeDirectory /Users/$eusername
        dscl . passwd /Users/$eusername "$userpass"  #password to use
        dscl . create /Users/$eusername picture "$userpicture"  #picture for account
        dscl . append /Groups/admin GroupMembership $eusername  # adds as an admin, modify as required

[sdagley]

@ChrisTech If you have a call to jamf policy -event trigger2 in your 1st policy you should see the 2nd policy run to completion before the 1st policy exits/runs recon (at least thats how things work if you trigger the 2nd from a Files and Processes payload. If you're forcing a restart via a script in your 2nd policy you'll prevent the 1st policy from ever reporting completion.

You may also want to look at this article on using the sysadminctl in 10.10 or later for creating user accounts: sysadminctl: our new friend

[Look]

As @sdagley says the restart in the second policy wil be upsetting the logs.
Move the restart to the first policy, the second policy should run through before the first policy restarts and the logging should end up correct.

[mscottblake]

If policy1 is calling policy2 then policy2 initiates a reboot, it will interrupt policy1.

The policy2 reboot will run before the completion of policy1. Policy1 logs and inventory will be waiting for policy2 to complete before they are sent to the JSS, causing issues.

[ChrisTech]

@marklamont Excellent! That does what I needed. For some reason though it's not pulling the default dock in the templates when the user logs in with that particular account. The most important part is that all of the steps are contained in one policy. Dockutil takes care of the dock for this particular account through the LaunchAgent. Many thanks!