Run policies on enrollment, AFTER user logs in

[danshaw]

I have a series of policies that fire off with the enrollment trigger when a computer is first picked up using DEP. Trouble I am running into is that if you wait too long on the screen for creating the user account, the policies start to run due to the computer being enrolled in the background before the user logs in for the first time. This causes the policies to run as the "_mbsetupuser" user account.

Does anyone know how I can hold off on running these scripts until the user logs in? Guessing maybe it needs to be a LaunchAgent that is installed on enrollment, that then runs a script to start the policies? Curious if there is an easier way.

[sam_g]

Are you able to set the trigger to be on "login" instead? That's what we do for our initial enrollment.

[tthurman]

This is tricky.
Something that should be noted. I don't think it's best practice to use the Enrollment Complete trigger to install applications.
--EDIT-- I don't think it's best practice to install more than 1 or 2 applications during Enrollment Complete. --EDIT--

I'm not sure if you're binding to the domain or not, but that shouldn't matter.

My recommendation would be to write a pkg that installs a LaunchDaemon and then in the postinstall of the pkg - load it.

Use the LaunchDameon to run a script to call individual policies from jamfPro. Make sure that it waits until "Finder" is running.

That should accomplish what you're trying to do.

Regards,
TJ

[jmahlman]

What @tthurman mentioned is probably the most fool-proof method for making something run at enrollment after logging in. I use DEPNotify for our DEP machines and that was the only way I could get consistent results.

I make a package that drops the app, scripts, and a launch daemon to run the scripts at login (after a few checks). My package has a post install script that activates the launch daemon and when the user logs in it makes sure it’s not the _mbsetup user, and the finder and dock are both active. After that it runs.

It’s worked 100% of the time for me so far!

[stevenjklein]

I'm not familiar with DEPNotify, though I did just read the DEPNotify readme file.

It's not clear to me how DEPNotify can solve this problem. If there's a feature in DEPNotify to run a script/package/whatever after the user is logged in, I'm not seeing it.

[sdagley]

@stevenjklein The combination of DEPNotify and Jamf's DEPNotify-Starter script can be used to trigger as many policies as you want/need once the Setup Assistant completes if you set up a policy to run the DEPNotify-Starter script on the Enrollment Complete trigger

[mbezzo]

Hi,
We do something similar to what @tthurman does, but it's just a bash script that's run by a policy triggered with Enrollment complete:

#!/bin/bash

# Get the currently logged in user
loggedInUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");'`
log "Current user is $loggedInUser"

# get UID for current User
currentUID=$(dscl . -list /Users UniqueID | grep $loggedInUser | awk '{print $2;}')
log "$loggedInUser UID is $currentUID"

# Check and see if we're currently running as the user we want to setup - pause and wait if not
while [ $currentUID -ne 502 ] && [ $currentUID -ne 501 ]; do
    log "Currently logged in user is NOT the 501 or 502 user. Waiting."
    sleep 2
    loggedInUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");'`
    currentUID=$(dscl . -list /Users UniqueID | grep $loggedInUser | awk '{print $2;}')
    log "Current user is $loggedInUser with UID $currentUID"
done

# Now that we have the correct user logged in - need to wait for the login to complete so we don't start too early
dockStatus=$(pgrep -x Dock)
log "Waiting for Desktop"
while [ "$dockStatus" == "" ]; do
  log "Desktop is not loaded. Waiting."
  sleep 2
  dockStatus=$(pgrep -x Dock)
done

# Start the imaging process since we're now running as the correct user.
log "501 or 502 user is now logged in, continuing setup."
jamf policy -event firstRun

exit 0

Edit as necessary for your situation. :)

Good luck!

[danshaw]

Thanks everyone! Some great ideas. I think I'll use the script from @mbezzo and instead of waiting for the 501 or 502 user, I will write it to look for any username that is NOT "_mbsetupuser". Might even do a check to see if the finder and dock are up. Hopefully running this on enrollment will work consistently. If it doesn't I can try what @jmahlman and @tthurman say to do.

[joshuaw]

@mbezzo Are all of your other install policies then set to run at enrollment complete as well or just at login?

[mbezzo]

Hi @joshuaw I only trigger one policy with enrollment complete, which kicks off a policy that starts a script that calls the policies in our preferred order (amongst other things). Technically, this shouldn't be necessary - but I like the regularity of knowing each and every computer will have things installed in the same order.

Good luck!

[Geant-IT]

@mbezzo What script do you use to call policies in a certain order? Would like to try that

[mbezzo]

Hi @Geant-IT The script is super simple - just a bunch of:

#!/bin/sh
jamf policy -event customTriggerNameHere1
jamf policy -event customTriggerNameHere2

So you just need to set a custom trigger for the policies in question, then just use the script to call them in the order you'd like.

Thanks!
Matt

[sdagley]

@Geant-IT You should look at the combination of DEPNotify and DEPNotify-Starter to automate your enrollment process. You can use it even if you're not currently using DEP/ADE (and if you aren't it'll make things even easier when you make that switch).

[jallen241]

I run into this same issue, it installs crashplan as mpb user vs the actual user. So delaying the app installs would be great.

[LangStefan]

Have a look on that. This should help and i am using it for my enrollments.
A simple launchdaemon that checks some parameters before you go one with any installation.
https://github.com/Yohan460/JAMF-Enrollment-Kickstart