Problems using osascript Display Dialog with Enrollment Complete trigger policy

[ericbenfer]

I've recently run into a challenge with an Enrollment Complete trigger workflow.

I want to run a bash script that uses osascript display dialog to prompt the current user for an asset tag after enrolling.
The script is thoroughly tested. It works from the command line. It works in a policy using self service, or a custom trigger.
However, if the policy is triggered by Enrollment Complete the script runs but it does NOT display the AppleScript dialog box.

I've simplified the policy for testing.
I setup one policy using the Enrollment Complete trigger and a custom trigger.
I use "Files and Processes > EXECUTE COMMAND"

/usr/bin/osascript -e "display dialog "Hello World"" >/dev/null 2>&1

According the to policy logs the policy runs during enrollment. The command runs but the osascript Display Dialog does not appear.
If I run the policy from the command line with the custom trigger it works.
I have also tried this with a full bash script using sudo -u "$currentUser" osascript

Thoughts?

[Hugonaut]

have you tried creating just a script via Management Settings -> Computer Management -> Scripts , adding it to the policy & have it set to run after policy? might be a quick easy workaround.

#!/usr/bin/osascript display dialog "Hello World" buttons {"Click Here to Acknowledge, etc.."}

[mbezzo]

Is it maybe running too early? Like before the desktop is loaded? That's been a constant struggle for us with DEP workflows. We get around it with a policy triggered by enrollment complete that does a while loop that waits for a specific user id to be logged in (maybe 501) and then a second while loop that waits for the dock process to exist. Once those conditions are met, then call your notification policy.

Thanks,
Matt

[ericbenfer]

I just figured out the cause. The "current user" while the script is running is _mbsetupuser.
_mbsetupuser is the account used by setup assistant.

So I know the problem... Just not sure how to fix it... yet. @mbezzo I agree with you. I may need to hang back a bit before kicking off scripts like this.

[mbezzo]

Yeah, this is exactly what was happening to us. Here's the code I'm using to wait (sanitized slightly). Maybe it'll help. We wait for the 501 or 502 user as those are the possible users for us when this runs. Adjust accordingly.

#!/bin/bash

# Function to add date to log entries
log(){
NOW="$(date +"*%Y-%m-%d %H:%M:%S")"
echo "$NOW": "$1"
}

# Logging for troubleshooting - view the log at /var/log/thelog.log
touch /var/log/thelog.log
exec 2>&1>/var/log/thelog.log

# 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

# Call the policy we need to run now that the user is fully logged in.
log "501 or 502 user is now logged in, continuing setup."
jamf policy -event yourEvent

exit 0

[blackholemac]

It is running AppleScript too early...enrollment complete policies start to fire off during the setup assistant. I usually have my first GUI based AppleScript run as a first true interactive login trigger. It is possible to get cute and add a “dummy user account” and configure it to login automatically during your enrollment complete if you need to.